"connectedHost" variable contains wrong IP, reason unknown (was: Re: [X2Go-User] Pb with x2go agent on ppc64 system)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Package: x2goagent severity: normal version: 3.5.0.24
Note: Crossposting and Reply-To'ing to X2Go-Dev due to the need for a C/C++ coder, also, turning it into a bug so we can keep track of this.
Here's the output the user gets as the connection refuses to establish itself:
quoting Sebastien Chabrolles:
running as X2Go Agent
NXAGENT - Version 3.5.0
Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information.
Info: Agent running with pid '24808'. Session: Starting session at 'Sat Jun 7 15:37:37 2014'. Info: Proxy running in server mode with pid '24808'. Info: Waiting for connection from 'localhost' on port '30003'. Warning: Refusing connection from '225.3.10.80'. .80' on port '30003'. I don't know what is this IP address !!!!!
And at a later attempt, Sebastien received this output:
running as X2Go Agent
NXAGENT - Version 3.5.0
Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information.
Info: Agent running with pid '10710'. Session: Starting session at 'Wed Jun 11 23:02:09 2014'. Info: Proxy running in server mode with pid '10710'. Info: Waiting for connection from 'localhost' on port '30006'. Warning: Refusing connection from '141.168.10.80'. Info: Aborting the procedure due to signal '1'. Error: Aborting session with 'Unable to open display 'nx/nx,options=/root/.x2go/C-root-51-1402520526_stRWWWBROWSER_dp24/options:51''. Session: Aborting session at 'Wed Jun 11 23:02:19 2014'. Session: Session aborted at 'Wed Jun 11 23:02:19 2014'.
My first guess is/was that there's something endianess-related going wrong, as he's running X2Go on a ppc64 architecture instead of x86/x64. However, the fact that the two "wrong" IPs change at random speak against that, so I may be totally wrong with this and there's a much simpler reason and solution.
quoting myself, replying to Mike Gabriel there:
Do you think you could at least give him a hint as to where that message is pulling the IP from and how it is being mangled/processed before that?
My guess is that there's some self-made conversion routine somewhere that only works on little-endian architectures like x86 and x64.
PPC64 is big-endian by default.
quoting Mike Gabriel:
you can get the nx-libs sources from git.x2go.org [1] and grep through the sources.
I am currently doing the same to get NX fixed on systems with poly-instantiated /tmp directories.
Here's what I was able to find out so far:
I was able to locate the message in Loop.cpp. It uses the variable "connectedHost". So "connectedHost" contains the wrong IP.
connectedHost gets populated (also in Loop.cpp) like this:
char *connectedHost = inet_ntoa(newAddr.sin_addr);
so either newAddr.sin_addr already contains a wrong value (I'm not sure how to check that, though), or inet_ntoa does something wrong, or both.
I haven't touched C/C++ code since the year 2002 or so, so debugging this further is way beyond my ken.
Any one of the more experienced coders willing to jump in?
Here's some more info about the X2Go server system as provided by Sebastien Chabrolles:
# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.7.19.161 fc20-161
# cat /etc/resolv.conf nameserver 129.35.160.4
#cat /etc/nsswitch.conf passwd: files shadow: files group: files ### #this strange-looking entry was present during the first tries. # #hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname # # it was changed to the one below for the last try, which gave # the result with the different, but still wrong, IP. ### hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: nisplus automount: files aliases: files nisplus
# ifconfig -a eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.7.19.161 netmask 255.255.255.0 broadcast 10.7.19.255
inet6 fe80::f816:3eff:feec:ecb8 prefixlen 64 scopeid0x20<link> ether fa:16:3e:ec:ec:b8 txqueuelen 1000 (Ethernet)
RX packets 90677 bytes 5717673 (5.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 89102 bytes 32828059 (31.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 76 bytes 5248 (5.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 76 bytes 5248 (5.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.7.19.254 0.0.0.0 UG 0 0 0 eth0 10.7.19.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
- -Stefan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTmM4gAAoJEG7d9BjNvlEZ1MYH/0X8PNPuZUCxkhkUGndLFaez O0fARZVEa8VWby4jMWUlujgux3lxzcEU1MJ5JluduoTgPwWXUrqlouymEqX1eUqX AnO4W2OKUiOdHEvj89zWFFQIuL8msBdnfJqC1CE1Z7MZ45vA94eztZ8E1wpwtgRd jJq4pa9sR4iz20CamAhWNbu75pBdxGxMYf1KtQFkFOo1kL7RiPA0Z/dNZspeVI3A zVT8CwvnRe+SY3RczOZvlkgXK2CWFaOsATt44hK752ky8v9JCo90wchFrXC++v8r OBtZDOlG5h7aq25VZjP/YWOdTLIyIyGE+tgNDaN+D1Ip+Y/uDFbTGtcMCLx29d0= =ii4y -----END PGP SIGNATURE-----
Thank you for filing a new Bug report with X2Go.
This is an automatically generated reply to let you know your message has been received.
Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course.
Your message has been sent to the package maintainer(s): X2Go Developers <x2go-dev@lists.x2go.org>
If you wish to submit further information on this problem, please send it to 515@bugs.x2go.org.
Please do not send mail to owner@bugs.x2go.org unless you wish to report a problem with the Bug-tracking system.
-- 515: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=515 X2Go Bug Tracking System Contact owner@bugs.x2go.org with problems
On 06/11/2014 05:46 PM, Stefan Baur wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Package: x2goagent severity: normal version: 3.5.0.24
Note: Crossposting and Reply-To'ing to X2Go-Dev due to the need for a C/C++ coder, also, turning it into a bug so we can keep track of this.
Here's the output the user gets as the connection refuses to establish itself:
quoting Sebastien Chabrolles:
running as X2Go Agent
NXAGENT - Version 3.5.0
Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information.
Info: Agent running with pid '24808'. Session: Starting session at 'Sat Jun 7 15:37:37 2014'. Info: Proxy running in server mode with pid '24808'. Info: Waiting for connection from 'localhost' on port '30003'. Warning: Refusing connection from '225.3.10.80'. .80' on port '30003'. I don't know what is this IP address !!!!! And at a later attempt, Sebastien received this output: running as X2Go Agent
NXAGENT - Version 3.5.0
Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information.
Info: Agent running with pid '10710'. Session: Starting session at 'Wed Jun 11 23:02:09 2014'. Info: Proxy running in server mode with pid '10710'. Info: Waiting for connection from 'localhost' on port '30006'. Warning: Refusing connection from '141.168.10.80'. Info: Aborting the procedure due to signal '1'. Error: Aborting session with 'Unable to open display 'nx/nx,options=/root/.x2go/C-root-51-1402520526_stRWWWBROWSER_dp24/options:51''. Session: Aborting session at 'Wed Jun 11 23:02:19 2014'. Session: Session aborted at 'Wed Jun 11 23:02:19 2014'.
My first guess is/was that there's something endianess-related going wrong, as he's running X2Go on a ppc64 architecture instead of x86/x64. However, the fact that the two "wrong" IPs change at random speak against that, so I may be totally wrong with this and there's a much simpler reason and solution.
quoting myself, replying to Mike Gabriel there:
Do you think you could at least give him a hint as to where that message is pulling the IP from and how it is being mangled/processed before that?
My guess is that there's some self-made conversion routine somewhere that only works on little-endian architectures like x86 and x64.
PPC64 is big-endian by default.
quoting Mike Gabriel:
you can get the nx-libs sources from git.x2go.org [1] and grep through the sources.
I am currently doing the same to get NX fixed on systems with poly-instantiated /tmp directories. Here's what I was able to find out so far:
I was able to locate the message in Loop.cpp. It uses the variable "connectedHost". So "connectedHost" contains the wrong IP.
connectedHost gets populated (also in Loop.cpp) like this:
char *connectedHost = inet_ntoa(newAddr.sin_addr);
so either newAddr.sin_addr already contains a wrong value (I'm not sure how to check that, though), or inet_ntoa does something wrong, or both.
I haven't touched C/C++ code since the year 2002 or so, so debugging this further is way beyond my ken.
Any one of the more experienced coders willing to jump in?
Here's some more info about the X2Go server system as provided by Sebastien Chabrolles:
# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.7.19.161 fc20-161
# cat /etc/resolv.conf nameserver 129.35.160.4
#cat /etc/nsswitch.conf passwd: files shadow: files group: files ### #this strange-looking entry was present during the first tries. # #hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname # # it was changed to the one below for the last try, which gave # the result with the different, but still wrong, IP. ### hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: nisplus automount: files aliases: files nisplus
# ifconfig -a eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.7.19.161 netmask 255.255.255.0 broadcast 10.7.19.255
inet6 fe80::f816:3eff:feec:ecb8 prefixlen 64 scopeid0x20<link> ether fa:16:3e:ec:ec:b8 txqueuelen 1000 (Ethernet)
RX packets 90677 bytes 5717673 (5.4 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 89102 bytes 32828059 (31.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 76 bytes 5248 (5.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 76 bytes 5248 (5.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.7.19.254 0.0.0.0 UG 0 0 0 eth0 10.7.19.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
- -Stefan
I'm far from being any type of coder. Looks like it could be an endian issue though.
inet_aton() converts the Internet host address cp from the IPv4 numbers-and-dots notation into binary form (in network byte order) and stores it in the structure that inp points to.
http://linux.die.net/man/3/inet_ntoa
Mike
- On 12.06.2014 01:04 am, Mike wrote:
I'm far from being any type of coder. Looks like it could be an endian issue though.
No, that doesn't make sense to me.
ppc64 supports both little endian (which is compatible to x86 -- and as it works on x86, it's highly doubtful this is a little endian issue) and big endian (i.e., network byte order), the latter one being the default.
From what I gathered skimming the code, no conversion is taking place (understandble, as inet_ntoa does only create a string with the dotted quad IPv4 address from an address in _network byte order_.)
Generally, nobody needs the address in binary form in host byte order.
Sebastien, how are you connecting? Via an IPv4 address, or via a host name? Does the host name by any chance contain multiple addresses?
(Though I might like to add, that actually debugging this issue really requires being able to reproduce the issue, recompiling nx with debug info and attaching a debugger.)
Mihai
Hi Mihai,
ppc64 support support Big and Little Endian, But... it is quite new and most of the OS distro are BigEndian (fedora, Radhat, Suse, ....) only Ubuntu propose both : ubuntu ppc64 (BE) and ubuntu ppc64el (LE).It will take time for the Enterprise Linux distro to move and fully support ppc64 in Little Endian.
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.
# lscpu Architecture: ppc64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Big Endian ...
For the connection, I use IPV4 addresse, no hostname. There is only one IP on the server.
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.
Cordialement / Best Regards
Sébastien Chabrolles Power Systems Benchmark Specialist IBM Client Center, Montpellier 1 rue vieille poste 34000 Montpellier FRANCE Tel +33 4 67 34 40 95 Email : s.chabrolles@fr.ibm.com
From: Mihai Moldovan <ionic@ionic.de> To: bellyacres@gmail.com, x2go-dev@lists.x2go.org Date: 12/06/2014 18:46 Subject: Re: [X2Go-Dev] [X2Go-User] "connectedHost" variable contains wrong IP, reason unknown Sent by: x2go-dev-bounces@lists.x2go.org
- On 12.06.2014 01:04 am, Mike wrote:
I'm far from being any type of coder. Looks like it could be an endian issue though.
No, that doesn't make sense to me.
ppc64 supports both little endian (which is compatible to x86 -- and as it works on x86, it's highly doubtful this is a little endian issue) and big endian (i.e., network byte order), the latter one being the default.
From what I gathered skimming the code, no conversion is taking place (understandble, as inet_ntoa does only create a string with the dotted quad IPv4 address from an address in _network byte order_.)
Generally, nobody needs the address in binary form in host byte order.
Sebastien, how are you connecting? Via an IPv4 address, or via a host name? Does the host name by any chance contain multiple addresses?
(Though I might like to add, that actually debugging this issue really requires being able to reproduce the issue, recompiling nx with debug info and attaching a debugger.)
Mihai
[attachment "smime.p7s" deleted by sebastien chabrolles/France/IBM]
x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 655.732.332,20 ? SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A
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
Guys, please cc: 515@bugs.x2go.org instead of x2go-dev-bounces@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.
HI Stefan, Sebastien, Mihai,
On Do 12 Jun 2014 21:59:59 CEST, Stefan Baur wrote:
Guys, please cc: 515@bugs.x2go.org instead of x2go-dev-bounces@lists.x2go.org - no idea how that address ended up in here. (CCing so it shows up in the bugtracker)
Actually, please only direct bug related mails to
<bugno>@bugs.x2go.org
and maybe put people that might not be on x2go-dev list into Cc:. (You
can also use <bugno>-submitter@bugs.x2go.org to force the bugtracker
to send the mail to the person who originally issued the bug).
All bugs (if the package has been set correctly) are forwarded to the
x2go-dev ML anyway, so please avoid duplicates. Avoiding duplicates
means: send the mail to the bug. Period. Don't Cc: or To: the x2go-dev
ML.
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Guys,
Just to tell you, I have reproduce the issue on another machine in RedHat 7.0 ppc64
IP of this system is different (10.7.19.168) which could explain the different IP in the session.log... But again, I don't know what is this IP addresse. ....
running as X2Go Agent
NXAGENT - Version 3.5.0
Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information.
Info: Agent running with pid '11574'. Session: Starting session at 'Fri Jun 13 17:00:02 2014'. Info: Proxy running in server mode with pid '11574'. Info: Waiting for connection from 'localhost' on port '30003'. Warning: Refusing connection from '138.119.178.116'. 116' on port '30003'.
Cordialement / Best Regards
Sébastien Chabrolles Power Systems Benchmark Specialist IBM Client Center, Montpellier 1 rue vieille poste 34000 Montpellier FRANCE Tel +33 4 67 34 40 95 Email : s.chabrolles@fr.ibm.com
Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 655.732.332,20 ? SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A
- On 12.06.2014 09:48 pm, Mihai Moldovan wrote:
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.)
Follow-up: I've written a simple program to look up hosts using the OS-provided functions getaddrinfo() and inet_ntop(). If you (Sebastien) are interested, take a look in /usr/src/domainlookup, although it's really boring.
Output for "./getaddrinfo localhost 127.0.0.1 loopback":
### information for localhost ### addr 1: 127.0.0.1 (length 9) addr 2: 127.0.0.1 (length 9) addr 3: 127.0.0.1 (length 9) addr 4: 127.0.0.1 (length 9) addr 5: 127.0.0.1 (length 9) addr 6: 127.0.0.1 (length 9)
### information for 127.0.0.1 ### addr 1: 127.0.0.1 (length 9) addr 2: 127.0.0.1 (length 9) addr 3: 127.0.0.1 (length 9)
### information for loopback ###
Thus, it doesn't look like a system issue. The returned addresses are just fine. Even if something WERE to convert 127.0.0.1 to "localhost" and back to an address, the address list for localhost is fine and does not contain the unknown addresses.
Seems like we're really seeing an nx bug on ppc64.
I'll supply more information later when I get back.
Mihai
WaitForRemote(int) is being called by nxagent/x2goagent. Thus, I should be rather debugging that and not nxproxy...
- On 14.06.2014 01:22 am, Mihai Moldovan wrote:
WaitForRemote(int) is being called by nxagent/x2goagent. Thus, I should be rather debugging that and not nxproxy...
Sorry for sending the last eMail to the wrong bug number, Mike. I got confused with the threads and was adding the addressing manually. :(
However, I have good news for #515. I was able to fix the bug.
I'll be writing a roundup and attaching a patch, soon.
Basically, the addresses Sebastien has seen were "nothing more" than uninitialized memory.
The underlaying issue was that accept() wants a socklen_t *addrlen parameter. The original code created a size_t variable to store the size of the sockaddr structure where information like the IP address is to be written. This value has been, correctly, set to 16. It was then casted to (socklen_t) and given to accept().
The problem, however, is that socklen_t is defined as a 4 byte integer, while size_t is at least 8 bytes wide on ppc64. (I highly recommend reading man 2 accept and the in the man page included Linus Torvald rant on that matter!)
This is "not a big deal" on little endian machines, as casting size_t to socklen_t there will only cut the upper 4 bytes off and leave you with the lower 4 bytes -- which is just fine, as struct sockaddr isn't bigger than 2^32-1 bytes anyway. 16 stays 16 in that case.
Doing the same thing on big endian machines, however, cuts the lower 4 bytes off and leaves you with the upper 4 bytes. As the original value was "16", the upper 4 bytes were all zero.
Thus, zero was passed as the addrlen parameter to accept().
As the addrlen parameter defines how many bytes may be written to the sockaddr structure given to accept(), the function didn't even touch addr. Hence, addr was left in its original, un-initialized state.
It was an endianness issue after all, but not exactly where anyone would have expected it.
The fix is trivial -- don't use size_t as the type of the addrlen variable, but socklen_t, which will also remove the need of casting.
Mike: I hope the patch applies fine. I have quiltimported all other patches before, so my patch is based on the patched nx-libs repository.
Oh, and thanks again to Sebastien for providing access to a Power8 machine for debugging and building purposes!
Am 14.06.2014 03:40, schrieb Mihai Moldovan:
It was an endianness issue after all, but not exactly where anyone would have expected it.
Ha! :-D
@Mihai: Thanks for helping Sebastien out.
@Sebastien: Once your customer's appliance is ready, feel free to add a description of it at http://wiki.x2go.org/doku.php/doc:deployment-stories:start (you will need a Wiki account for this). We're always happy to list success stories from our users. :-)
-Stefan
Am 12.06.2014 18:39, schrieb Mihai Moldovan:
Sebastien, how are you connecting? Via an IPv4 address, or via a host name? Does the host name by any chance contain multiple addresses?
I had asked Sebastien (off-list, yesterday) to provide IPs of client and host as well as traceroutes between them (back and forth), but haven't heard back from him yet. Also, regarding the Name vs. IP question, seconded (I think I asked him before, too, again, off-list, but it seems he skipped that question).
If I hear from him, I will add the info to BTS.
-Stefan
sorry Stefan,
I missed your message
I'm currently at home, thru internet + openVPN. Here is the traceroute output Unfortunatly, some router doesn't sent their IP.
traceroute to 10.7.19.161 (10.7.19.161), 30 hops max, 60 byte packets 1 10.32.0.1 (10.32.0.1) 41.263 ms 42.800 ms 43.497 ms 2 * * * 3 * * * 4 * * * 5 10.7.19.161 (10.7.19.161) 57.182 ms 58.998 ms 59.124 ms
Client IP is 192.168.0.113 (My personal Home network) but my tun0 interface (OpenVPN client) is 10.32.0.8
Server has the following IP : 10.7.19.161
Cordialement / Best Regards
Sébastien Chabrolles Power Systems Benchmark Specialist IBM Client Center, Montpellier 1 rue vieille poste 34000 Montpellier FRANCE Tel +33 4 67 34 40 95 Email : s.chabrolles@fr.ibm.com
From: Stefan Baur <newsgroups.mail2@stefanbaur.de> To: x2go-dev@lists.x2go.org Date: 12/06/2014 19:29 Subject: Re: [X2Go-Dev] [X2Go-User] "connectedHost" variable contains wrong IP, reason unknown Sent by: x2go-dev-bounces@lists.x2go.org
Am 12.06.2014 18:39, schrieb Mihai Moldovan:
Sebastien, how are you connecting? Via an IPv4 address, or via a host name? Does the host name by any chance contain multiple addresses?
I had asked Sebastien (off-list, yesterday) to provide IPs of client and host as well as traceroutes between them (back and forth), but haven't heard back from him yet. Also, regarding the Name vs. IP question, seconded (I think I asked him before, too, again, off-list, but it seems he skipped that question).
If I hear from him, I will add the info to BTS.
-Stefan
x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 655.732.332,20 ? SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A
-------- Original-Nachricht -------- Betreff: Re: [X2Go-Dev] [X2Go-User] "connectedHost" variable contains wrong IP, reason unknown Datum: Thu, 12 Jun 2014 19:39:37 +0200 Von: sebastien chabrolles <s.chabrolles@fr.ibm.com> An: Stefan Baur <newsgroups.mail2@stefanbaur.de> Kopie (CC): x2go-dev@lists.x2go.org, x2go-dev-bounces@lists.x2go.org
sorry Stefan,
I missed your message
I'm currently at home, thru internet + openVPN. Here is the traceroute output Unfortunatly, some router doesn't sent their IP.
traceroute to 10.7.19.161 (10.7.19.161), 30 hops max, 60 byte packets 1 10.32.0.1 (10.32.0.1) 41.263 ms 42.800 ms 43.497 ms 2 * * * 3 * * * 4 * * * 5 10.7.19.161 (10.7.19.161) 57.182 ms 58.998 ms 59.124 ms
Client IP is 192.168.0.113 (My personal Home network) but my tun0 interface (OpenVPN client) is 10.32.0.8
Server has the following IP : 10.7.19.161
Cordialement / Best Regards
Sébastien ChabrollesPower Systems Benchmark Specialist IBM Client Center, Montpellier 1 rue vieille poste 34000 Montpellier FRANCE Tel +33 4 67 34 40 95 Email : s.chabrolles@fr.ibm.com
From: Stefan Baur <newsgroups.mail2@stefanbaur.de> To: x2go-dev@lists.x2go.org Date: 12/06/2014 19:29 Subject: Re: [X2Go-Dev] [X2Go-User] "connectedHost" variable contains wrong IP, reason unknown Sent by: x2go-dev-bounces@lists.x2go.org
Am 12.06.2014 18:39, schrieb Mihai Moldovan:
Sebastien, how are you connecting? Via an IPv4 address, or via a host name? Does the host name by any chance contain multiple addresses?
I had asked Sebastien (off-list, yesterday) to provide IPs of client and host as well as traceroutes between them (back and forth), but haven't heard back from him yet. Also, regarding the Name vs. IP question, seconded (I think I asked him before, too, again, off-list, but it seems he skipped that question).
If I hear from him, I will add the info to BTS.
-Stefan
x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 655.732.332,20 € SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A
-
Mihai Moldovan -
Mike -
Mike Gabriel -
owner＠bugs.x2go.org -
sebastien chabrolles -
Stefan Baur