https://gitlab.synchro.net/main/sbbs/-/commit/04b47329aa0cfbc839ec1a4c
Modified Files:
docs/v322_new.md src/sbbs3/zmodem.c
Log Message:
zmodem: fix SIGFPE when the transmit window is under 4 blocks (#1197)

zmodem_send_from() picks the ack-request interval as

subpkts_sent % (max_window_size / block_size / 4)

which is a division by zero whenever the window is narrower than four
blocks: with -8 -w8192 the divisor is 8192 / 8192 / 4, that is 1 / 4,
that is 0. sexyz then dies with SIGFPE right after the ZRQINIT/ZRINIT handshake, having put about 3 KB of handshake on the wire and no file
data at all. Also affected: -8 -w16384, -2 -w4096, and the same window
sizes set through MaxWindowSize in sexyz.ini.

Clamp the interval to a minimum of one, so a window narrower than four
blocks requests an ACK on every subpacket, which is the only sensible
reading of "every quarter window" at that size.

Verified against lrz over the bench harness: -8 -w16384 and -2 -w4096
both used to die on signal 8 and now complete with a matching SHA-256, at
3.08 and 0.71 MB/s. Windows that already worked are unchanged, -w32768
at 4.88 MB/s and -w65536 at 5.03, as is streaming without -w at 11.6.

SyncTERM shares zmodem.c but never sets max_window_size, so it leaves the
value at zero, short-circuits the branch, and cannot reach this. The
exposure is sexyz only.

A window exactly equal to the block size (-8 -w8192) no longer crashes
but is still pathologically slow, roughly one subpacket per second with a one-second receive timeout each iteration. That is tracked separately in
the issue; it is not a regression, since it used to be a crash.

zmodem_ver bumped 2.3 -> 2.4. Release notes updated, including the already-shipped 2 GB windowed fix and Deuce's send-path speedups, which
had no v322 entry.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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