1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/zmodem.c

    From rswindell@VERT to CVS commit on Thu Jan 31 21:50:00 2019
    src/sbbs3 zmodem.c 1.122 1.123
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv32090

    Modified Files:
    zmodem.c
    Log Message:
    Address GCC v7.3.0
    warning: ‘sprintf’ may write a terminating nul past the end of the destination



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Digital Man@VERT to rswindell on Thu Jan 31 22:10:00 2019
    Re: src/sbbs3/zmodem.c
    By: rswindell to CVS commit on Fri Feb 01 2019 02:50 am

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

    A fix for these UTF-8 chars in the commit messages, btw, is to 'export LANG=C'. :-|

    digital man

    This Is Spinal Tap quote #31:
    Viv Savage: Quite exciting, this computer magic!
    Norco, CA WX: 47.1øF, 94.0% humidity, 0 mph SSW wind, 0.42 inches rain/24hrs

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Sat Aug 24 16:05:34 2019
    src/sbbs3 zmodem.c 1.123 1.124
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/home/rswindell/sbbs/src/sbbs3

    Modified Files:
    zmodem.c
    Log Message:
    Fix a 14-year old bug with ZMODEM-send. If the receiver already has the
    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.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Thu Nov 26 20:48:05 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/df15131bdb18831c6646ddff
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    zmodem_recv_files() now returns upon first failed file.

    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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Thu Nov 26 21:04:08 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/6ffdef9ff1449de30ea478ce
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Fix build error introduce in previous commit.

    __FUNCTION__ cannot be used a string literal in GCC.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Fri Nov 27 09:07:55 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/8a4698c5a581d8a42c462878
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Include file/progress byte-offset at the beginning of log messages

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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Fri Nov 27 17:02:22 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/b8797f3e9335f0bb89883cdb
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    More log output messages/detail. No functional change.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Fri Nov 27 19:39:25 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/d1259998004d6e3f47be6066
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    zmodem_recv_file_data() will purge receive buffer before sending ZRPOS, but...

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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Fri Nov 27 21:43:29 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/421db04420bcc48b5ca3f38f
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Insure receive buffer is purged before sending ZRPOS.

    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).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Nov 28 00:07:12 2020
    https://gitlab.synchro.net/main/sbbs/-/commit/074edbc12b9163e8a0e8e10b
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Better HEX frame corruption detection.

    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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Feb 13 10:14:08 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/12ac1fc4c828739d5a76e66b
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Accept hex headers terminated with 0x8A

    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)

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Feb 13 11:40:27 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/0f7716c038d4a6f37947f888
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Strip/ignore high (parity) bit in ZPAD, ZDLE, and hex headers

    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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Thu Apr 28 10:05:48 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/3bfa626d494d44afd5d6e32a
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    Fix erroneous error message

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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (in GitKraken)@VERT to Git commit to main/sbbs/master on Thu Feb 16 00:01:50 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/b4e181688c06a2a05280947f
    Modified Files:
    src/sbbs3/zmodem.c
    Log Message:
    64-bit free disk space fix

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