[X2Go-Dev] Bug#515: [X2Go-User] "connectedHost" variable contains wrong IP, reason unknown

Stefan Baur newsgroups.mail2 at stefanbaur.de
Thu Jun 12 21:59:59 CEST 2014


Guys, please cc: 515 at bugs.x2go.org instead of
x2go-dev-bounces at lists.x2go.org - 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.


More information about the x2go-dev mailing list