Re: Client Access disconnecting -- MIDRANGE-L

--
[ Picked text/plain from multipart/alternative ]
Yes, I would agree that Windoze is the culprit.

I solved my problem by replacing the Windows Gateway with a Linux
Gateway (SuSE 7.0). Much more reliable. This has never crashed since it
was installed. It was last booted over 6 months ago.

I also use Linux (SuSE 7.2) as my workstation. Connections the AS/400
never go down (Telnet, FTP, HTTP, Netserver, etc.). All systems are go!!

I only use Windoze when I have to. Then the old instabilities come back.
 - Please IBM, get your finger out and make Linux compatible versions of
Ops Navigator and Code/400.

I think Windoze wait for the TCP/IP reply, somehow misses or looses it,
and goes into a wait state for that reply. Eventually it times out.

Trying to persuade IBM 'fix' this problem is probably a waste of time. I
don't think it's IBM's problem. I don't think they can fix it!!
Microsoft needs to fix this one.

Syd Nicholson
Castlehill Computer Services Ltd.
sydnic@ccs400.com


Douglas Handy wrote:

>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
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>

--