Hello, all. We were delighted to see Mihai's find about the overflow as we do have client whose Mac always freezes if the screen saver kicks in. We are eager to upgrade her but are unsure of the current state of the Mac client. Is there a production ready version with this fix available? If so, which one? Thanks - John
Hi John,
On Di 06 Mär 2012 01:06:55 CET "John A. Sullivan III" wrote:
Hello, all. We were delighted to see Mihai's find about the overflow as we do have client whose Mac always freezes if the screen saver kicks in. We are eager to upgrade her but are unsure of the current state of the Mac client. Is there a production ready version with this fix available? If so, which one? Thanks - John
You should wait for 3.99.1.1, I guess. There is an X-Server detection
fix (using unix socket, not TCP to connect to the local X-Server) in it.
Mihai, is anything else needed to be patched into x2goclient.git
currently for Mac OS X?
Thanks, 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...
Hi Mike,
- On 06.03.2012 09:48 AM, Mike Gabriel wrote:
You should wait for 3.99.1.1, I guess. There is an X-Server detection fix (using unix socket, not TCP to connect to the local X-Server) in it.
Probably. :) I do have a got git-snapshot with this fix in place (or could easily fetch the newest changes and rebuild), but this "production-ready" requirement makes me hesitate. ;)
Mihai, is anything else needed to be patched into x2goclient.git currently for Mac OS X?
Depends... here's a list of problems I FOUND (but not fixed):
- sometimes, I have to resume a session, restart the client, suspend the session and resume it again for it to be usable (first time resuming will just close the connection to the server), BUT IIRC this happens on Linux, too, so I can't actually blame the OS X part... (plus, it only happens sometimes. :()
- Client seems to be working fine for me on OS X 10.6/Snow Leopard. But:
problem, but at least I've got some debug output.
- has some weird memleak on OSX 10.5 (not always, again...)
- Stephan reported problems on 10.7 which seem to be SSH-related, I've gotta take a look at that, no idea if I can figure it out though. Looks like a libssh
No concrete code fixes from my side yet though.
Best regards,
Mihai
On Tue, 2012-03-06 at 18:21 +0100, Mihai Moldovan wrote:
Hi Mike,
- On 06.03.2012 09:48 AM, Mike Gabriel wrote:
You should wait for 3.99.1.1, I guess. There is an X-Server detection fix (using unix socket, not TCP to connect to the local X-Server) in it.
Probably. :) I do have a got git-snapshot with this fix in place (or could easily fetch the newest changes and rebuild), but this "production-ready" requirement makes me hesitate. ;)
Mihai, is anything else needed to be patched into x2goclient.git currently for Mac OS X?
Depends... here's a list of problems I FOUND (but not fixed):
- sometimes, I have to resume a session, restart the client, suspend the session and resume it again for it to be usable (first time resuming will just close the connection to the server), BUT IIRC this happens on Linux, too, so I can't actually blame the OS X part... (plus, it only happens sometimes. :()
- Client seems to be working fine for me on OS X 10.6/Snow Leopard. But: problem, but at least I've got some debug output.
- has some weird memleak on OSX 10.5 (not always, again...)
- Stephan reported problems on 10.7 which seem to be SSH-related, I've gotta take a look at that, no idea if I can figure it out though. Looks like a libssh
No concrete code fixes from my side yet though. <snip> I have noticed that problem in Linux. I think it is an SSH timing issue. The connecting, suspending, reconnecting is not actually doing anything, I believe, except functioning as a rudimentary clock. If one just waits five minutes after being abruptly disconnected, all reconnects fine :( - John
Hi guys,
On Di 06 Mär 2012 18:48:12 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 18:21 +0100, Mihai Moldovan wrote:
- sometimes, I have to resume a session, restart the client,
suspend the session and resume it again for it to be usable (first time resuming will
just close the connection to the server), BUT IIRC this happens on Linux, too, so I can't actually blame the OS X part... (plus, it only happens sometimes. :()
<snip> I have noticed that problem in Linux. I think it is an SSH timing issue. The connecting, suspending, reconnecting is not actually doing anything, I believe, except functioning as a rudimentary clock. If one just waits five minutes after being abruptly disconnected, all reconnects fine :( - John
When writing the connection/tunneling code of python-x2go I observed
something similar. The problem with port forwarding requests (both
reverse or non-reverse) is a situation when (after suspend) the ports
do no get closed properly. We always have to make sure to properly
cancel port forwarding requests before we disconnect from a SSH session.
Thanks+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 Tue, 2012-03-06 at 22:55 +0100, Mike Gabriel wrote:
Hi guys,
On Di 06 Mär 2012 18:48:12 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 18:21 +0100, Mihai Moldovan wrote:
- sometimes, I have to resume a session, restart the client,
suspend the session and resume it again for it to be usable (first time resuming will
just close the connection to the server), BUT IIRC this happens on Linux, too, so I can't actually blame the OS X part... (plus, it only happens sometimes. :()<snip> I have noticed that problem in Linux. I think it is an SSH timing issue. The connecting, suspending, reconnecting is not actually doing anything, I believe, except functioning as a rudimentary clock. If one just waits five minutes after being abruptly disconnected, all reconnects fine :( - John
When writing the connection/tunneling code of python-x2go I observed
something similar. The problem with port forwarding requests (both
reverse or non-reverse) is a situation when (after suspend) the ports
do no get closed properly. We always have to make sure to properly
cancel port forwarding requests before we disconnect from a SSH session. <snip> So how should we respond if the network connection is broken uncleanly, e.g., the WAN or Internet connection drops or the client computer crashes?
Hi John,
On Di 06 Mär 2012 23:00:35 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 22:55 +0100, Mike Gabriel wrote:
Hi guys,
On Di 06 Mär 2012 18:48:12 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 18:21 +0100, Mihai Moldovan wrote:
- sometimes, I have to resume a session, restart the client, suspend the session and resume it again for it to be usable (first time resuming will just close the connection to the server), BUT IIRC this happens on Linux, too,
so I can't actually blame the OS X part... (plus, it only happens sometimes. :()<snip> I have noticed that problem in Linux. I think it is an SSH timing issue. The connecting, suspending, reconnecting is not actually doing anything, I believe, except functioning as a rudimentary clock. If one just waits five minutes after being abruptly disconnected, all reconnects fine :( - John
When writing the connection/tunneling code of python-x2go I observed something similar. The problem with port forwarding requests (both reverse or non-reverse) is a situation when (after suspend) the ports do no get closed properly. We always have to make sure to properly cancel port forwarding requests before we disconnect from a SSH session. <snip> So how should we respond if the network connection is broken uncleanly, e.g., the WAN or Internet connection drops or the client computer crashes?
What I do is, I try to connect and if that fails, I try to cancel the
port forwarding requests. This mostly works and sometimes also fails.
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 Tue, 2012-03-06 at 23:12 +0100, Mike Gabriel wrote:
Hi John,
On Di 06 Mär 2012 23:00:35 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 22:55 +0100, Mike Gabriel wrote:
Hi guys,
On Di 06 Mär 2012 18:48:12 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 18:21 +0100, Mihai Moldovan wrote:
- sometimes, I have to resume a session, restart the client, suspend the session and resume it again for it to be usable (first time resuming will just close the connection to the server), BUT IIRC this happens on Linux, too,
so I can't actually blame the OS X part... (plus, it only happens sometimes. :()<snip> I have noticed that problem in Linux. I think it is an SSH timing issue. The connecting, suspending, reconnecting is not actually doing anything, I believe, except functioning as a rudimentary clock. If one just waits five minutes after being abruptly disconnected, all reconnects fine :( - John
When writing the connection/tunneling code of python-x2go I observed something similar. The problem with port forwarding requests (both reverse or non-reverse) is a situation when (after suspend) the ports do no get closed properly. We always have to make sure to properly cancel port forwarding requests before we disconnect from a SSH session. <snip> So how should we respond if the network connection is broken uncleanly, e.g., the WAN or Internet connection drops or the client computer crashes?
What I do is, I try to connect and if that fails, I try to cancel the
port forwarding requests. This mostly works and sometimes also fails. <snip> Yes, but that is what we do as users. What can we do as developers to detect and correct this situation so users do not have to do this? Thanks - John
Hi John,
On Di 06 Mär 2012 23:20:54 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 23:12 +0100, Mike Gabriel wrote:
Hi John,
On Di 06 Mär 2012 23:00:35 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 22:55 +0100, Mike Gabriel wrote:
Hi guys,
On Di 06 Mär 2012 18:48:12 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 18:21 +0100, Mihai Moldovan wrote:
- sometimes, I have to resume a session, restart the client, suspend the session and resume it again for it to be usable (first time resuming will just close the connection to the server), BUT IIRC this happens on Linux, too, so I can't actually blame the OS X part... (plus, it only happens sometimes. :()
<snip> I have noticed that problem in Linux. I think it is an SSH timing issue. The connecting, suspending, reconnecting is not actually doing anything, I believe, except functioning as a rudimentary clock. If one just waits five minutes after being abruptly disconnected, all reconnects fine :( - John
When writing the connection/tunneling code of python-x2go I observed something similar. The problem with port forwarding requests (both reverse or non-reverse) is a situation when (after suspend) the ports do no get closed properly. We always have to make sure to properly cancel port forwarding requests before we disconnect from a SSH session. <snip> So how should we respond if the network connection is broken uncleanly, e.g., the WAN or Internet connection drops or the client computer crashes?
What I do is, I try to connect and if that fails, I try to cancel the port forwarding requests. This mostly works and sometimes also fails. <snip> Yes, but that is what we do as users. What can we do as developers to detect and correct this situation so users do not have to do this? Thanks - John
I have implemented this in the python-x2go code. I am saying this from
the developer's point of view.
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 Tue, 2012-03-06 at 23:26 +0100, Mike Gabriel wrote:
Hi John,
On Di 06 Mär 2012 23:20:54 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 23:12 +0100, Mike Gabriel wrote:
Hi John,
On Di 06 Mär 2012 23:00:35 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 22:55 +0100, Mike Gabriel wrote:
Hi guys,
On Di 06 Mär 2012 18:48:12 CET "John A. Sullivan III" wrote:
On Tue, 2012-03-06 at 18:21 +0100, Mihai Moldovan wrote: > - sometimes, I have to resume a session, restart the client, > suspend the session > and resume it again for it to be usable (first time resuming will > just close the > connection to the server), BUT IIRC this happens on Linux, too, so I can't > actually blame the OS X part... (plus, it only happens sometimes. :()
<snip> I have noticed that problem in Linux. I think it is an SSH timing issue. The connecting, suspending, reconnecting is not actually doing anything, I believe, except functioning as a rudimentary clock. If one just waits five minutes after being abruptly disconnected, all reconnects fine :( - John
When writing the connection/tunneling code of python-x2go I observed something similar. The problem with port forwarding requests (both reverse or non-reverse) is a situation when (after suspend) the ports do no get closed properly. We always have to make sure to properly cancel port forwarding requests before we disconnect from a SSH session. <snip> So how should we respond if the network connection is broken uncleanly, e.g., the WAN or Internet connection drops or the client computer crashes?
What I do is, I try to connect and if that fails, I try to cancel the port forwarding requests. This mostly works and sometimes also fails. <snip> Yes, but that is what we do as users. What can we do as developers to detect and correct this situation so users do not have to do this? Thanks - John
I have implemented this in the python-x2go code. I am saying this from
the developer's point of view. <snip> Ah, I misunderstood. My apologies. I do hope we can resolve it in the x2goclient code. Thanks - John
Hi Mihai,
- Stephan reported problems on 10.7 which seem to be SSH-related, I've gotta take a look at that, no idea if I can figure it out though. Looks like a libssh problem, but at least I've got some debug output.
No concrete code fixes from my side yet though.
Can i help debugging my problem?
Is it possible that the problem is on my server side (the old mac client, linux and windows is working to connect to the x2go server)? So i can generate a login for you on my x2go test server and we can check if you can connect to it.
Best regards Stephan
Best regards,
Mihai
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Stephan Diehl Geschäftsführer
Open Solutions GmbH & Co. KG Luisenweg 109 20537 Hamburg
Fon: 040 / 7070806 - 70 Mail: stephan.diehl@opensolutions.net
Registergericht: Amtsgericht Hamburg, HRA 105 704 Persönlich haftende Gesellschafterin: Open Solutions GmbH Registergericht: Amtsgericht Hamburg, HRB 999 00 Geschäftsführer: Stephan Diehl USt-Id-Nr: DE253775678; Steuer-Nr: 46/649/00349
On Tue, 2012-03-06 at 09:48 +0100, Mike Gabriel wrote:
Hi John,
On Di 06 Mär 2012 01:06:55 CET "John A. Sullivan III" wrote:
Hello, all. We were delighted to see Mihai's find about the overflow as we do have client whose Mac always freezes if the screen saver kicks in. We are eager to upgrade her but are unsure of the current state of the Mac client. Is there a production ready version with this fix available? If so, which one? Thanks - John
You should wait for 3.99.1.1, I guess. There is an X-Server detection
fix (using unix socket, not TCP to connect to the local X-Server) in it.Mihai, is anything else needed to be patched into x2goclient.git
currently for Mac OS X?Thanks, Mike <snip> Thanks very much, Mike. We'll eagerly await the new release - John
-
John A. Sullivan III -
Mihai Moldovan -
Mike Gabriel -
Stephan Diehl