Subj : docs/xymodem_verification.md
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Sun Aug 30 2026 17:21:07

https://gitlab.synchro.net/main/sbbs/-/commit/5a540e056f80c1af0ba86942
Modified Files:
	docs/xymodem_verification.md
Log Message:
docs/xymodem: compare the three knob failures against lrzsz and DSZ

The first cut reported three options that fail hard rather than
degrading, and left it there.  That was the wrong stopping point: XMODEM
has no capability negotiation, so somebody has to degrade, and the useful
question is whether anyone else does better in the same situation.
Measured against both references, the three sort into three different
verdicts.

CRC fallback is ours to be proud of.  XMODEM-CRC specifies the
degradation on the receiver: ask with C, fall back to NAK after enough
unanswered attempts.  Put a checksum-only sender in front of each
receiver and sexyz rc falls back and completes in 12 seconds, DSZ rx
falls back and completes, and lrz --xmodem -c does not, timing out at
40.  So the deadlock reported for SendCRC=false is lrzsz declining to
degrade, not us.

G-mode fallback is ours to fix.  The mirror test, a sender refusing G in
front of a G-mode receiver: DSZ rb -g drops out of G and completes, while
sexyz rg gives up with "Error fetching YMODEM header block" after 27
seconds.  That is the clearest actionable item in the document.

And the receive-side block-size cap has nothing to compare against --
neither lrz nor DSZ exposes such a setting -- so MaxBlockSize is
Synchronet-only and its sole reachable effect is to break a transfer that
would otherwise work.

The common thread that survives all three: when a capability mismatch
ends a session, nothing in the log names the cause.
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.