Re: Client Access disconnecting -- MIDRANGE-L

James,

>Has anyone experienced these drops that *were not* using client access?

Meaning dropping connections when using another telnet or whatever connection to
the iSeries?  Or random dropping of TCP/IP connections in general?

I only use client access express (not Mocha etc) to connect to the iSeries.  I
do experience drops.  I do not have a support contract, so I don't open a PMR or
anything, but then I don't think it is IBM's problem.

At least in my case, I'm not convinced CAE has anything to do with it -- I think
it is problems in the MS handlers for TCP/IP traffic.

The reason I say this is because I also randomly drop TCP connections even when
CAE is not active.  In my setup I have a private 192.168.x.x address on an
internal LAN (as does my 400), and a machine which acts as the gateway to the
internet.  This gateway machines runs VNC host so I can operate it from my
desktop when I so choose.

When I experience drops, I can observe the following:

 - Most TCP connections already open seem to get blocked and timeout while
waiting for a reply.  This includes telnet, FTP, SMTP, POP3, HTTP, and
pcAnywhere but interestingly does not seem to always disrupt a VNC connection to
my gateway, even if already open, though sometimes it does.  Go figure.

 - During this period while this timeout is occuring, my desktop cannot open a
new connection on any of the ports which are in the process of timing out, nor
can I ping something like my ISP's mail server.

 - However, I *can* ping my gateway machine, and I *can* typically start or
resume a VNC session to the gateway.  From the gateway machine I can readily
ping the mail server or others destinations on the Net, open browse windows,
etc.  In other words, the gateway seems to be unaffected.  It is only my local
desktop which appears to hang.

 - From my desktop, if I start a "ping (address) -t" to continually retry the
command and keep it running in a window off to the side (I use multi monitor
support so just shove it off on monitor #3), then when one of these lockouts
occur I can witness the ping window change to showing continual timeouts.

 - After an inconsistent period of time, the pings will resume working.
Generally they will take off and all succeed until the next time a lockout
occurs.  Sometimes they resume intermittently, with some pings working and
others timing out, then eventually all working again.

 - On the gateway machine, I've tried W2K Pro, Win Me, and Win 98se.  On the
desktop I've tried Win98se and W2K Pro.  It doesn't seem to matter what
combination I use.

Since this seems to happen whether or not I have any CA Express sessions going,
I'm not convinced it has anything to do with CAE unless it is a background
process which CA has loaded.  (I do not run service level update, etc)

I can't get DSL or cable service where I'm at, and ISDN is metered and *very*
expensive except for occassional use, so I was dialup until a couple of week ago
when I installed a one-way satellite connection.  Because of the high latency
involved on the return path, the software adjusts some TCP registry settings,
such as the receive window size, so it can collect more packets in a stream.

Since moving to satellite, the problem seems to happen more often.  And when it
does, it takes longer to recover too.  (Sigh)  It would seem Windoze is
incorrectly not accepting/receiving packets on open socket connections during
this lockout period, and eventually they all timeout and disconnect.

Unfortunately, with my high latency connection, the timeout takes longer.
According to MS knowledge base article Q158474 which describes TCP registry
settings in Win 95/98/98se/ME, I can't directly control the timeout value, only
the number of retries.  To quote in part:

MaxDataRetries = 32-bit number

Data Type: String

Specifies the maximum number of times a segment carrying data or an FIN will be
retransmitted before the connection is terminated. The retransmission timeout
itself is adaptive and will vary according to link conditions. The default is 5.


There is another knowledge base article, Q236926, which admits Win95/98/98se
"incorrectly computes the retransmit timer because of a math error".  It also
says:

  "TCP uses a retransmit timer to retransmit packets that do not seem to have
reached the receiver. To set this timer, TCP uses information about the
historical round-trip time (RTT) for each connection, which it measures by
observing the time between sending packets and receiving acknowledgments for
them."

The article has a link to a file, 236926usa8.exe, "but it is only intended to
correct the problem described in this article and should be applied only to
systems experiencing this specific problem."

I've installed that patch, but still have the same lockup conditions occuring.

Sometimes, the lockout seems to be resolved fast enough that a telnet session
doesn't drop -- it just has horrible response time before the screen updates.
But it does *not* seem to be system activity level related -- it seems to be a
TCP problem, and I suspect more attributable to MS than CAE.  It puts the doze
back in Windoze.

At other times, it never recovers and the session times out.  Unfortunately,
when using a CAE session profile with a dynamic WS ID, a reconnect then gives
you a new session rather than attaching back to the prior session...

Doug