Am 27.07.2011 14:33, schrieb Mike Gabriel:

Hi Alex,

On Mi 27 Jul 2011 13:52:46 CEST Oleksandr Shneyder wrote:

...

Am 22.07.2011 06:38, schrieb John A. Sullivan III:

...

I believe I have tested this on both Linux and Windows - becoming a bit of a blur after a long hot day!. In previous versions of X2GoClient, I could open multiple instances and connect to multiple different X2Go Server simultaneously. It was not official and it generated a few errors but it worked. This is actually a highly desirable feature for a possible very large account of ours.

For some reason, that has stopped working in 3.99. It did not work in 3.0.1.18 either. It does work in Pyhoca so I do not think it is an impossibility. If at all possible, we would like to see this functionality restored - preferably officially but even accidentally as it was would do :) Thanks - John

---

X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev

Hello John,

Unfortunately, I can't reproduce this. I was able to start a several sessions simultaneously on debian and win7, see screen shots:

http://www.x2go.org/screenshots/multisess-debian.png http://www.x2go.org/screenshots/multisess-win7.png

Thanks for all your testing!!!!

If I recall John correctly, her meant:

start x2goclient, connect to session A as user A start another x2goclient, also connect to session A as user A (that is a second session as the same user to the same server)

John, could you please cross-check this?

Thanks, Mike

As I understood, John meant, connecting with user A to server A, start second client and connecting as user B to server B. But it does not matter, I've tried all variants:

A->A B->B

A->A B->A

A->A A->B

A->A A->A

regards, alex

Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team

email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de

--> X2go - everywhere@home

On Wed, 2011-07-27 at 09:33 -0400, John A. Sullivan III wrote:

On Wed, 2011-07-27 at 14:41 +0200, Oleksandr Shneyder wrote:

...

Am 27.07.2011 14:33, schrieb Mike Gabriel:

...

Hi Alex,

On Mi 27 Jul 2011 13:52:46 CEST Oleksandr Shneyder wrote:

...

Am 22.07.2011 06:38, schrieb John A. Sullivan III:

...

I believe I have tested this on both Linux and Windows - becoming a bit of a blur after a long hot day!. In previous versions of X2GoClient, I could open multiple instances and connect to multiple different X2Go Server simultaneously. It was not official and it generated a few errors but it worked. This is actually a highly desirable feature for a possible very large account of ours.

For some reason, that has stopped working in 3.99. It did not work in 3.0.1.18 either. It does work in Pyhoca so I do not think it is an impossibility. If at all possible, we would like to see this functionality restored - preferably officially but even accidentally as it was would do :) Thanks - John

---

X2go-Dev mailing list X2go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev

Hello John,

Unfortunately, I can't reproduce this. I was able to start a several sessions simultaneously on debian and win7, see screen shots:

http://www.x2go.org/screenshots/multisess-debian.png http://www.x2go.org/screenshots/multisess-win7.png

Thanks for all your testing!!!!

If I recall John correctly, her meant:

start x2goclient, connect to session A as user A start another x2goclient, also connect to session A as user A (that is a second session as the same user to the same server)

John, could you please cross-check this?

Thanks, Mike

As I understood, John meant, connecting with user A to server A, start second client and connecting as user B to server B. But it does not matter, I've tried all variants:

A->A B->B

A->A B->A

A->A A->B

A->A A->A

regards, alex <snip> Oleksandr is correct - two separate users connected to two separate X2Go servers. I can do the initial connection but, within a few seconds, the first session times out. I've seen this myself on Debian and Windows XP and another tester confirmed it on Windows 7 64 bit. I'll try to dig out more details. Thanks very much for investigating - John <snip> OK - now this is bizarre - after days of it not working on Squeeze, it decided to work today when I tested. All right, who changed things while I wasn't looking! I'll give Windows a test later but I do know I wasn't imagining this and we had another tester confirm the same phenomenon. I'll check again with them, too. Thanks - John

On Wed, 2011-07-27 at 12:37 -0400, John A. Sullivan III wrote:

