ColdFire - NicheLite Loss of TCP/IP session

[jes]

We've discovered that the NicheLite IP stack apparently does NOT recognize a loss of connection on a telnet session (server running the NicheLite stack) when the client equipment is powered down.  We are expecting this to result in an M_CLOSED indication by lower layer to the callback function, but this apparently doesn't arrive.  I only say apparently since we haven't put a debugger on it as yet but we are able to determine that the previous session is still intact because we only allow one telnet session at our device at any one time and our device rejects subsequent telnet connections.

Also, according to our IT dept, a CAT5 cable disconnect on an existing session ought to similarly result in a report of loss of connection for security reasons (ie someone trying to spoof a previously existing connection), but it does not do this either.

Anyone familiar with this problem and a possible fix?  Any help is much appreciated.

[TomE]

---

jes wrote:

We've discovered that the NicheLite IP stack apparently does NOT recognize a loss of connection on a telnet session (server running the NicheLite stack) when the client equipment is powered down.  We are expecting this to result in an M_CLOSED indication by lower layer to the callback function, but this apparently doesn't arrive. ...

Also, according to our IT dept, a CAT5 cable disconnect on an existing session ought to similarly result in a report of loss of connection for security reasons (ie someone trying to spoof a previously existing connection), but it does not do this either.

I think you've run into a DECADES old misunderstanding here.

There is no mechanism in TCP to time out a connection (there is, but see later). A "Feature" of TCP is the ability to set up a connection, take down the connection between the two computers for a WEEK, reconnect and have the connection remain established. This is a deliberate feature.

If your Application requires a "disconnection notification" then it is the APPLICATION'S problem and is not TCP's.

TCP has a contentious "TCP Keepalive" documented here:

http://tools.ietf.org/html/rfc1122#page-101

Also here (click on "Read more" at the bottom and search for "keepalive"):

http://groups.google.com/group/comp.answers/msg/cd072527fe89c44c?&q=faq

Because of the fear of the internet being bought down by everything sending keep-alives all the time, the specification listed above is to have the "Keepalive Time" default to two HOURS. It has never been used or supported by anything.

You're looking at doing something different though. In your application you are expecting that unplugging the Ethernet Cable will signal up to the TCP and Application that the link has gone down. Maybe and maybe not. I wouldn't expect this to always work. Simple network devices might be able to do this. More complicated one with multiple connected networks might not. Just because a PC does it doesn't make it right :smileyhappy:.

It certainly won't work if there's a HUB between the client and the server. The hub will be providing the link indication to the server and it won't ever signal client disconnection or power-off.

If you want 'connection security" then that's a problem for the "connection".

[jes]

Yes indeed it is my understanding (if not late in coming as I've only recently needed to revisit the boards and some of my older posts).

As you wrote, a local CAT5 cable disconnect doesn't necessarily kill the session.  We've since implemented an upper layer 'keep-alive' tossed back and forth between devices that have a mutual understanding of the necessity to do this to be able to quickly and reliably recognize the loss of connectivity at either end.

On a separate product, we've also recently implemented a keep-alive 'probe' sent by a telnet server to a remote client every X seconds.  It's essentially a packet with no data.  If a cable should become disconnected or an interim router/switch goes down then the server will recognize this by a reported failure of 'probe' by TCP-IP layer code and close the session.  This prevents our single-session-at-a-time server (to prevent multiple users simultaneously controlling end equipment) from keeping a non-responsive session open in perpetuity thereby denying access to other prospective users.

[TomE]

> This prevents our single-session-at-a-time server (to prevent multiple users simultaneously

> controlling end equipment) from keeping a non-responsive session open in perpetuity

> thereby denying access to other prospective users.

I thought this might be an "Application Level Problem".You want an inactive logged-in user to be timed out, logged out and the TCP session closed/aborted.

What happens if someone is logged in, then goes home for the weekend leaving their computer turned on? The session is still blocked.

Wouldn't a "login inactivity timer" be a better solution than considering link-level disconnection and TCP Pings?

A problem you might have with this in an embedded system is that the TCP session may not close when there's no remote to respond to the close, but that's due to a bug in the TCP if it happens and should be fixed. As well, it may take 5-10 minutes to close in this case (and in your current case). This is the normal TCP Retransmit Timeout. If you want a more rapid timeout/login, then you should have a multi-session server, but have the login application enforce the "one at a time". You can also have the login server report back "You can't log in because user 'name' on IP address aa.bb.cc.dd which DNS resolves to 'machine name' is already logged on".

Tom

[vier_kuifjes]

I don't know about the telnet stuff as I haven't made use of it, but I do have some experience with NicheLite and know that there are some issues with it. A have made a web page describing my findings:

http://www.mvdh.be/cf_lite_patched.html