Re: Client disconnecting over a VPN connection

From: Simon Hobson (simonsnews_at_thehobsons.codotuk)
Date: 09/24/05


Date: Sat, 24 Sep 2005 18:09:29 +0100

On Wed, 21 Sep 2005 11:26:52 +0100, Rob wrote
(in message <dgrch5$538$1@newsread.albacom.net>):

> During the last 2 months we've been told about a frequent number of
> "disconnections" reported on the remote site; by disconnection I mean
> the disappearing of the windows which depicts the package even while the
> operator is typing/clicking.
>
> These problems occurs approx every 10/15 minutes and have been reported
> by all the operators on the remote site (ie, this is not related to a
> single box) even if they occur at different times.
>
> During these periods, the internet connection is reported as functional
> since operators on the remote side can browse the 'Net without problems;
> the VPN link seems to work fine since (eg) while operator Bill reports
> the problem, operator Bob still works using the same VPN channel.

I know this isn't going to be very helpful, but at my last job we ran
character sessions (telnet) to an OpenServer 5.0.6s box. We always had a low
level of disconnections which we mostly at sites using a WAN link - they were
reported to the user by the local telnet app popping up a notice that teh
connection was reset by the peer.

I alway put this down to a flaky bit of network programming, either in the
TCP stack or the telnet daemon - I always assumed that there was a network
error (dropped packet) or a delayed packet and some bit of the system simply
didn't handle it correctly.

Simon



Relevant Pages

  • Re: Telnet Command Line Access
    ... via telnet at the command line level. ... expect scripts to run User Profile reports, ... If I automate the telnet via expect scripts will it ignore the psuedo ... QSH will not provide an shell commands to audit users. ...
    (comp.sys.ibm.as400.misc)
  • Re: Client disconnecting over a VPN connection
    ... Simon Hobson wrote: ... >>the VPN link seems to work fine since while operator Bill reports ... > I alway put this down to a flaky bit of network programming, ... > error (dropped packet) or a delayed packet and some bit of the system simply ...
    (comp.unix.sco.misc)