Hello All,
Am facing a problem where the three SSH tcp connections are being torn down. Personally I am using a Cisco router and reflexive ACLs and can see what is happening. I have tried configuring SSHD on the remote server side with the following:
TCPKeepAlive no ClientAliveInterval 30 ClientAliveCountMax 3
This appears to have resolved the issue with File&Print but the PulseAudio connection is still being torn down. Have thought about removing the ClientAliveCountMax but why would three attempts fail when I was still connected to my X2go session ?
Thanks, Phil
Hi Phil,
On Fr 18 Mär 2011 18:17:11 CET "--[ UxBoD ]--" wrote:
Hello All,
Am facing a problem where the three SSH tcp connections are being
torn down. Personally I am using a Cisco router and reflexive ACLs
and can see what is happening. I have tried configuring SSHD on the
remote server side with the following:TCPKeepAlive no ClientAliveInterval 30 ClientAliveCountMax 3
This appears to have resolved the issue with File&Print but the
PulseAudio connection is still being torn down. Have thought about
removing the ClientAliveCountMax but why would three attempts fail
when I was still connected to my X2go session ?This is so frustrating and cannot believe nobody else has hit it;
unless everybody is running it across a LAN ???
What I always do when developing PyHoca and I meet an error, I switch
over to x2goclient and test if the other X2go client app available
shows the same behaviour.
As the SSH implementation in Python X2go is completely Python-based
(Paramiko module) it should be possible to track down if it is a
server problem or a client problem. So maybe you cross-check with
PyHoca-GUI if the problem occurs there as well.
I have added quite some verbosity to PyHoca-GUI, also for failing
(rev) port forwarding requests.
With what you describe:
o do port forwardings start up and then fail (get torn down) o or do they not even start up (rev port forwarding request denials)
The last aspect I have met and unfortunately still meet with Python
X2go... The denials are a known issue in SSHD (I can't find the source
I found on the web a couple of weeks ago). If you meet rev port
forwarding request denials, restart SSHD on the server and then the
rev port fw request should succeed.
The denials of rev port forwarding occur only on ,,resume session''
operations in PyHoca-GUI, esp. after a session has died unexpectedly.
The reason is that SSHD does not release a requested port fast enough
after the client connection has vanished (client-side network failure
etc.).
So what I do with reverse port forwarding in Python X2go (that is in
the client SSH code): I cancel a potentially previous port forwarding
request on the server before requesting a new one on the same port.
Especially while testing PyHoca-GUI (many session starts, reconnects,
resumptions, etc. in a short period of time, often with the same
session) I encountered many of these rev port fw denials. After adding
the described above hack (cancel_port_fw before request_port_fw) I had
reduced the issues to 10% or so, but they still occur, but only on
certain test servers. Here I presume that the SSHD configs on the
server could be optimized.
Hope this helps, 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...
----- Original Message -----
Hi Phil,
On Fr 18 Mär 2011 18:17:11 CET "--[ UxBoD ]--" wrote:
Hello All,
Am facing a problem where the three SSH tcp connections are being torn down. Personally I am using a Cisco router and reflexive ACLs and can see what is happening. I have tried configuring SSHD on the remote server side with the following:
TCPKeepAlive no ClientAliveInterval 30 ClientAliveCountMax 3
This appears to have resolved the issue with File&Print but the PulseAudio connection is still being torn down. Have thought about removing the ClientAliveCountMax but why would three attempts fail when I was still connected to my X2go session ?
This is so frustrating and cannot believe nobody else has hit it; unless everybody is running it across a LAN ???
What I always do when developing PyHoca and I meet an error, I switch over to x2goclient and test if the other X2go client app available shows the same behaviour.
As the SSH implementation in Python X2go is completely Python-based (Paramiko module) it should be possible to track down if it is a server problem or a client problem. So maybe you cross-check with PyHoca-GUI if the problem occurs there as well.
I have added quite some verbosity to PyHoca-GUI, also for failing (rev) port forwarding requests.
With what you describe:
o do port forwardings start up and then fail (get torn down) o or do they not even start up (rev port forwarding request denials)
The last aspect I have met and unfortunately still meet with Python X2go... The denials are a known issue in SSHD (I can't find the source I found on the web a couple of weeks ago). If you meet rev port forwarding request denials, restart SSHD on the server and then the rev port fw request should succeed.
The denials of rev port forwarding occur only on ,,resume session'' operations in PyHoca-GUI, esp. after a session has died unexpectedly. The reason is that SSHD does not release a requested port fast enough after the client connection has vanished (client-side network failure etc.).
So what I do with reverse port forwarding in Python X2go (that is in the client SSH code): I cancel a potentially previous port forwarding request on the server before requesting a new one on the same port. Especially while testing PyHoca-GUI (many session starts, reconnects, resumptions, etc. in a short period of time, often with the same session) I encountered many of these rev port fw denials. After adding the described above hack (cancel_port_fw before request_port_fw) I had reduced the issues to 10% or so, but they still occur, but only on certain test servers. Here I presume that the SSHD configs on the server could be optimized.
Hope this helps, Mike
Thanks, Mike.
Thanks, Phil
Hi Phil,
On Fr 18 Mär 2011 18:58:53 CET "--[ UxBoD ]--" wrote:
I have been monitoring my router and see exactly what is happening;
yet it does not for File/Print. I am wondering whether libssh is
sending any sort of keep-alive packet ? or perhaps it is not
responding correctly to the server side packet that is being sent.
libssh 0.4.8 came out in January so would be interested to see how
x2go works when that version is used. It's very frustrating indeed :(Thanks, Phil
hang on, I am getting at what you mean. Alex has submitted a patch to
libssh upstream that fixes a timeout problem with rev port forwarding.
The patch has been accepted and is included in libssh-0.4.8 AFAIK.
http://www.mail-archive.com/libssh@libssh.org/msg00358.html
Alex and Heinz have developed x2goclient with the already patched
libssh and it is also available for download:
http://x2go.obviously-nice.de/deb/pool-heuler/libssh/
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...
----- Original Message -----
Hi Phil,
On Fr 18 Mär 2011 18:58:53 CET "--[ UxBoD ]--" wrote:
I have been monitoring my router and see exactly what is happening; yet it does not for File/Print. I am wondering whether libssh is sending any sort of keep-alive packet ? or perhaps it is not responding correctly to the server side packet that is being sent. libssh 0.4.8 came out in January so would be interested to see how x2go works when that version is used. It's very frustrating indeed :(
Thanks, Phil
hang on, I am getting at what you mean. Alex has submitted a patch to libssh upstream that fixes a timeout problem with rev port forwarding. The patch has been accepted and is included in libssh-0.4.8 AFAIK. http://www.mail-archive.com/libssh@libssh.org/msg00358.html
Alex and Heinz have developed x2goclient with the already patched libssh and it is also available for download: http://x2go.obviously-nice.de/deb/pool-heuler/libssh/
Greets, Mike
Thanks, Phil
Hi Phil,
On Fr 18 Mär 2011 19:53:43 CET "--[ UxBoD ]--" wrote:
Already using 3.01.18 so that should have been compiled with; plus I
have compiled my own Windows client. This is also happening under
Linux which is the odd thing. I will have to recompile under Linux
as-well to enable debugging and find out what is happening. Like I
say the initial connection and F&P are fine; it is just sound now
causing the issue. I cannot understand what is different between
F&P and Sound; if you do say a 'df' you see the timeout count reset
but keeping a sound link alive is very different.
Unless you haven't compiled libssh statically into x2goclient (under
Linux normally not the way it is compiled, how is it compiled under
Windows?) using 3.01.18 without the patched libssh installed on your
system will still result in the observed error...
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...
----- Original Message -----
Hi Phil,
On Fr 18 Mär 2011 19:53:43 CET "--[ UxBoD ]--" wrote:
Already using 3.01.18 so that should have been compiled with; plus I have compiled my own Windows client. This is also happening under Linux which is the odd thing. I will have to recompile under Linux as-well to enable debugging and find out what is happening. Like I say the initial connection and F&P are fine; it is just sound now causing the issue. I cannot understand what is different between F&P and Sound; if you do say a 'df' you see the timeout count reset but keeping a sound link alive is very different.
Unless you haven't compiled libssh statically into x2goclient (under Linux normally not the way it is compiled, how is it compiled under Windows?) using 3.01.18 without the patched libssh installed on your system will still result in the observed error...
Greets, Mike
Thanks, Phil