See comments in line. At 02:27 AM 5/23/02, Mark Odette II wrote: >To anybody that has experience with Sniffers. or more perhaps more >specifically, Priscilla- > >I'm trying to hunt down the culprit of Telnet Session disconnects >without Administrative or User interaction to invoke such action. > >The situation is Telnet clients on remote ends of PIX VPNs have their >sessions dropped without warning, and without Administrative action to >cause such sudden session endings. > >All users that connect to the same Telnet Server on the local subnet >never experience this problem. For the remote users that do experience >this problem, it usually occurs after roughly 30 minutes of inactivity. >This used to not be the case when all such remote clients were >connecting via private Frame Relay networks back to the Server in a >hub-n-spoke fashion.. Only since the switch to VPNs for connectivity to >the Telnet Server's Private Network has this anomaly arisen. > >The Telnet Server is a custom application service for Unidata DB Server >by Informix. It uses the standard Telnet port, and runs on NT 4.0. For >everything I can see in the registry referencing the Telnet App Service, >it doesn't specify any settings for keep-alive or session monitoring.
How about the clients? Do they have some setting for keepalive or disconnecting after no activity? How about the VPN software? It might have something like that. I would definitely focus on the VPN aspects since that's the one thing you say that changed. > >Also, from the Unidata Application Server's point of view, the Server >thinks the user is still connected, so it never clears the session. >When the user finds his/her application rendering a Pop-Up dialogue >stating that the session was disconnected, and asks if they want to >reconnect, they choose "Yes" naturally. From the Server side, a second >session for that user is started, and the first session becomes an >"orphan" process (in my own words). This of course then causes a >problem of exhausting the limited number of users licenses, and >eventually causes users to not be able to get back on the system until >the old orphaned processes are administratively cleared. > >So, I open a case with Cisco, and they say "Slap a Sniffer on the Server >side of the network, and see what is causing the disconnects". They >also say that they are suspect that the Telnet Server is sending its >session keep-alives via Broadcast A server sending its keepalives via broadcast sounds extremely unlikely. Ask that this be escalated to a more senior TAC engineer?! ;-) (On the other hand, they see a lot of strange things and probably wouldn't say this unless they had seen something similar. So there may be some germ of truth in it.) But, from the symptoms that you are experiencing, I would put the sniffer on the client side, not the server side. You said the server still thinks the session is open. It probably didn't send anything. Actually put a sniffer on both sides to get the best results. >, and that by design of Security, the >VPN tunnels don't pass Broadcast Traffic. The Sniffer capture is >supposed to prove or disprove this. > >I put a Sniffer (Ethereal on Windows 2K) out and collected a Time Window >of data, but am at a loss as to how to identify the disconnect process >of a telnet session..Which is where I could use a few pointers. A good sniffer would let you search for the text "FIN" in the detail. Also, be sure to set up a filter for Telnet traffic just from that server so you'll have less data to look at. > >Could someone tell me what to look for in a session trace that >identifies a sudden termination of a specific telnet session (most >probably initiated by the server)?? Either FIN or maybe RST (reset). > >Unfortunately, I'm not a very well experienced person in following the >SYN, FIN, PSH, ACK, SYN ACK, etc. process. But I want to learn! That's what you have to do. You just have to follow it, packet by packet. There's no magic. It just takes practice and a willingness to spend lots of time studying the details. > >If I had the time and money, I'd go take a Sniffer class, but that's >another story. You may not need a class, if you have the time to work on it yourself. Good luck. Let us know the resolution! Thanks. Priscilla >so, in the mean time, if someone would be kind enough to >point me in a direction on how to interpret and follow a sniffer trace, >I'd be eternally greatful. > >Thanks, >Mark ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44855&t=44793 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
