Guys, please cc: [email protected] instead of [email protected] - 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. _______________________________________________ x2go-dev mailing list [email protected] http://lists.x2go.org/listinfo/x2go-dev
