NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/bbs/waffle/5551

Text File | 1992-12-26 | 3.7 KB | 99 lines

Path: sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!werple.apana.org.au!posgate!msp
From: [e-mail] (Mark Purcell)
Newsgroups: comp.bbs.waffle
Subject: Help: Remote system closing channel
Summary: Resend of packets doesn't seem to function
Keywords: ACK SEND resend
Message-ID: <[e-mail]>
Date: Sat, 26 Dec 92 21:01:59 +1000
Organization: Private APANA site
Lines: 87


Hi,

I seem to have a simple problem with my Waffle 1.65.  During data
transfers after a random period (these things always happen after
random periods), usually about 10 minutes, my system stops sending
data packets to the host it is connected to.  This has happened
with a couple of different system I connect to, each of which run
different inplementations of UUCP.

I run a 386DX40 with 4/80 and a ADTECH 2400 modem, under DOS5.0 which
has functioned fine for some time now running UUPC/extended so I don't
think it is my hardware, but it could be some obscure difference
between the packet sending in Waffle and UUPC.

As the snap from uucico shows below my machine keeps on trying to resend
the packets but the other system never receives them.  The strange thing
is I see the ACK coming in on the modems LEDs but I don't see the
resends going out on the LEDs.

This leads me to think that for some reason the resends aren't making
it to my modem.   I was running SMARTDRIV but I removed that and
everything else which might of been buffering the output but I
couldn't make any difference.

I understand that the variable uu.delay sets the times before uucico
does a timeout and tries to resend missing packets, but nothing  is
seen on the modems LEDs.  I also understand that the variable uu.alive
sets the time before the system closes down the connection.  I started
with the default values but have lowered uu.delay to make the system
resend the missing packets more often, neither with any joy.

Has anyone else seen these symptoms or have a workaround/solution?

Mark

PS Does the (Overflows: 334 Tx, 0 Rx) line have anything to do
with the problem, ie should this be 334?

[multiplies of what you see here deleted]

19:27:38.12 (6) *** ACK 6
19:27:38.18 (6) send DATA packet, yyy=5 xxx=5 len=64
19:28:07.84 (6) * got ACK 6
19:28:17.83 (6) * got ACK 6
19:28:27.77 (6) * got ACK 6
19:28:37.77 (6) * got ACK 6
19:28:47.77 (6) * got ACK 6
19:28:57.82 (6) * got ACK 6
19:29:07.81 (6) * got ACK 6
19:29:17.04 (5) *** timeout 7
19:29:17.04 (6) => resend 7
19:29:18.63 (6) send DATA packet, yyy=5 xxx=7 len=64
19:29:18.69 (6) => resend 0
19:29:18.80 (6) send DATA packet, yyy=5 xxx=0 len=64
19:29:18.85 (6) => resend 1
19:29:18.85 (6) send DATA packet, yyy=5 xxx=1 len=64
19:29:18.85 (6) => resend 2
19:29:18.91 (6) send DATA packet, yyy=5 xxx=2 len=64
19:29:18.91 (6) => resend 3
19:29:18.91 (6) send DATA packet, yyy=5 xxx=3 len=64
19:29:18.96 (6) => resend 4
19:29:18.96 (6) send DATA packet, yyy=5 xxx=4 len=64
19:29:18.96 (6) => resend 5
19:29:19.02 (6) send DATA packet, yyy=5 xxx=5 len=64
19:29:19.07 (6) * got ACK 6
19:29:27.81 (6) * got ACK 6
19:29:37.86 (6) * got ACK 6
19:29:37.91 (6) * got CLOSE
19:29:37.91 (0) Remote system closing channel
19:29:37.97 (6) send CLOSE packet, yyy=0
19:29:37.97 (5) session state: Y
19:29:37.97 (6) * got CLOSE
19:29:37.97 (4) Closing packet channel..
19:29:47.03 (0) 157 packets sent, 5 received, 2 errors, at 38 cps
19:29:47.09 (5) session state: P
19:29:47.09 (5) toplevel state: y
19:29:47.09 (4) wmsg: OOOOOO
19:30:17.02 (4) rmsg: TIMEOUT, no ^P
19:30:17.02 (4) wmsg: OOOOOO
19:30:17.90 (5) Overflows: 334 Tx, 0 Rx
19:30:17.90 (5) Errors: Framing 0, Parity 34, Transmit 0
19:30:18.39 (5) Errors: DSR 0, CTS 0

--
[e-mail]    [e-mail]
Mark Purcell, 62/25 Market Street, SYDNEY NSW 2000.  [phone]