Hello Sebastien
Please don't mind me answering inline.
- On 12.06.2014 07:28 pm, sebastien chabrolles wrote:
So, I don't say that the problem is due to Endianness, but we have to keep in mind that fedora 20 ppc64 is BIG Endian.
Yes, but big endian is fine. All those functions operate in network byte order, which is big endian. No conversion is taking place in the code, as that would be unnecessary anyway. Only inet_ntoa() is writing the quad dotted decimal address to a string buffer in host endianness. However, this is done by the operating system, so NX can (and is) agnostic about it.
For the connection, I use IPV4 addresse, no hostname. There is only one IP on the server.
OK. I was asking because the code is calling gethostbyname() which, when given a host name, looks up the address of that specified host name. If, however, the host name should have multiple addresses, all of them will be returned in a list -- their order depending on how the DNS server spits them out. Most DNS servers use a round-robin method for this, so you will get a different ordering with each lookup.
That was one possible explanation for what you might have experienced.
However, if you're only using IP addresses directly everywhere, gethostbyname() merely converts the given string to its binary address representation in network byte order. Thus, the functionality is almost equal to inet_aton() (just the way the information is returned differs, but that's no functional change.)
If you need to have access to the server, this can be done with openVPN certificate. This is only a "sandbox server" to reproduce the x2go issue.
Providing a means to debug the issue would be great, because at that time I have no valid explanation for what is happening there.
Were those packages installed via binary packages? Unfortunately, x2go doesn't ship debug builds.
Please make sure that the machine in question features build tools and gdb, as nxcomp/nxproxy will need to be compiled with debug information in order to get anything interesting out of it.
Mihai