1. 28 Apr, 2022 1 commit
  2. 20 May, 2021 1 commit
  3. 22 Feb, 2021 1 commit
  4. 18 Feb, 2021 1 commit
  5. 14 Feb, 2021 1 commit
    • Rob Swindell's avatar
      Strip/ignore high (parity) bit in ZPAD, ZDLE, and hex headers · 0f7716c0
      Rob Swindell authored
      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.
      0f7716c0
  6. 13 Feb, 2021 1 commit
    • Rob Swindell's avatar
      Accept hex headers terminated with 0x8A · 12ac1fc4
      Rob Swindell authored
      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)
      12ac1fc4
  7. 04 Dec, 2020 2 commits
    • Rob Swindell's avatar
      48a6feb2
    • Rob Swindell's avatar
      ZMODEM Window Management support · 483c86de
      Rob Swindell authored
      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.
      483c86de
  8. 28 Nov, 2020 4 commits
  9. 27 Nov, 2020 3 commits
  10. 16 Aug, 2020 1 commit
  11. 25 Aug, 2019 1 commit
    • rswindell's avatar
      Fix a 14-year old bug with ZMODEM-send. If the receiver already has the · fba33a15
      rswindell authored
      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.
      fba33a15
  12. 01 Feb, 2019 1 commit
    • rswindell's avatar
      Address GCC v7.3.0 · de64ad21
      rswindell authored
      warning: ‘sprintf’ may write a terminating nul past the end of the destination
      de64ad21
  13. 20 Feb, 2018 2 commits
  14. 01 Feb, 2018 1 commit
  15. 19 Nov, 2015 1 commit
  16. 14 Nov, 2012 2 commits
  17. 24 Oct, 2012 1 commit
  18. 29 Oct, 2011 1 commit
    • deuce's avatar
      Fix format-related warnings. · 8563ad46
      deuce authored
      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.
      8563ad46
  19. 21 Oct, 2011 1 commit
  20. 12 Mar, 2010 2 commits
  21. 10 Mar, 2010 3 commits
  22. 09 Mar, 2010 2 commits
  23. 08 Mar, 2010 2 commits
  24. 06 Mar, 2010 1 commit
  25. 05 Mar, 2010 3 commits