On Wed, 2011-07-27 at 12:18 -0400, John A. Sullivan III wrote:

...

On Wed, 2011-07-27 at 09:33 -0400, John A. Sullivan III wrote:

...

On Wed, 2011-07-27 at 14:41 +0200, Oleksandr Shneyder wrote:

...

Am 27.07.2011 14:33, schrieb Mike Gabriel:

...

Hi Alex,

On Mi 27 Jul 2011 13:52:46 CEST Oleksandr Shneyder wrote:

...

Am 22.07.2011 06:38, schrieb John A. Sullivan III: > I believe I have tested this on both Linux and Windows - becoming a bit > of a blur after a long hot day!. In previous versions of X2GoClient, I > could open multiple instances and connect to multiple different X2Go > Server simultaneously. It was not official and it generated a few > errors but it worked. This is actually a highly desirable feature for a > possible very large account of ours. > > For some reason, that has stopped working in 3.99. It did not work in > 3.0.1.18 either. It does work in Pyhoca so I do not think it is an > impossibility. If at all possible, we would like to see this > functionality restored - preferably officially but even accidentally as > it was would do :) Thanks - John > > _______________________________________________ > X2go-Dev mailing list > X2go-Dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/x2go-dev

Hello John,

Unfortunately, I can't reproduce this. I was able to start a several sessions simultaneously on debian and win7, see screen shots:

http://www.x2go.org/screenshots/multisess-debian.png http://www.x2go.org/screenshots/multisess-win7.png

Thanks for all your testing!!!!

If I recall John correctly, her meant:

start x2goclient, connect to session A as user A start another x2goclient, also connect to session A as user A (that is a second session as the same user to the same server)

John, could you please cross-check this?

Thanks, Mike

As I understood, John meant, connecting with user A to server A, start second client and connecting as user B to server B. But it does not matter, I've tried all variants:

A->A B->B

A->A B->A

A->A A->B

A->A A->A

regards, alex <snip> Oleksandr is correct - two separate users connected to two separate X2Go servers. I can do the initial connection but, within a few seconds, the first session times out. I've seen this myself on Debian and Windows XP and another tester confirmed it on Windows 7 64 bit. I'll try to dig out more details. Thanks very much for investigating - John <snip> OK - now this is bizarre - after days of it not working on Squeeze, it decided to work today when I tested. All right, who changed things while I wasn't looking! I'll give Windows a test later but I do know I wasn't imagining this and we had another tester confirm the same phenomenon. I'll check again with them, too. Thanks - John <snip> The bizarreness continues. Now it works in Windows, too. Still waiting to hear back from the other tester. Other things have suddenly started to work, too, as I'll report separately, yet we've done nothing to change anything in our environment :( <snip> I can confirm this is still a problem for some. The below report is from a windows 7/64 user. How do we begin troubleshooting? Thanks - John

Same problem - soon after starting the second window, the system comes up with an error message: "No response received from the remote server. Do you want to terminate the current session?". If one selects No, one is able to connect and use the current (second) session, but it immediately kills the previously started (first) session, with the message "The connection with the remote session was shut down. Please check the state of your network connection."

If one then attempts to start another (third) session, it generates the second error message again, which prevents a new session from starting, but does leave the existing (second) sesson running.

Not sure if there is a clue here, but when trying to log into the third session (when the session-locking dialog box comes up), I note that the number of black bullets coming up is different from the number of keys that I have pressed - and that if one tries to erase them with the backspace key, each press generates another black bullet.

So no progress viewed from this end, I regret.

2011/7/28 John A. Sullivan III <jsullivan@opensourcedevel.com>: <snip>

...

...

...

...

...

>>> I believe I have tested this on both Linux and Windows - becoming a bit >>> of a blur after a long hot day!.  In previous versions of X2GoClient, I >>> could open multiple instances and connect to multiple different X2Go >>> Server simultaneously.  It was not official and it generated a few >>> errors but it worked.  This is actually a highly desirable feature for a >>> possible very large account of ours. >>> >>> For some reason, that has stopped working in 3.99.  It did not work in >>> 3.0.1.18 either.  It does work in Pyhoca so I do not think it is an >>> impossibility.  If at all possible, we would like to see this >>> functionality restored - preferably officially but even accidentally as >>> it was would do :)  Thanks - John

