 |
Zortek
Novice
Joined: 26 Jul 2002
Posts: 35
Location: USA
|
 Posted: Wed Jul 02, 2008 2:22 pm
[2.29 CMudPro] SSH Session Timeout (KeepAlives?)
|
Server: RHEL 4 & 5, Centos 5, SLES 10
Client: WindowsXP Pro, Windows XP64 Pro
Protocol: SSH2
Unlike my other ssh tools, CMudPro times out or in some way becomes non-responsive after a period of inactivity. I have not narrowed down the minimum interval required to duplicate this behavior but it seems that >1hr is consistent. Side-by-side sessions (putty and cssh) left over night connected to the same server always result in cssh requiring a reconnect and putty not so.
Server side sshd.conf contains:
ClientAliveInterval 14
ClientAliveCountMax 3
I might be anachronistic or simply missing something. Sharing snippets from the sshd_config man page for reference:
| Code: |
ClientAliveCountMax
Sets the number of client alive messages (see below) which
may be sent without sshd receiving any messages back from the
client. If this threshold is reached while client alive mes-
sages are being sent, sshd will disconnect the client, termi-
nating the session. It is important to note that the use of
client alive messages is very different from TCPKeepAlive
(below). The client alive messages are sent through the
encrypted channel and therefore will not be spoofable. The
TCP keepalive option enabled by TCPKeepAlive is spoofable.
The client alive mechanism is valuable when the client or
server depend on knowing when a connection has become inac-
tive.
The default value is 3. If ClientAliveInterval (see below)
is set to 15, and ClientAliveCountMax is left at the default,
unresponsive ssh clients will be disconnected after approxi-
mately 45 seconds.
ClientAliveInterval
Sets a timeout interval in seconds after which if no data has
been received from the client, sshd will send a message
through the encrypted channel to request a response from the
client. The default is 0, indicating that these messages
will not be sent to the client. This option applies to pro-
tocol version 2 only. |
Now I've toyed with TCPKeepAlive as well for a couple days and I'm not seeing any improvement/difference in my testing either way:
| Code: |
TCPKeepAlive
Specifies whether the system should send TCP keepalive mes-
sages to the other side. If they are sent, death of the
connection or crash of one of the machines will be properly
noticed. However, this means that connections will die if
the route is down temporarily, and some people find it
annoying. On the other hand, if TCP keepalives are not
sent, sessions may hang indefinitely on the server, leaving
“ghost” users and consuming server resources.
The default is “yes” (to send TCP keepalive messages), and
the server will notice if the network goes down or the
client host crashes. This avoids infinitely hanging ses-
sions.
To disable TCP keepalive messages, the value should be set
to “no”. |
Presently, I have TCPKeepAlives disabled to accomodate the router differences between team members and client systems (Linksys/Netgear) that are known to be problematic with Windows connectivity issues and SSH.
Any thouoghts?
Z |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Jul 02, 2008 5:10 pm
|
Do you have any other specific information on what format the "client alive messages" mentioned in the first section are? I've never heard of those, but if the server is sending some sort of "client alive message" to CMUD SSH that it needs to respond to, then I can probably add that.
We talked about the TCPKeepAlive stuff several times in the past here, and it's on my list to look into. It's tricky because as a MUD client, most MUD servers do not want CMUD to send KeepAlive packets to keep their session active. Most MUDs do not want inactive sessions to remain connected, like if someone just left CMUD connected overnight. So it's a difficult position where some players want it, but the feature might cause the MUD admins to start banning CMUD usage.
Anyway, so the TCPKeepAlive stuff is on my list, but I hadn't heard of any other "client alive message" so let me know what other information you can find out.
Finally, yes, it is actually very common for routers along the Internet to drop/change an ssh/telnet connection too. That's what the TCPKeepAlive is supposed to prevent. Since it depends upon specific router settings, some people could experience more timeout problems than others depending upon their ISP and their exact router configurations. |
|
|
|
|
Zortek
Novice
Joined: 26 Jul 2002
Posts: 35
Location: USA
|
Posted: Wed Jul 02, 2008 5:41 pm
|
I'll set up the account for you now and get that info to you first.
|
|
|
|
|
Zortek
Novice
Joined: 26 Jul 2002
Posts: 35
Location: USA
|
Posted: Wed Jul 02, 2008 6:39 pm
|
| Zugg wrote: |
| Do you have any other specific information on what format the "client alive messages" mentioned in the first section are? I've never heard of those, but if the server is sending some sort of "client alive message" to CMUD SSH that it needs to respond to, then I can probably add that. |
I don't have the deep dive info handy, but I know some of the information request or message details are covered in Section 3.2 RFC4256. I'm fairly confident that doesn't cover the full scope of the data you need. I'll try to see if I can dig up some more dirt. OpenSSH may be my next stop.
| Zugg wrote: |
| We talked about the TCPKeepAlive stuff several times in the past here, and it's on my list to look into. It's tricky because as a MUD client, most MUD servers do not want CMUD to send KeepAlive packets to keep their session active. Most MUDs do not want inactive sessions to remain connected, like if someone just left CMUD connected overnight. So it's a difficult position where some players want it, but the feature might cause the MUD admins to start banning CMUD usage. |
Hehe... this is an old discussion. Typical admin discussion goes like this, 
| Code: |
[admin1] We don't want players to remain idle keping sockets open...
[admin2] yeah but "admins" should have the ability to remain connected as long as they want/need
[admin1] but it would require potential changes to the mud driver/lib/server
[admin2] um, okie, so I'll make the changes
[admin1] but what about the clients
[admin2] Clients!?! BAH... Zugg is taking over the planet... and he's reasonable and charming too... [ed. by unknown editor]
[admin1] yup, but isn't that hypicritical?
<dramatic pause>
[admin2] ...only if you are a "player"... |
| Zugg wrote: |
| Anyway, so the TCPKeepAlive stuff is on my list, but I hadn't heard of any other "client alive message" so let me know what other information you can find out. |
Distinguishing the client side TCPKeepAlives from the server side ClientAlives has tripped me up on several occations. A skim of a few support forums seems to indicate that this is a continuing "awareness" struggle for the OpenSSH folks.
| Zugg wrote: |
| Finally, yes, it is actually very common for routers along the Internet to drop/change an ssh/telnet connection too. That's what the TCPKeepAlive is supposed to prevent. Since it depends upon specific router settings, some people could experience more timeout problems than others depending upon their ISP and their exact router configurations. |
This has become quite a hot topic in the past year. ISPs have been foisting "business logic" on various protocols as they experiment and try to find how far they can push disrupting bit torrent and other services without losing their customer base. It's become an ugly business, technically and politically.
Z |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Jul 02, 2008 7:41 pm
|
It *is* an ugly business. I don't want to side-track the thread, but I was playing a freebie MMO game a few weeks ago and discovered that at night I was getting disconnected. But only at night. Turns out it's an issue with Comcast. They claim they are not "packet shaping", but they *are* using some 3rd party software that is trying to disrupt bit-torrent P2P traffic, and it somehow thinks that a large burst of data from this MMO looks like P2P and so it sends a disconnect to the client and server. If this starts effecting more mainstream games, then Comcast is history.
Anyway, yeah, it's tricky. The main reason I'm still considering adding some TCPKeepAlive logic is that other "clients" do it anyway (such as PuTTY). |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
