GitLab

Subpacket OVERFLOW means received subpacket byte offset is >= the max subpacket length.

The previous committed fix/issue raised some additional concerns about this "parity" bit:

Something I didn't notice before from the ZMODEM spec:
"The hex header receiving routine ignores parity."

And looking at lrzsz's zm.c, I see it goes even further and ignores the "parity" bit on the ZPAD and ZDLE bytes proceeding the frame encoding byte as well as in the frame encoding byte itself (so ZHEX, 'B' 0x22 and 0xC2 should be treated as equivalent).

I find it strange that some ZMODEM implementations (e.g. chuck's zshhdr()) would send the terminating LF with the even-parity bit set, but not set the even-parity flag for any of the frame content bytes. And then, expect that the parity flag may be set on incoming hex headers. I suppose it makes sense for 7-E-1 connections, but then the transmitted terminating LF would have had its parity flag set automatically (would not need to be set manually in the code). Add to the mysteries of ZMODEM that will likely never be solved.

Some ZMODEM implementations set the high bit (even parity?) when sending this '\n' terminator.
As reported via IRC:
<Keyop> sexyz: !zmodem_recv_hex_header HEX header not terminated with LF: 138 (8Ah)

The default is still full-streaming mode. The default can be changed by
setting [ZMODEM] MaxWindowSize in sexyz.ini to a maximum window size to
use by default (e.g. "100K"). Additionally, a [ZMODDEM] TargetWindowSize
can be set to a duration (e.g. 60s) to dynamically adjust the maximum
window size to match the through-put rate while keeping the outstanding data
in-flight to an estimated "duration". When TargetWindowSize is used, the
MaxWindowSize only specifies the *initial* maximum window size.

The new '-w' command-line option can be used to control Window Management
support (e.g. over-riding the .ini set default) - by using '-w' or '-w0',
Window Management won't be used or by using '-w<max-size>', a maximum window
size will be imposed (subject to the TargetWindowSize setting mentioned
above). <max-size> can be specified in bytes or multiples (e.g. "-w100K").
Ths option is similar to the [l]sz '-w' option except no space is expected
between '-w' and the (optional) max-size value.

Also new, when receiving [ZMODEM] FullDuplex can be set to FALSE to disable
streaming mode: if the RecvBufSize is not set (0), the sender should use the
subpacket data length (block size, e.g. 1K) as the segment size. Otherwise,
setting FullDuplex=FALSE should produce the same behavior as setting the
RecvBufSize would before (the result being the use of "segmented ZMODEM"
instead of "streaming ZMODEM").

All sexyz command-line options are case-sensitive now (not just the 'cmds').
A lot of code clean-up in zmodem.c.

Incremented zmodem.c rev to 2.0.
Incremented sexyz version to 3.0.

More logging details (e.g. subpacket byte progress).
Identify XON and XOFF by name (e.g. when purging receive buffer).
Some variable naming and comment improvements.

Also, zmodem_send_raw() was saving the "last sent" char, even if it wasn't successfully sent.

Eliminated the "errors" mode of zmodem_recv_header_raw() since was no longer used.
Eliminated zmodem_recv_header_and_check() since it's no longer used.

Some debug-log fix-ups (e.g. with progress/offset).

only when the errored data subpacket was a ZCRCW (waiting for ZACK).
To resolve a non-streaming failure to recover after CRC error issue.

Makes easier trace/debugging of issues (e.g. matching up with sending side logs).
No functional change.

__FUNCTION__ cannot be used a string literal in GCC.

Previously, a ZRINIT frame would be sent even after a failed file download, and this could be misinterpreted by the sender as a successful file receipt 
 acknowledgement. 'lrz' just completely aborts the receive "batch" under the same conditions, so we'll just do the same to prevent the sender (e.g. BBS) from mistakenly counting this as a successful transfer (download).

A lot of log message updates: additions, removals, and use of the __FUNCTION__ macro.

file named in the ZFILE frame, they will usually compute the local CRC
value and request the sender to compute and send its CRC of the file it
wants to send. If the CRCs match, the receiver will send a ZSKIP frame
next ("skip this file, I already have it"). However, when I implemented
the ZCRC frame support in zmodem_send_file(), I added the ZCRC frame
check *after* the check to see if its a ZSKIP frame, when in fact, they
will normally come in the other order (ZCRC, then ZSKIP). This would result
in multiple ZCRC request/response, then ZSKIP requests that were ignored
by the sender (who just send a ZFILE frame again). Simple fix: check for
ZCRC frame before ZSKIP frame.

warning: ‘sprintf’ may write a terminating nul past the end of the destination

Jacques Mattheij to Stephen Hurd. I'm assuming the derived code is now jointly
copyright by Stephen and myself, so maybe some notices needed to be updated.
<shrug>

Likely cause of truncated filenames to three chars.

Located by DigitalMan, reported on DoVeNet by someone else.

I've likely broken something though, so if you see weird behaviour with
extended ASCII, let me know please.

This is *likely* to break the Win32 build and even when the macros are
specified in xpdev, I doubt Microsoft has added support for the 'z' size
specifier used in smblib/smbadd.c we'll likely need a SIZE_T_SIZE macro
that is "z" on C99 systems and "ll" or "64" or whatever it is on Win32.

Or maybe a whole slew of complete SIZE_T macros since the 32/64 but thing
and the max file size thing may actually need the full format specification
to be in the macro... "zu" on C99 platforms and whatever magic Microsoft
needs there.

partial file CRC.  Prevents waiting for both ends to do so sequentially.

and fixed possible local abort ignore due to previous commit.
Some if/else/if to switch/case conversion.

This prevents is_cancelled from being called three times for ever recv_byte

_FILE_OFFSET_BITS=64, and use fseeko() and ftello() for 64-bit offset support
(instead of fseek() and ftell()) - also redefine off_t on Win32 to int64_t and
removed filelen_t and fileoff_t typedefs (use off_t instead).

size.

milliseconds.