One thing I've had problems with in the past is TCP port conflicts. When x2go starts a session, it always uses a TCP port above 30000, decided by x2gostartagent on the server side. If you start multiple sessions from one client to several different servers, wouldn't that create a port conflict sooner or later? Maybe that is what you've seen, with conflicts causing sessions to terminate.

Example, x2go on client CA connects (a ssh tunnel) to server SA on port 30001 (-L 30001:localhost:30001 user@SA). You then start another session from client A to server B, also using port 30001 (-L 30001:localhost:30001 user@SB). Doesn't that create a port conflict on client CA? You have two separate ssh tunnels trying to use the same TCP port on the client.

The problems I've seen have been when client CA has connected to server SA, which then has been used as a "gateway client" to connect to other servers. Sometimes the session between CA and SA used port 30001 and the session(s) between SA and other server SB also used port 30001. I could always set up the sessions, but if I tried to reconnect from client CA to SA I got an error message about ”the remote proxy closed the connection while negotiating …”. My workaround was to separate the port ranges used by x2gostartagent on the servers; server SA now uses 30001-, server SB uses 30101-, server SC uses 30201- and so on. No more conflicts.

I've been trying to think of some way to make x2go automatically only use free ports, but since there are possibly several clients and servers involved in multiple incoming and outgoing sessions, the only safe way I've come up with would be to register used ports (or reserve port ranges) on a shared resource somewhere, which would make all x2go clients and servers dependent on that one resource.

Cheers, Daniel

Hi Daniel,

On Fr 29 Jul 2011 07:24:40 CEST Daniel Lindgren wrote:

[...]

I've been trying to think of some way to make x2go automatically only use free ports, but since there are possibly several clients and servers involved in multiple incoming and outgoing sessions, the only safe way I've come up with would be to register used ports (or reserve port ranges) on a shared resource somewhere, which would make all x2go clients and servers dependent on that one resource.

What you have been describing above is the old, well known
NXServer/NXClient problem.

To my experience it does not exist with X2go (at least not with
pyhoca-gui ;-) ).

The connecting stuff is a bit tricky...

• x2goclient connects via SSH and launches either x2gostartagent or x2goresume-session

