Re: telnet disconnect problem

From: Adam bultman <adamb@glaven.org>
Date: Fri May 12 2006 - 10:12:32 AKDT

No. I can look at our router (the VPN router that they are passing
through) and my jurisdiction ends about 3/4" beyond our switch. Other
people are using VPNs and telnet without complaining about disconnects.
The other end is not my jurisdiction either sadly, and they won't let me
poke around on their network. Also, they're a windows shop.

Adam

Jared Armstrong wrote:
> Have you looked at any routers in between?
>
>
>> From: Adam bultman <adamb@glaven.org>
>> To: aklug@aklug.org
>> Subject: telnet disconnect problem
>> Date: Fri, 12 May 2006 09:22:45 -0800
>>
>> This is a problem that has been plaguing me, and I cannot figure out
>> what's wrong.
>>
>> I have a Red Hat 7.3 server sitting behind a VPN. It's a fast machine.
>> I have client systems on the other end of the VPN using telnet to
>> connect. Telnet on our end is handled via xinetd.
>>
>> Recently (past 3 weeks) they have started getting disconnects. After
>> certain amounts of inactivity they will get booted. so for example, if
>> they start something that takes a while, and then go to lunch, they'll
>> get disconnected, and the job will die.
>>
>> The other end is currently blaming us. We both claim to have changed
>> nothing (it's true, at least for my end; I didn't change anything, and
>> the software didn't update itself..) but the problem persists.
>>
>> I've done googling, and found two ways of addressing this, at least from
>> the server side:
>> 1. Change the tcp timeout on the server to be higher
>> 2. Change the xinetd.conf file for telnet to have KEEPALIVE as one of
>> the server flags.
>>
>> There's no way I'm changing the global tcp timeout on the server via the
>> /proc interface - I don't want to afffect anything else - and I did make
>> the xinetd change.
>>
>> The problem is persisting, and in the kernel messages, I see things
>> like:
>> ttloop: read: Connection reset by peer
>> ttloop: peer died: EOF
>>
>> The PID numbers don't jive with both types of messages (meaning that I
>> won't see pid 1100 show up for a Connection reset by peer message as
>> well as a peer died message. They will get one error, or the other, but
>> not both.) By tracking PID numbers, I have been able to find that they
>> aren't the only group of people getting those disconnect messages - of
>> course, I have no idea if Bob from whatever different VPN endpoint
>> disconnected by closing his telnet session properly, or just shut down
>> his computer directly, or yanked his ethernet cable.
>>
>> I'm led to believe that because of the error messages, that it's not a
>> problem of our server kicking - it's a problem of their end
>> disconnecting, or dying. I have no complaints about VPN problems - it's
>> a small number of people getting disconnected in a larger number of
>> people. I'm trying to figure out where these people are in relation to
>> one another, to see if it's a problem in a specific office, but I don't
>> know, apart from sitting around watching tcpdump, how to figure out
>> exactly what's causing the disconnects.
>>
>> Whaddya think?
>>
>> Adam
>> ---------
>> To unsubscribe, send email to <aklug-request@aklug.org>
>> with 'unsubscribe' in the message body.
>>
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's
> FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri May 12 10:11:26 2006

This archive was generated by hypermail 2.1.8 : Fri May 12 2006 - 10:11:26 AKDT