• 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
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Wed Sep 13 18:56:11 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/23cd780b3dc51f1d55398748
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Remove redundant timestamp from "End of preexisting log entry" log message

    Most logs sysops are looking at already have a date/timestamp for each
    message, so this one ended up with 3 date/timestamps in a single line.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Tue Sep 19 18:37:16 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/e5f64faf337040f12844c4cc
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Log a critical error message if a node is WFC, but its socket is still in use

    This should avoid/work-around issue #630

    Nelgin's terminal server log indicated that the node's configuration was being reloaded for a new client connection (which doesn't normally/always happen, only when there's been a config file change or a node "rerun" requested),
    while there was still a user online using that node. This would explain the segfault (configuration fields being freed and reallocated).

    The node_socket[] array indicates when a node thread is actively servicing
    a client, so it should contain INVALID_SOCKET for the any node's that WFC.
    If it doesn't, that means something/someone changed the node's status value
    to 0 (WFC) in the node.dab file while the node was still in-use. Let's not crash in this case and rather just log the message and give the client the
    next available node (if any).

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Sun Sep 24 01:32:43 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/229cca918d31e14add4b2ef7
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Close node socket after waiting one hour to go inactive to run exclusive event

    After 90 minutes of waiting, we'll do the same abort wait (and run the event anyway), but closing the node's socket should be enough to get the node_thread to terminate and set the node status back to NODE_WFC.

    Apparently some sysops like to leave their terminals idling (e.g. running MRC) and never disconnect and since they're T-exempt, the BBS won't limit their
    time online to allow events to run. Exclusive events will wait for all nodes
    to become inactive, but give up after 90 minutes of waiting and run the event anyway and set node status to WFC at the end. If the node was actually still connected/in-use, this could lead to the (new) critical error messages logged "!Node X status is WFC, but the node socket (N) and thread are still in use!" and other chaos (NODE STATUS FIXUP and the like).

    This should prevent all that by just abruptly disconnecting the node after waiting 60 minutes for the sysop to gracefully disconnect. The log message
    when this happens:
    "!TIRED of waiting for node N to become inactive (status=X), closing socket Y"

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Mon Sep 25 18:07:33 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/6b49ddffc9b3ee4bb3bdb3c1
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Auto-recycle the term server if/when the ctrl/text.ini file is created/touched

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sat Nov 11 13:07:10 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/230bd5872d55cb239b03aeed
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    js_init() now logs notice-level messages upon runtime or context creation fail

    js_init() failures are now logged with a critical error level (instead of just "error").

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Fri Dec 29 10:17:20 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/1994a535b8c0e688e8a139fc
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Don't log error on final channel message

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Thu Jan 4 19:19:36 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/7df6956da2b4246a9ca3940e
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Don't log an error if there's QWKnet sub pointer value to be read

    This partially reverts commit 44c3350f where a bunch of read() and write() return value checking was added.

    ---
    ■ 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 Thu Jan 11 00:33:48 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/bac2285755b0eda8a209e365
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Another fix for the read() reutrn value FORTIFY warning

    that doesn't log an error

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Jan 17 13:31:24 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/a8374b52cbc57902bb303d7e
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    second part of commit 0b1b1a6f

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Jan 20 20:25:21 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/e53f173153fdaf0341cca95c
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Remove unnecessary call to DuplicateHandle() in Win32 builds of sbbs_t::init()

    The client_socket_dup is overwritten after with the return value of accept(), so this was likely a socket/handle leak (since commit 74470573, 17 years ago).

    Noticed this only after logging a new error in an SSH connection when this
    call to DuplicateHandle() failed for some reason (WinError 6), but it seems like it's been redundant code for a long time now. So just ace it and possibly fix a resource leak.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Mon Jan 22 17:43:44 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/346a2d304c7d921d656489ad
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Log the socket descriptor and protocol when getsockname() fails

    This is a new error that just started cropping up. I suspect it's related to recent SSH changes. This might help a little with context, when it happens again.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tue Feb 6 12:35:50 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/af7852df11093dc6ed559f64
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Ignore remove() return value purposefully in this case.

    Does this resolve Coverity warning? I don't rember.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Wed Feb 7 12:23:42 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/2b2d8289b92d7f6e6faa1633
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    More time_t printf fun.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Feb 14 15:11:56 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/1e734d10425f7ca7fb239931
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Remove line that was commented-out 14 years ago

    Commit d1182efc

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sat Feb 24 14:54:24 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/0a6c1f00de9e4457f598b4f4
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Log a warning if failed to write to spy ring buffer

    ---
    ■ 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 Sat Feb 24 20:31:04 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/4fa2aa66fda6be0ef693f512
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Don't log an error if spy socket write return EPIPE (expected)

    Also, resove a new gcc warning about signed/unsigned compares.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Mon Feb 26 22:41:59 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/a474017fb7c51f91ef9c4095
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    sbbs_t::incom() should return NOINP immediately if/when socket disconnected

    JS console.inkey() and friends use this as the underlying function to get
    input from the TCP socket.

    This might address issue #725

    Hoping Nelgin will let us know.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Tue Feb 27 20:20:48 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/4c893720f8e0c57753b08a91
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Attempt to fix error nelgin reported with ssh session timeouts

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Wed Feb 28 15:29:55 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/e4adbcb541c6f7139e63d2ca
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Prevent the input thread from closing channel that has a session,
    but does not yet have a session type.

    Also, fix what appears to be a fairly blatant memory leak.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From DeucĘ@VERT to Git commit to main/sbbs/master on Thu Feb 29 11:55:23 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/346849ac253a08374b9bfca0
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Unlock ssh_mutex before calling sftps_recv()

    This should fix the sftp hangs...
    While FreeBSD will return EDEADLOCK when a mutex would deadlock,
    Linux will do what I ask and deadlock.

    Since we're not checking the return value of pthread_mutex_lock(),
    this would go completely unnoticed on FreeBSD, resulting in the
    mutex being unlocked early and all sorts of unprotected accesses
    would happen, potentially doing crazy things. On Linux it just
    deadlocks, and taking a peek at the thread backtraces makes the
    problem obvious.

    So, point to Linux for making life more correct for people who
    do incorrect things (locking without checking the return value).

    I'd also like to thank nelgin, for sticking with me on this issue
    and being my gdb puppet.

    And really, this commit should be shared by all the contributors
    who... ĘĘĘĘ

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Thu Mar 21 23:34:07 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/c846776318dc4ca28946083c
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Break stuff to test things.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Thu Mar 21 23:38:26 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/eddcfe2f9b10d250d16a6c7f
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Now unbreak!

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Fri Mar 22 21:28:05 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/be8603b11bd6cf12c6f74256
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Replace (and auto-upgrade) ctrl/time.dab with time.ini

    This will allow us to change scfg_t.event[].last to a time_t value (from time32_t) whenever we abandon Borland C/C++ in the future.

    Now it's trival for sysops to view/edit when their timed events 'last run' values. And there's no more endianness concerns. Bad .dab files, bad, go away.

    After I wrote this change, I found the original conversion code in v4upgrade.c which is almost exactly the same (except I was going to write to different filename). Finally actually implemented this. Next up: qnet.dab

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Fri Mar 22 21:28:05 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/03be991a6f30b98ae9c0320b
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Convert (and auto-upgrade) ctrl/qnet.dab to ctrl/time.ini as well

    I suppose this should've been part of the previous commit.

    Again, this is almost verbatim what v4upgrade.c did (though never actually used).

    ---
    ■ 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 Mar 22 22:50:36 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/19ab720de38838ae2e4e1154
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Resolve recently introduced warnings about const char* to char* conversion

    C++ <sigh>

    We don't need a .ini section separator anyway.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Mon Apr 8 16:32:54 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/00a80d45d884c9ab547fef31
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    exec/*.bin cmd shell filenames were case sensitive (must've been lowercase)

    ... while the mods/*.bin command shell filenames could be any-case!

    Only impacted non-Windows systems (UNIX file systems are case-sensitive).

    Discovered while making this tutorial video: https://youtu.be/HlwQ0uX4S04

    ---
    ■ 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 Wed Apr 10 23:07:19 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/76b5c7f4399c7774c368c754
    Modified Files:
    src/sbbs3/main.cpp
    Log Message:
    Resolve CID 492287 - we don't care about the fexistcase() return value here

    We're just using it to "fix" the case, if the file indeed exists.

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