On 06.08.2015 12:56, Heinz-Ado Arnolds wrote:
On 06.08.2015 11:42, Stefan Baur wrote:
Am 05.08.2015 um 14:27 schrieb Heinz-Ado Arnolds:
Dear Mr. Bauer,
thanks for your immediate response!
On 05.08.2015 12:30, Stefan Baur wrote: ...
Since you're using a custom-built Linux distribution, it would most likely be helpful to know what it is based on - Debian, Ubuntu, Fedora Core, Red Hat, ... and the corresponding version number.
Our system is build from scratch, no package manager. I used x2goclient-4.0.5.0 x2goserver-4.0.1.19 nx-libs-3.5.0.32.tar.gz
System environment: gcc-5.2.0 glibc-2.21 linux-4.1.3
Another thing to check: Are you using banners, like, for example in /etc/hosts.allow?
No banners, no .profile, no /etc/profile
Would be really great if you have a look at client-sessions1:
Proxy: Identified message of 14 bytes for FD#6 channel ID#1. handleWrite: Called for FD#6. handleWrite: Decoding messages for FD#6 with 14 bytes in the buffer.
a working connection shows
Proxy: Identified message of 50 bytes for FD#6 channel ID#1. handleWrite: Called for FD#6. handleWrite: Decoding messages for FD#6 with 50 bytes in the buffer.
I assume that the fake cookie can't be set. Di you have any hint where to look for this?
In the meantime, Mihai Moldovan (ionic@ionic.de) took a look at your logfiles. He suggested you run a compile of nx-libs using the "typescript" logging tool, and to post the logfile(s) here.
Two more bits of information:
The message "Loop: Assuming NX client location '/home/arnolds/opt/x2go/bin/x2goclient'." looked weird to Mihai. I'm not sure what exactly he was referring to, the path of X2GoClient residing in a subdirectory of your home directory, maybe? Is that intentional?
It would be interesting to see what happens when you connect to an MPA-Linux-based X2GoServer from an Ubuntu Client. You tested it from an Ubuntu client to an MPA server, and from an MPA client to an MPA server. Testing it in the other direction would help to rule out or confirm that it is an issue that requires an MPA Linux on both ends to occur.
Kind Regards, Stefan Baur
Dear Mr. Baur,
you'll find the log of my last build enclosed (STAGE1-nx-libs.log.bz2). Additionally there is a patch file which adjusts some paths and enables logging at different places (x2go-patch). Finally you'll find a listing of the directory structure (x2go-dir-struct). Perhaps I'm missing something in my installation?
Yes, the x2goclient is installed in my home dir intentionally. Just to play with statically linked qt-4.8.6 libs in an otherwise qt-5 based system. Is anything wrong with this location? (The problem is the same if I try to connect from a qt-4.8.6 based system with a x2goclient built with shared qt libs).
Cheers,
H.-A. Arnolds
Hello,
I'm quite sure that my first guess is the real reason for my problem: The fake cookie is never saved to ~/.Xauthority.
When I look at the server side,
XOpenDisplay() X11TransConnectDisplay() GetAuthorization(..., auth_namep, auth_namelenp, auth_datap, auth_datalenp)
I see that GetAuthorization() doesn't return any values in xauth_name and xauth_data (which I can even verify with a simple "xauth list"). Debug output shows: in GetAuthorizatioin() xauth_name: (null), xauth_data: (null). in GetAuthorizatioin() family: 256, saddrlen: 6, saddr: ncd-11, strlen (dpynumbuf): 2, dpynumbuf: 50, authptr: (null).
Can anybody give me a hint where (in the code) the fake cookie is stored into ~/.Xauthority please?
Thanks a lot,
Ado