I'm working for IBM, one of our partner would like to use build an "applicance" on one of our Power8 system. They would like to give access to their application through "X2go".
The operating system used is a Fedora 20 ppc64. In oder to install x2goserver, we have add the Fedora Rawhide repo (x2goagent is not available in the fc20 repo). Intallation process is fine, without any error.
But it is impossible to connect to the server from a x2go client. The connection is closed with the following error:
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 !!!!!
I tested the same installation on x86 system (FC20 + rawhide repo for x2goserver). Everything works out of the box.
Is anybody can help me to solve this issue on ppc64 ?
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
Hi Sebastien,
On Mi 11 Jun 2014 12:31:40 CEST, sebastien chabrolles wrote:
I'm working for IBM, one of our partner would like to use build an "applicance" on one of our Power8 system. They would like to give access to their application through "X2go".
The operating system used is a Fedora 20 ppc64. In oder to install x2goserver, we have add the Fedora Rawhide repo (x2goagent is not available in the fc20 repo). Intallation process is fine, without any error.
But it is impossible to connect to the server from a x2go client. The connection is closed with the following error:
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 !!!!!
I tested the same installation on x86 system (FC20 + rawhide repo for x2goserver). Everything works out of the box.
Is anybody can help me to solve this issue on ppc64 ?
Cordialement / Best Regards
Great to here that X2Go is used by IBM.
The problem with your issue is that I/we cannot test/debug things
without accessing that very special hardware platform. I (as one of
the core devs) have absolutely no clue, where that IP is coming from.
By its address pattern, we can tell that it is a multicast IP address
(IIRC). Is that address specific to your setup?
As this is a very special case, I cannot give more advise on this
without being contracted and payed for the time I would have to give
for helping with a solution.
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...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 11.06.2014 13:30, schrieb Mike Gabriel:
As this is a very special case, I cannot give more advise on this without being contracted and payed for the time I would have to give for helping with a solution.
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.
@Sebastien: Wikipedia claims that PPC64 can be switched to little-endian, though big-endian is the default. Could you please check if such a switch is feasible for you and if it makes the problem go away?
iQEcBAEBAgAGBQJTmELDAAoJEG7d9BjNvlEZNiAH/1MvWym/fo0t9yBdCerpmgLi X0ju9arhrVDghVDR9fyl4/dxiVm3hoJokZ76gGwBiFu3u3bxpguy+lP0XCQ2iH5l z/gwg/vbwkgY2Y8ZUMoBhm4AQ6co0+EGuphjC89dJ7nux49IYUU6KdICaA+FR+xO YHCOj7bBqYSQy7Gu1rlJ8koLUdaHioarMeCA1Gln/yHfqri/biw4MZkB135vMmKF SkR4XI0OH8FQP5RcuiP1qqyUWH0fqWsc/o7SuffNcLyTkvWsNfaBgxw0+vfW5WiK NmHtCPzRiSoYg5DKbEVGFNylG/wZxWRwbHkHM8SRsgqhnVJvr7cZY3eXn8N4rCI= =ZXWx -----END PGP SIGNATURE-----
The problem is that this switch to little Endian is available on Power8 only and it is dependent to the Linux distro. Because it is new, most of the Linux distro are BigEndian today. (This could change in the future).
Only Ubuntu move to ppc64le.
So we can't easily switch to LE with fedora are redhat today.
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
Le 11 juin 2014 à 13:51, "Stefan Baur" <newsgroups.mail2@stefanbaur.de> a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 11.06.2014 13:30, schrieb Mike Gabriel:
As this is a very special case, I cannot give more advise on this without being contracted and payed for the time I would have to give for helping with a solution.
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.
@Sebastien: Wikipedia claims that PPC64 can be switched to little-endian, though big-endian is the default. Could you please check if such a switch is feasible for you and if it makes the problem go away?
- -Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTmELDAAoJEG7d9BjNvlEZNiAH/1MvWym/fo0t9yBdCerpmgLi X0ju9arhrVDghVDR9fyl4/dxiVm3hoJokZ76gGwBiFu3u3bxpguy+lP0XCQ2iH5l z/gwg/vbwkgY2Y8ZUMoBhm4AQ6co0+EGuphjC89dJ7nux49IYUU6KdICaA+FR+xO YHCOj7bBqYSQy7Gu1rlJ8koLUdaHioarMeCA1Gln/yHfqri/biw4MZkB135vMmKF SkR4XI0OH8FQP5RcuiP1qqyUWH0fqWsc/o7SuffNcLyTkvWsNfaBgxw0+vfW5WiK NmHtCPzRiSoYg5DKbEVGFNylG/wZxWRwbHkHM8SRsgqhnVJvr7cZY3eXn8N4rCI= =ZXWx -----END PGP SIGNATURE-----
x2go-user mailing list x2go-user@lists.x2go.org http://lists.x2go.org/listinfo/x2go-user
Hi Stefan, hi Sebastien,
On Mi 11 Jun 2014 13:51:31 CEST, Stefan Baur wrote:
Am 11.06.2014 13:30, schrieb Mike Gabriel:
As this is a very special case, I cannot give more advise on this without being contracted and payed for the time I would have to give for helping with a solution.
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.
@Sebastien: Wikipedia claims that PPC64 can be switched to little-endian, though big-endian is the default. Could you please check if such a switch is feasible for you and if it makes the problem go away?
- -Stefan
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.
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...
-----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 scopeid
0x20<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 0
lo: 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
-----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-----
Am 11.06.2014 12:31, schrieb sebastien chabrolles:
Warning: *Refusing connection from '225.3.10.80'.* .80' on port '30003'.
I don't know what is this IP address !!!!!
Neither do I, but is Power8/ppc64 a different-endian architecture than x86? If so, there might be some conversion going on in one of the scripts that isn't "endian-safe", so to speak.
cf. http://en.wikipedia.org/wiki/Endianness
If that turns out to be the problem, I guess we should move the thread to x2go-dev and file a bug about it. Let's see what the others think about the issue ...
Anyone else using X2Go on ppc64? Or on a different-endian system than x86?
-Stefan
Power8 support both Endian model (Little and Big)
But Most of the Linux distro on Power are Big Endian (ppc64 is BigEndian) (redhat / fedora) for example.
In my case FC20, we need a code that support Big-Endian or "Endian-safe".
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-user@lists.x2go.org Date: 11/06/2014 13:42 Subject: Re: [X2Go-User] Pb with x2go agent on ppc64 system Sent by: x2go-user-bounces@lists.x2go.org
Am 11.06.2014 12:31, schrieb sebastien chabrolles:
Warning: *Refusing connection from '225.3.10.80'.* .80' on port '30003'.
I don't know what is this IP address !!!!!
Neither do I, but is Power8/ppc64 a different-endian architecture than x86? If so, there might be some conversion going on in one of the scripts that isn't "endian-safe", so to speak.
cf. http://en.wikipedia.org/wiki/Endianness
If that turns out to be the problem, I guess we should move the thread to x2go-dev and file a bug about it. Let's see what the others think about the issue ...
Anyone else using X2Go on ppc64? Or on a different-endian system than x86?
-Stefan
x2go-user mailing list x2go-user@lists.x2go.org http://lists.x2go.org/listinfo/x2go-user
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
Am 11.06.2014 12:31, schrieb sebastien chabrolles:
Info: Waiting for connection from 'localhost' on port '30003'. Warning: *Refusing connection from '225.3.10.80'.* .80' on port '30003'.
Another idea, so we don't keep blaming endianess ;-)
What do the files /etc/hosts say on both the working x64 and the non-working ppc64 system?
-Stefan