mirror of https://github.com/wwarthen/RomWBW.git
b1ackmai1er
6 years ago
committed by
GitHub
GitHub
16 changed files with 371 additions and 85 deletions
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -0,0 +1,77 @@ |
|||
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. |
|||
Loading…
Reference in new issue