forked from MirrorRepos/RomWBW
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
77 lines
3.4 KiB
77 lines
3.4 KiB
XModem 12.5 & Tera Term Anomaly Analysis
|
|
----------------------------------------
|
|
|
|
Protocol Notes:
|
|
|
|
- During protocol startup, the receiver NAKs the sender repeatedly
|
|
to let the sender know it can start sending.
|
|
- Normally, the receiver sends a NAK character to ask the sender to
|
|
resend a packet.
|
|
- Prior to receiving the first packet, the receiver may send a "C"
|
|
or a "CK" instead of a NAK. This mechanism is used to inform the
|
|
sender that the receiver wants to use (C)RC error detection
|
|
instead of checksum error detection and optionally 1(K) packet sizes.
|
|
- After the first packet exchange, a NAK is always used to
|
|
request a packet be resent.
|
|
|
|
Anomalous Exchange Description:
|
|
|
|
XModem on RomWBW is being used to receive a file being sent
|
|
by Tera Term on a Windows PC...
|
|
|
|
- XModem is started in receive mode
|
|
- User starts process of selecting a file to send on Tera Term
|
|
- XModem begins sending "CK" sequences as described above
|
|
to wake up the sender
|
|
- Tera Term buffers incoming "CK" sequences while user is selecting
|
|
a file to send
|
|
- User completes file selection
|
|
- Tera Term receives the first "CK" which was buffered while user
|
|
was selecting a file
|
|
- Tera Term correctly receives the first "CK", sets itself to
|
|
use CRC and 1K packets, then sends the first packet
|
|
- While waiting for Tera Term to send the first packet, XModem
|
|
is repeatedly timing out and resending the "CK" sequence
|
|
- For each timeout, XModem spends 1 second flushing any incoming
|
|
characters from the sender (it assumes it is flushing line garbage).
|
|
- IFF the first packet from Tera Term starts to arrive during this
|
|
1 second flushing interval, XModem gobbles up and discards the
|
|
first packet sent by Tera Term
|
|
- XModem then sends a new "CK" because it is still waiting for the
|
|
first packet (having just flushed the actual first packet)
|
|
- Tera Term has already switched out of "first packet" mode and will
|
|
now only respond to an actual NAK character, so it ignores all of
|
|
the CKs send from XModem
|
|
- XModem continues to send CKs and Tera Term continues to ignore them
|
|
until XModem hits a retry threshold
|
|
- When XModem hits the retry threshold, it attempts to switch from
|
|
CRC to Checksum assuming the sender was not capable of using
|
|
CRCs
|
|
- XModem now sends a NAK character because that is what is used for
|
|
for first packet NAKing in Checksum mode
|
|
- Tera Term sees the NAK and resends the first packet, but appends a
|
|
CRC instead of a Checksum because Tera Term is still in CRC mode
|
|
- XModem fails the Tera Term first packet resends because it is
|
|
looking for a Checksum and Tera Term is appending CRCs.
|
|
- XModem eventually gives up.
|
|
|
|
Summary of failure:
|
|
|
|
If Tera Term happens to start sending the first packet during the
|
|
one second "flush" window of XModem, the exchange will fail during
|
|
the startup sequence.
|
|
|
|
Since the precise start timing of the first packet is dependent on
|
|
the time the user takes to select a file, the occurrence of the
|
|
failure is essentially random.
|
|
|
|
The timeout used by XModem is about 5 seconds followed by the 1
|
|
second line flush. So, there is a 1 in 6 chance that the protocol
|
|
will fail to startup successfully.
|
|
|
|
Mitigation:
|
|
|
|
- Modified the receive timeout recovery to *not* flush the incoming
|
|
buffer for one second. Flushing in this scenario makes no sense
|
|
anyway because a timeout just occurred meaning no data is being
|
|
received.
|