• src/sbbs3/main.cpp

    From Rob Swindell@VERT to Git commit to main/sbbs/m on Sat Jan 21 13:15:00 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/6426954c87ae1bd5c04691e4
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Don't attempt to remove a non-existing qwk-pack semfile

    Reduce occurrences of subsequent errors (unsure of root-cause):
    !ERROR 2 (No such file or directory) in main.cpp line 2778 (event_thread) removing "/sbbs/data/pack0341.now"

    This does seem to be the only location that deleted pack*.now files, so weird that they'd disappear sometime after calling glob(), but I do understand that its theoretically possible.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/m on Tue Jan 24 21:30:00 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/5f7f1104db341b7c52e4e209
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Don't try to upgrade */csts.dab and */dsts.dab files that don't exist

    In a fresh v3.20 install, the legacy stats files don't exist, so don't try
    to convert/upgrade them and log errors about it.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/m on Thu Feb 2 13:30:00 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/d60262aa81e4b14405e6fd57
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Lower severity of "Spy socket ... connected" log message from ERR (?) to INFO

    Looks like just a confluence of search/replace errors over the past 19 years, starting with commit 9ef382e50c6.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Fri Feb 10 21:52:17 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/95a07b236294a36633481033
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Fix crash when getting file area web_file_prefix in JSexec

    js_init was assuming that startup != NULL

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (in GitKraken)@VERT to Git commit to main/sbbs/master on Sun Mar 12 18:21:16 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/9eeb09f19514e1ccf10d85eb
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Fix PETSCII 40/80 column port connections for IPv6

    The connected TCP port detection method only worked for IPv4, so automatically detecting a CBM/PETSCII connection over IPv6 didn't work. Thanks to Deuce's xp_sockaddr and helper functions, this was an easy change.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sun May 7 13:45:08 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/d6544a7700951590fa2916a4
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Enforce telbuf size bounds (don't just log the overflow condition)

    This should resolve CID 453850

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Fri Jun 2 17:49:52 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/ca7ab040466b030281a9aaca
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Add a 60-second timeout to sbbs_t::passthru_socket_activate()

    Keyop reported an issue via irc whereby a user that failed to download a file would leave the node "hung" in "downloading via telnet" node status even
    though the user had long since disconnected and the log reflected that the terminal server was aware of this:

    term Node 4 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
    term Node 4 <user> sexyz: !zmodem_recv_header TIMEOUT
    term Node 4 <user> external Timeout waiting for output buffer to empty
    <minutes later>
    term Node 4 connection reset by peer on send
    term Node 4 !ERROR 32 sending on socket 102
    term Node 4 !ERROR 32 sending on socket 102
    term Node 4 !ERROR 32 sending on socket 102
    term Node 4 !ERROR 32 sending on socket 102
    term Node 4 !ERROR 32 sending on socket 102
    term Node 4 disconnected
    term Node 4 !ERROR 32 sending on socket 102

    and

    term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
    term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !Receive timeout (1 seconds)
    term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
    term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
    term Node 3 <user> external Timeout waiting for output buffer to empty
    <minutes later>
    term Node 3 connection reset by peer on receive
    term Node 3 !ERROR 32 sending on socket 96

    These nodes were then locked up in call to passthru_socket_activate(false)
    as reported by gdb, e.g.

    Looking at passthru_socket_activate(), the deactivation path (called at the
    end of external() in this case), it was clear that this could be an infinite loop in the case the user had disconnected:

    do { // Allow time for the passthru_thread to move any pending socket data to the outbuf
    SLEEP(100); // Before the node_thread starts sending its own data to the outbuf
    } while(RingBufFull(&outbuf));

    These flush/purge loops aren't strictly needed if the user has disconnected, but as can be seen by the above logs, the terminal server may not know that (the socket may not indicate disconnect) before passthru_socket_activate()
    is called by external().

    So... worst case, just do the activation and deactivation buffer flushes
    and purges for 60 seconds.

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