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

  • src/syncterm/telnet_io.c

    From Deucе@VERT to Git commit to main/sbbs/master on Sun Dec 25 00:36:23 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/836593162c49c5ccf5469240
    Modified Files:
    src/syncterm/telnet_io.c
    Log Message:
    Whitespace cleanup

    ---
    ￭ 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 Apr 23 00:25:42 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/2bae9a96e637c06d8f48c8c6
    Modified Files:
    src/syncterm/telnet_io.c
    Log Message:
    Track Telnet Binary TX mode set by server via Telnet (IAC) commands

    As reported by Chris/akacastor (21:1/162), SyncTERM would always assume the Telnet session was in ASCII mode until/unless conn_binary_mode_on() was called which is only called at the beginning of a file transfer, which sets the conn_api.binary_mode accordingly. Unfortunately, if the Telnet server
    requested binary mode itself (e.g. during initial connection), SyncTERM would (try to) set the connection back to ASCII mode after any file transfer. :-(

    With this change, the conn_api.binary_mode will track the actual binary TX
    mode whether initiated locally or remotely (by the server), but it'll only be set to true when *both* directions are succesfully set to binary mode. And
    this way, if the connection was already in binary mode before any file transfer, it'll remain in binary mode as was apparently desired by the server.

    Also with this change, we could probably remove the setting of conn_api.binary_mode to true/false in conn_binary_mode_on()/off() functions, but it shouldn't hurt anything if it's left there I suppose (in case some *other* terminal transport protocols have the concept of binary mode?).

    ---
    ■ 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 Apr 26 09:27:51 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/90bdf8c207ced9796d7820be
    Modified Files:
    src/syncterm/telnet_io.c
    Log Message:
    Fix CID 425333: update_binary_mode() is a function returning void

    ---
    ■ 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 May 27 23:14:45 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/1c7c3efd14a0cd6b4aec9af1
    Modified Files:
    src/syncterm/telnet_io.c
    Log Message:
    We don't support echo (sending what we receive back to the server).

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Thu Apr 3 05:20:12 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/9a9a81ea0a4c6a5666ca5ae0
    Modified Files:
    src/syncterm/telnet_io.c
    Log Message:
    Fix telnet binary mode tracking.

    When SyncTERM started by enabling binary mode in both directions,
    the internal tracking of the binary status wasn't updated, so it
    was incorrectly tracked as being in NVT mode. After a file
    transfer, it would then revert to the NVT mode it throught it was
    in.

    This change updates the binary mode value when sending as well as
    receiving TELNET_BINARY_TX.

    This is still technically broken though since binary mode is
    negotiated separately in each direction, and the initial send of
    WILL + DO is actually a pair of requests that need to be confirmed
    by the remote. Until they are confirmed, the connection is still
    in NVT mode.

    Hopefully though this isn't an issue since the remote should reply
    to both, and if it denies there's no effective difference between
    what we should do when already in binary mode and not because we
    don't support any other modes (such as CHARSET option). Fixing it
    correctly would get very complex and involve blocking the connection
    until we get a response.

    ---
    ￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Sun Mar 15 01:06:05 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/6986bd4168837eed5e5593a2
    Modified Files:
    src/syncterm/telnet_io.c
    Log Message:
    Fix telnet parser getting stuck on long subnegotiations

    telnet_interpret() stores incoming subnegotiation bytes in
    telnet_cmd[64]. When the buffer fills, telnet_cmdlen stays at 64
    and no further bytes are stored. The IAC SE termination check at telnet_cmd[telnet_cmdlen-2] then reads stale data and can never
    match, so the parser permanently stays in SB mode and swallows all
    subsequent terminal output.

    Fix: when the buffer is full, slide the last two bytes forward so
    that position [62] always holds the previous byte and [63] holds the
    current byte. The existing telnet_cmd[telnet_cmdlen-2] check then
    sees a fresh IAC when it arrives, and correctly terminates the
    subnegotiation.

    A malicious (or just chatty) server sending e.g. a >64-byte
    ENVIRON or NEW-ENVIRON SB would trigger this.

    Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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