Subject: Re: [X2Go-Dev] [X2Go-User] "connectedHost" variable contains wrong IP, reason unknown

From: Stefan Baur <[email-masked]>
Date: Thu, 12 Jun 2014 21:59:59 +0200

Guys, please cc: [email-masked] instead of
[email-masked] - no idea how that address ended up in here.
(CCing so it shows up in the bugtracker)

Am 12.06.2014 21:48, schrieb Mihai Moldovan:
> 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.