1. Forum
  2. FidoNet
  3. SYNC SYSOPS

  • Questions regarding Zmodem download/upload reliability for linux hosts

    From Alex Ackermann@1:103/705 to GitLab issue in main/sbbs on Fri Dec 22 08:13:27 2023
    open https://gitlab.synchro.net/main/sbbs/-/issues/691

    Hi, in my recent testing ``zmodem-streaming`` between ``git.synchro.net`` and my Debian 12 linux powered by lrzsz+zssh failed after transferring few files (check attachment-1, it just messed up the whole screen). Luckily ``zmodem-windowed`` didn't fail (I have tested only once though). ``-windowed`` did print error message (``Retry 0: Got ERROR``), but I am not sure if that's false alarm from rz command on client side (check attachment-2).

    Sexyz wiki [section on streaming](http://wiki.synchro.net/util:sexyz#zmodem_streaming) mentions that "SEXYZ supports the following ZMODEM streaming modes, in order of decreasing successful data transfer assurance". Does that apply also apply to connections between Synchronet BBS server talking to a Linux/Windows machine running programs like ``rz`` over zssh/ztelnet, or just when Synchronet is connected to a old-style modem? (am pretty new to BBSing, please pardon my lack of understanding).

    The reason I ask is: I want to setup a BBS for modern Linux geeks, and would want to provide only the most reliable download experience (as in our times it is unheard of to have download/upload failures). Is unreliability indispensable when communicating over zmodem protocol between Linux remote server and client? Does synchronet plan to support sftp for downloads? Is there a recommended streaming mode that linux clients powered by zssh+lrzsz use when dealing with downloads/uploads? One thing that would really help is to document expected/mandatory flags for ``rz`` and ``sz`` commands for all the respective streaming modes. IMHO, newbies from Linux land like me who are new to BBSing do not really understand if/when to pass any flags when talking to BBS servers. Here's the Debian documentation for lrzrz's [rz](https://manpages.debian.org/bookworm/lrzsz/rz.1.en.html) and [sz](https://manpages.debian.org/bookworm/lrzsz/sz.1.en.html) commands.

    1) zmodem_streaming, garbled text in upper tmux pane: ![zmodem_streaming](https://gitlab.synchro.net/main/sbbs/uploads/9b373b455568d8d8f3522d459aef63fe/zmodem_streaming.png)

    2) zmodem_windowed, ``Retry 0: Got ERROR`` in upper tmux pane: ![zmodem_windowed](https://gitlab.synchro.net/main/sbbs/uploads/1b3b6027e571e8bf1de825710c29ceef/zmodem_windowed.png)
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri Dec 22 12:37:29 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/691#note_4603

    Does synchronet plan to support sftp for downloads?

    No, but Synchronet already supports FTPS and HTTPS for downloads.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri Dec 22 12:43:33 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/691#note_4604

    YMODEM (slow ack/nak protocol) and YMODEM-G should provide 100% reliability, though they're not as convenient as ZMODEM.

    And honestly, if you run lrzsz (or equivalent) on both ends of the TCP session, you'll probably get 100% ZMODEM reliability as well. While Chuck's code is hard to follow, it does seem to provide the best performance and reliability (on *nix), so I usually test w/lrzsz (on the client side) to confirm any performance or interoperability problems with SEXYZ (on the server side) or lrzsz on the server and SyncTERM on the client.

    Running SEXYZ/SyncTERM on both sides should not provide any obvious performance or reliability advantage.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri Dec 22 12:49:14 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/691#note_4605

    IMHO, newbies from Linux land like me who are new to BBSing do not really understand if/when to pass any flags when talking to BBS servers.

    I agree it can be confusing: some of the *MODEM protocol options are controlled on the sending side (when uploading, that's the client and when downloading, that's the server) and some are controlled on the receiving side.

    Usually, ZMODEM "just works" and requires no special options to make it reliable. However, when dealing with UART<->TCP gateway devices (or similar unique setups), the asymmetry of the speeds and buffer sizes between the links can introduce surprising behavior/failures. lrzsz usually seems to deal with these issues better than SEXYZ, but sometimes changing protocol options can often resolve or improve the situation. SEXYZ is still a work in progress for matching or beating the performance and reliability of lrzsz in all situations.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Sat Dec 23 13:19:42 2023
    https://gitlab.synchro.net/main/sbbs/-/issues/691#note_4610

    Regarding sftp and scp specifically, neither protocol was documented at all last time I looked, so implementing either requires digging deeply into the OpenSSH code to extract the details. If there's actual documentation at some point, it should be fairly straight forward to implement them.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Thu Feb 1 14:02:14 2024
    https://gitlab.synchro.net/main/sbbs/-/issues/691#note_4751

    I've started implementing SFTP in Synchronet (and SyncTERM). That said, a mechanism to initiate an sftp file transfer from within the terminal session is still in the distant future, and even when it exists, will require client support (which, with OpenSSH, will likely be somewhat painful to use if it's even possible).
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)