183 lines
6.2 KiB
Plaintext
183 lines
6.2 KiB
Plaintext
---- Unscheduled Incoming Mail at 20 Nov 91 13:39:25
|
||
* Connected at 9600/ARQ/HST
|
||
* FR1: Incoming Call at 13:39:25
|
||
* FR2/WVx: Waiting for sync
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Honoring previous TSYNC
|
||
* FR3: Receiving Mail Packet
|
||
* XMODEM/CRC: INBOUND\2.IN 0
|
||
* XMODEM/CRC: Duplicate 0
|
||
* XMODEM/CRC: Protocol Complete 0
|
||
* FR4: Received 1 packets (384 bytes)
|
||
* FR5: Receiving (possible) attached files
|
||
* DIETIFNA: BR1-2: Got filename 0
|
||
* DIETIFNA: BR1-2: Got filename 0
|
||
* DIETIFNA: BR1-3: Filename skip 0
|
||
* DIETIFNA: XR1-4: TELINK Block 0
|
||
* DIETIFNA: XR2: Bad Checksum 0
|
||
(Carrier loss or timeout during packet or file)
|
||
* Total connect time was 0:34
|
||
|
||
* Packet from 1:107/519
|
||
1 messages
|
||
---- Complete at 13:40:01
|
||
Original Message Date: Wed 20 Nov 91 16:54
|
||
From: Thom Henderson on 1:520/1015
|
||
To: Tom Jennings on 1:1/1
|
||
Subj: ARTSPEC
|
||
^ADOMAIN FIDONET 1:1/1 ALTERNET 7:520/1015
|
||
Oh well, so much for that idea. It seems that I still can't send you <20>
|
||
files.
|
||
|
||
|
||
Original Message Date: 20 Nov 91 22:32:14
|
||
From: tom jennings on 1:125/111
|
||
To: Thom Henderson on 1:107/519
|
||
Subj: file attach problems
|
||
^AINTL 1:107/519 1:125/111
|
||
Hah. Got a log fragment on the problem, enclosed. I'd like to identify
|
||
this problem ... to save you ther trouble of groping through the log,
|
||
it all is OK except the 2nd to last *'ed line -- "DIETIFNA: XR2 Bad
|
||
Checksum" (XR2 is FSC-0001, (X)modem (R)eceive state 2.)
|
||
|
||
Fido doesn't do SEALINK, and SEA(dog? Mail?) doesn't do TELINK, so the
|
||
skipfilename happens, and it looks like your end sends the expected
|
||
TELINK block, but Fido gets a checksum error (the TELINK block is
|
||
always checksum remember, even if the rest of the xfer is in CRC...
|
||
aargh) and then carrier is lost. I am fairly certain that its your end
|
||
disconnecting; I presume because Some Thing happened that was
|
||
intolerable, rather than simply one failed try!
|
||
|
||
My end displays more info than gets logged, so if you don't have any
|
||
immediate insight into what's going on (I have no further clues
|
||
without more data), can we arrange for you to send me a file again
|
||
whilst I watch?
|
||
|
||
Or maybe, do you have a self-contained program I can run on my
|
||
hardware here, via FOSSIL, under DESQview, that I can use to test
|
||
with? I swear I will only upload it to two or three BBSs :-)
|
||
|
||
Log frag follows:
|
||
|
||
---- Unscheduled Incoming Mail at 20 Nov 91 13:39:25
|
||
* Connected at 9600/ARQ/HST
|
||
* FR1: Incoming Call at 13:39:25
|
||
* FR2/WVx: Waiting for sync
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Honoring previous TSYNC
|
||
* FR3: Receiving Mail Packet
|
||
* XMODEM/CRC: INBOUND\2.IN 0
|
||
* XMODEM/CRC: Duplicate 0
|
||
* XMODEM/CRC: Protocol Complete 0
|
||
* FR4: Received 1 packets (384 bytes)
|
||
* FR5: Receiving (possible) attached files
|
||
* DIETIFNA: BR1-2: Got filename 0
|
||
* DIETIFNA: BR1-2: Got filename 0
|
||
* DIETIFNA: BR1-3: Filename skip 0
|
||
* DIETIFNA: XR1-4: TELINK Block 0
|
||
* DIETIFNA: XR2: Bad Checksum 0
|
||
(Carrier loss or timeout during packet or file)
|
||
* Total connect time was 0:34
|
||
|
||
* Packet from 1:107/519
|
||
1 messages
|
||
---- Complete at 13:40:01
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
31 Jan 92
|
||
|
||
Here's an annotated log of event sduring your last attempt to fileattach
|
||
to me. I'm running Fido/FidoNet 12u.
|
||
|
||
Note that the state names are directly from FSC-0001 and other
|
||
docs; FR2 is R2 from FSC-0001 (prefixed "F" because the state names
|
||
for WAZOO are the same...)
|
||
|
||
I know where the problem lies, I just don't know what your end is
|
||
expecting. It has to do with TELINK block handling.
|
||
|
||
|
||
(my FIDONET.LOG fragment line begin with "*")
|
||
|
||
---- Unscheduled Incoming Mail at 31 Jan 92 21:04:23
|
||
* Connected at 9600/ARQ/HST
|
||
* FR1: Incoming Call at 21:04:23
|
||
|
||
Fido "prefers" Wazoo; it remembers TSYNC, but waits 8 sec more
|
||
for a YOOHOO. In this case it honors the TSYNC (ie. FSC-0001)
|
||
|
||
* FR2/WVx: Waiting for sync
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Got TSYNC, but trying for YOOHOO
|
||
* FR2/WV2: Honoring previous TSYNC
|
||
* FR3: Receiving Mail Packet
|
||
|
||
Fido uses XMODEM CRC or CHECKSUM to receive the packet. Note the
|
||
"duplicate 0"; this is the ACK of the SEAlink block. Fido does NOT
|
||
support SEAlink.
|
||
|
||
In a past discussion in FTSC echo, it was left unclear (to me) whether
|
||
ACKing the SEALINK block (SOH block 0) is considered "receiver uses SEALINK
|
||
protocol", or if that is determined some other way. Fido simply ACKs it
|
||
as a "previous block".
|
||
|
||
* XMODEM/CRC: INBOUND\3.IN 0
|
||
* XMODEM/CRC: Duplicate 0
|
||
* XMODEM/CRC: Protocol Complete 0
|
||
* FR4: Received 1 packets (128 bytes)
|
||
|
||
File attach, of course, fails. I believe it has to do with SEALINK vs.
|
||
MODEM7/TELINK.
|
||
|
||
There is one thing that puzzles me: Fido gets a TELINK block (SYN), as
|
||
noted below in XR1-4. It gets a bad checksum (every time your system calls me)
|
||
then your end hangs up on mine. No retries. Is it assuming that if it doesn't
|
||
accept a SEALINK block (SOH/0) it *must* accept a TELINK block?
|
||
|
||
(Note that TELINK blocks are *always* in CHECKSUM, even if the rest
|
||
of the transfer is CRC!!!!!! I think this hangs up a lot of people...
|
||
it's been this way since 1981, when the idea was to allow upswitching from
|
||
checksum to CRC (as there were Telinks (aka Ptel's) that didn't do CRC ...)
|
||
|
||
* FR5: Receiving (possible) attached files
|
||
* DIETIFNA: BR1-2: Got filename 0
|
||
* DIETIFNA: BR1-2: Got filename 0
|
||
* DIETIFNA: BR1-3: Filename skip 0
|
||
* DIETIFNA: XR1-4: TELINK Block 0
|
||
* DIETIFNA: XR2: Bad Checksum 0
|
||
|
||
This means unexpected carrier loss, ie. CD dropped during a character
|
||
read or write.
|
||
|
||
(Carrier loss or timeout during packet or file)
|
||
* Total connect time was 0:28
|
||
|
||
* Packet from 1:109/0
|
||
0 messages
|
||
---- Complete at 21:04:53
|
||
|