https://gitlab.synchro.net/main/sbbs/-/commit/2a64eab7ba97101c60761917
Added Files:
docs/xymodem_verification.md
Modified Files:
docs/zmodem_comparison.md
Log Message:
docs: verify sexyz's X/YMODEM interoperability and options

The option audit prompted by issue #1229 covered ZMODEM and left the
X/YMODEM knobs untested. Test them, in a separate document since zmodem_comparison.md is ZMODEM-only.

Interoperability is clean: all twelve sender/receiver combinations
against lrzsz and against Forsberg's 1997 DSZ transfer a 16 KiB random
file byte-for-byte. Every knob does something, so there is no second Escape8thBit here.

Three of them fail hard rather than degrading, which is the part worth
acting on. SendCRC=false hangs until the timeout against a receiver
that only ever requests CRC, because XMODEM's receiver drives and ours
will not answer its C. SendG=false dies 18 bytes in against a G-mode
receiver. And [XMODEM] MaxBlockSize is asymmetric: it does not cap an
explicit sX send, which still uses 1024-byte blocks, while on the
receive side it breaks an otherwise working transfer from a 1K sender
part-way through. None of these is a dead option -- each demonstrably
changes behaviour -- but turning a capability off yields a timeout or an
abort with nothing in the log naming the cause.

Also records a harness trap that cost a diagnostic cycle: YMODEM carries
the filename and DSZ writes it through DOS 8.3 rules, so xy.16k arrives
as XY.16K and a test looking for the name it sent reports a failure that
did not happen.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net