• x2gostartagent will try to detect a free server-side port >30000. This port is put into the session database table. (Make sure you do not have other server-side stuff running that claims ports between 30000 and 30000++.

• x2goresume-session will pick the formerly detected port from the session database table (i.e. SQLite or postgres) and presume it is still unused (as it should be, unless unused by X2go -> x2gostartagent avoids claiming ports that are in the database marked with S (suspended) or R (running) state

• say we detect a free server-side port: 30015: x2gostartagent will
  launch the XNest-like x2goagent XServer, listening for incoming connections on port localhost:300015.

• x2goclient now tries to set up a forwarding tunnel from client to server (-L 30000:localhost:30015)

• if the local port 30000 (the first one in the above expression) is already in use, it simply selects another port. Each selected port is
  probed before usage. That is done by x2goclient.

• say we end up with -L 30028:localhost:30015

The problem you observe: ”the remote proxy closed the connection while
negotiating …” to my point of view stems from uncleanly closed SSH
connections. Try to restart the SSH daemon when this error occurs and
you should be able to connect again. This error can also be caused by
the sound/sshfs tunnels. Here the same cause applies: unclean shutdown
of SSH connections.

Reasons may be:

o unclean x2goclient/pyhoca-gui code o line failures (so the clients do not get the chance to cancel the port forwarding requests...)

You may do the following to debug:

o try if the problem occurs in the same way when you use pyhoca-gui/-cli o pyhoca-gui (i.e. python-x2go) tries to restore the mal-closure of SSH port forwardings... You may try to resume a session twice, the second time you should get a session window

The addressed issue was a big problem for Python X2go before version
0.1.0.0. It took me quite some sleepness nights to get rid of it by
90%+.

Greets, Mike

--

DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...

On Fri, 2011-07-29 at 10:21 +0200, Mike Gabriel wrote:

Hi Daniel,

On Fr 29 Jul 2011 07:24:40 CEST Daniel Lindgren wrote:

...

[...]

I've been trying to think of some way to make x2go automatically only use free ports, but since there are possibly several clients and servers involved in multiple incoming and outgoing sessions, the only safe way I've come up with would be to register used ports (or reserve port ranges) on a shared resource somewhere, which would make all x2go clients and servers dependent on that one resource.

What you have been describing above is the old, well known
NXServer/NXClient problem.

To my experience it does not exist with X2go (at least not with
pyhoca-gui ;-) ).

The connecting stuff is a bit tricky...

• x2goclient connects via SSH and launches either x2gostartagent or x2goresume-session

• x2gostartagent will try to detect a free server-side port >30000. This port is put into the session database table. (Make sure you do not have other server-side stuff running that claims ports between 30000 and 30000++.

• x2goresume-session will pick the formerly detected port from the session database table (i.e. SQLite or postgres) and presume it is still unused (as it should be, unless unused by X2go -> x2gostartagent avoids claiming ports that are in the database marked with S (suspended) or R (running) state

• say we detect a free server-side port: 30015: x2gostartagent will
  launch the XNest-like x2goagent XServer, listening for incoming connections on port localhost:300015.

• x2goclient now tries to set up a forwarding tunnel from client to server (-L 30000:localhost:30015)

• if the local port 30000 (the first one in the above expression) is already in use, it simply selects another port. Each selected port is
  probed before usage. That is done by x2goclient.

• say we end up with -L 30028:localhost:30015

The problem you observe: ”the remote proxy closed the connection while
negotiating …” to my point of view stems from uncleanly closed SSH
connections. Try to restart the SSH daemon when this error occurs and
you should be able to connect again. This error can also be caused by
the sound/sshfs tunnels. Here the same cause applies: unclean shutdown
of SSH connections.

Reasons may be:

o unclean x2goclient/pyhoca-gui code o line failures (so the clients do not get the chance to cancel the port forwarding requests...)

You may do the following to debug:

o try if the problem occurs in the same way when you use pyhoca-gui/-cli o pyhoca-gui (i.e. python-x2go) tries to restore the mal-closure of SSH port forwardings... You may try to resume a session twice, the second time you should get a session window

The addressed issue was a big problem for Python X2go before version
0.1.0.0. It took me quite some sleepness nights to get rid of it by
90%+. <snip> I continue to have a devil of a time with this. It seems like

• x2goclient now tries to set up a forwarding tunnel from client to server (-L 30000:localhost:30015)
• if the local port 30000 (the first one in the above expression) is already in use, it simply selects another port. Each selected port is
  probed before usage. That is done by x2goclient.

isn't working. In the past, using older clients, we would generate error messages about a problem connecting on port 30001 but the sessions would all still work.

We are no longer seeing those errors. Instead, the sessions are rudely dropped. I've restarted all the X2Go servers and clients after deleting all the old session directories on both. Still no success. Here are the details.

In our environment, we have a single PostgreSQL database for all the X2Go servers. There is one X2Go server for each user (x2go client). I connect to the first server and I start a valid session. I am using ports 30001 - 30003 on the server side and 30004 on the client side: tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN

Server User Status Last Connection Run Time Display Client GP SP FP Context Load RSS VSZ jasiii jasiii S 01.08.11 12:45:12 0d 0h 2m 51 74.75.231.235 30001 30002 30003 40016 0.04 434.2Mb 8.4Gb

I start a second x2goclient to connect to the second server. The client is listening on port 30005: tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:30005 0.0.0.0:* LISTEN

The server side is using the same ports as the other x2go server: Server User Status Last Connection Run Time Display Client GP SP FP Context Load RSS VSZ

cuser-a6 cuser-a6 R 01.08.11 12:45:06 0d 0h 1m 53 74.75.231.235 30001 30002 30003 40046 0.01 315.3Mb 5.9Gb jasiii jasiii S 01.08.11 12:45:12 0d 0h 2m 51 74.75.231.235 30001 30002 30003 40016 0.04 434.2Mb 8.4Gb

This is where the original session dies. If I understand the logic, shouldn't there be a mapping from 30004 to localhost:30001 for the first session and another from 30005 to localhost:30001 for the second session? Why is the first session dropped as if there was no network connectivity?

This is what the server side session.log says: Error: Failure reading from the peer proxy. Error: Connection with remote peer broken. Error: Please check the state of your network and retry. Session: Display failure detected at 'Mon Aug 1 12:45:07 2011'.

Sometimes, it can get really ugly: Error: Failure reading from the peer proxy. Error: Connection with remote peer broken. Error: Please check the state of your network and retry. nxagentReconnectFailedFonts: WARNING! Font server tunneling not retrieved. *** glibc detected *** /usr/lib/x2go/x2goagent: corrupted double-linked list: 0x0000000001131d10 *** ======= Backtrace: ========= /lib/libc.so.6(+0x71ad6)[0x7f05278fbad6] /lib/libc.so.6(+0x71f4d)[0x7f05278fbf4d] /lib/libc.so.6(+0x73418)[0x7f05278fd418] /lib/libc.so.6(cfree+0x6c)[0x7f052790084c] /usr/lib/x2go/libX11.so.6(XFreeFontPath+0x1d)[0x7f05295ff8dd] /usr/lib/x2go/x2goagent[0x485af8] /usr/lib/x2go/x2goagent[0x4ab421] /usr/lib/x2go/x2goagent[0x4ab840] /usr/lib/x2go/x2goagent[0x4ab95b] /usr/lib/x2go/x2goagent[0x48cb75] /usr/lib/x2go/x2goagent[0x450bbb] /usr/lib/x2go/x2goagent[0x45c65e] /usr/lib/x2go/x2goagent[0x429595] /usr/lib/x2go/x2goagent[0x455863] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f05278a8c4d] /usr/lib/x2go/x2goagent[0x40aa69]

The client side says this: Loop: WARNING! Connected to remote version 3.4.0 with local version 3.5.0. Loop: WARNING! Unrecognized session type 'unix-kde-depth_24'. Assuming agent session. Proxy: PANIC! Failure reading from the peer proxy on FD#5. Loop: PANIC! No shutdown of proxy link performed by remote proxy.

So what changed? Is this an issue with libssh? Thanks - John

On Mon, 2011-08-01 at 14:38 -0400, John A. Sullivan III wrote:

On Mon, 2011-08-01 at 13:30 -0400, John A. Sullivan III wrote:

...

On Fri, 2011-07-29 at 10:21 +0200, Mike Gabriel wrote:

...

Hi Daniel,

On Fr 29 Jul 2011 07:24:40 CEST Daniel Lindgren wrote:

...

[...]

I've been trying to think of some way to make x2go automatically only use free ports, but since there are possibly several clients and servers involved in multiple incoming and outgoing sessions, the only safe way I've come up with would be to register used ports (or reserve port ranges) on a shared resource somewhere, which would make all x2go clients and servers dependent on that one resource.

What you have been describing above is the old, well known
NXServer/NXClient problem.

To my experience it does not exist with X2go (at least not with
pyhoca-gui ;-) ).

The connecting stuff is a bit tricky...

• x2goclient connects via SSH and launches either x2gostartagent or x2goresume-session

• x2gostartagent will try to detect a free server-side port >30000. This port is put into the session database table. (Make sure you do not have other server-side stuff running that claims ports between 30000 and 30000++.

• x2goresume-session will pick the formerly detected port from the session database table (i.e. SQLite or postgres) and presume it is still unused (as it should be, unless unused by X2go -> x2gostartagent avoids claiming ports that are in the database marked with S (suspended) or R (running) state

• say we detect a free server-side port: 30015: x2gostartagent will
  launch the XNest-like x2goagent XServer, listening for incoming connections on port localhost:300015.

• x2goclient now tries to set up a forwarding tunnel from client to server (-L 30000:localhost:30015)

• if the local port 30000 (the first one in the above expression) is already in use, it simply selects another port. Each selected port is
  probed before usage. That is done by x2goclient.

• say we end up with -L 30028:localhost:30015

The problem you observe: ”the remote proxy closed the connection while
negotiating …” to my point of view stems from uncleanly closed SSH
connections. Try to restart the SSH daemon when this error occurs and
you should be able to connect again. This error can also be caused by
the sound/sshfs tunnels. Here the same cause applies: unclean shutdown
of SSH connections.

Reasons may be:

o unclean x2goclient/pyhoca-gui code o line failures (so the clients do not get the chance to cancel the port forwarding requests...)

You may do the following to debug:

o try if the problem occurs in the same way when you use pyhoca-gui/-cli o pyhoca-gui (i.e. python-x2go) tries to restore the mal-closure of SSH port forwardings... You may try to resume a session twice, the second time you should get a session window

The addressed issue was a big problem for Python X2go before version
0.1.0.0. It took me quite some sleepness nights to get rid of it by
90%+. <snip> I continue to have a devil of a time with this. It seems like

• x2goclient now tries to set up a forwarding tunnel from client to server (-L 30000:localhost:30015)
• if the local port 30000 (the first one in the above expression) is already in use, it simply selects another port. Each selected port is
  probed before usage. That is done by x2goclient.

isn't working. In the past, using older clients, we would generate error messages about a problem connecting on port 30001 but the sessions would all still work.

We are no longer seeing those errors. Instead, the sessions are rudely dropped. I've restarted all the X2Go servers and clients after deleting all the old session directories on both. Still no success. Here are the details.

In our environment, we have a single PostgreSQL database for all the X2Go servers. There is one X2Go server for each user (x2go client). I connect to the first server and I start a valid session. I am using ports 30001 - 30003 on the server side and 30004 on the client side: tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN

Server User Status Last Connection Run Time Display Client GP SP FP Context Load RSS VSZ jasiii jasiii S 01.08.11 12:45:12 0d 0h 2m 51 74.75.231.235 30001 30002 30003 40016 0.04 434.2Mb 8.4Gb

I start a second x2goclient to connect to the second server. The client is listening on port 30005: tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:30005 0.0.0.0:* LISTEN

The server side is using the same ports as the other x2go server: Server User Status Last Connection Run Time Display Client GP SP FP Context Load RSS VSZ

cuser-a6 cuser-a6 R 01.08.11 12:45:06 0d 0h 1m 53 74.75.231.235 30001 30002 30003 40046 0.01 315.3Mb 5.9Gb jasiii jasiii S 01.08.11 12:45:12 0d 0h 2m 51 74.75.231.235 30001 30002 30003 40016 0.04 434.2Mb 8.4Gb

This is where the original session dies. If I understand the logic, shouldn't there be a mapping from 30004 to localhost:30001 for the first session and another from 30005 to localhost:30001 for the second session? Why is the first session dropped as if there was no network connectivity?

This is what the server side session.log says: Error: Failure reading from the peer proxy. Error: Connection with remote peer broken. Error: Please check the state of your network and retry. Session: Display failure detected at 'Mon Aug 1 12:45:07 2011'.

Sometimes, it can get really ugly: Error: Failure reading from the peer proxy. Error: Connection with remote peer broken. Error: Please check the state of your network and retry. nxagentReconnectFailedFonts: WARNING! Font server tunneling not retrieved. *** glibc detected *** /usr/lib/x2go/x2goagent: corrupted double-linked list: 0x0000000001131d10 *** ======= Backtrace: ========= /lib/libc.so.6(+0x71ad6)[0x7f05278fbad6] /lib/libc.so.6(+0x71f4d)[0x7f05278fbf4d] /lib/libc.so.6(+0x73418)[0x7f05278fd418] /lib/libc.so.6(cfree+0x6c)[0x7f052790084c] /usr/lib/x2go/libX11.so.6(XFreeFontPath+0x1d)[0x7f05295ff8dd] /usr/lib/x2go/x2goagent[0x485af8] /usr/lib/x2go/x2goagent[0x4ab421] /usr/lib/x2go/x2goagent[0x4ab840] /usr/lib/x2go/x2goagent[0x4ab95b] /usr/lib/x2go/x2goagent[0x48cb75] /usr/lib/x2go/x2goagent[0x450bbb] /usr/lib/x2go/x2goagent[0x45c65e] /usr/lib/x2go/x2goagent[0x429595] /usr/lib/x2go/x2goagent[0x455863] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f05278a8c4d] /usr/lib/x2go/x2goagent[0x40aa69]

The client side says this: Loop: WARNING! Connected to remote version 3.4.0 with local version 3.5.0. Loop: WARNING! Unrecognized session type 'unix-kde-depth_24'. Assuming agent session. Proxy: PANIC! Failure reading from the peer proxy on FD#5. Loop: PANIC! No shutdown of proxy link performed by remote proxy.

So what changed? Is this an issue with libssh? Thanks - John <snip> I'm not sure where it is coming from but sometimes, not all the time, we receive a message such as:

channel_open_session failed - Received SSH_MSG_DISCONNECT: Received ieof for nonexistent channel 0

Lots of Internet research didn't produce a lot of helpful information on the error.

On the server side ssh logs I see: Aug 1 12:45:07 jasiii sshd[22977]: error: connect_to localhost port 30001: failed. Aug 1 12:45:07 jasiii sshd[22977]: channel_by_id: 0: bad id: channel free

I do not see anything of interest in the client ssh logs.

Out of curiosity, I tried reproducing this manually. Both systems where I can reliably reproduce this problem have a local smtp daemon. I did a "ssh -p <some hidden port> -L 40015:localhost:25 user1@machine1" and a "ssh -p <some hidden port> -L 40016:localhost:25 user2@machine2". I was able to telnet to each on port 40015 and 40016 without an issue or one disconnecting the other. Could there be a problem in the way libssh is handling multiple channels? - John

_<snip> Correction - we are getting error messages about the connection on 30001:

Aug 1 12:32:21 jasiii sshd[11630]: error: connect_to localhost port 30001: failed. Aug 1 12:32:21 jasiii sshd[11630]: channel_by_id: 0: bad id: channel free

On Mon, 2011-08-01 at 22:58 +0200, Mike Gabriel wrote:

Hi John,

On Mo 01 Aug 2011 20:43:23 CEST "John A. Sullivan III" wrote:

...

...

Out of curiosity, I tried reproducing this manually. Both systems where I can reliably reproduce this problem have a local smtp daemon. I did a "ssh -p <some hidden port> -L 40015:localhost:25 user1@machine1" and a "ssh -p <some hidden port> -L 40016:localhost:25 user2@machine2". I was able to telnet to each on port 40015 and 40016 without an issue or one disconnecting the other. Could there be a problem in the way libssh is handling multiple channels? - John

BRILLIANT, that is it!!! Debian squeeze still uses libssh-4 0.4.5, but
x2goclient needs a patch (sent to libssh upstream by Oleksandr) that
has entered libssh-4 with version 0.4.7.

I have already uploaded a Debian squeeze version of libssh-4 0.4.7. I
am also re-building x2goclient against libssh-4 0.4.7.

Sorry, I presumed that the newer libs were already in Debian squeeze...

Packages will be available soon on packages.x2go.org. <snip> So if we are running older versions of X2Go server, what do we update? I assume the libssh on the client. Does this imply there will be a new Windows client? It looks like it is still 3.99 on the wiki. Thanks - John