[X2go-dev] Torn down TCP connections

Mike Gabriel mike.gabriel at das-netzwerkteam.de
Fri Mar 18 18:50:18 CET 2011


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 at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20110318/eb432bf9/attachment.pgp>


More information about the x2go-dev mailing list