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
|
|||
|
|
|