1. Forum
  2. FidoNet
  3. SYNC SYSOPS

  • Asymmetric UTF-8 autoterm detection corrupts user charset settings

    From HM Derdok@1:103/705 to GitLab issue in main/sbbs on Sat Mar 28 12:07:48 2026
    open https://gitlab.synchro.net/main/sbbs/-/issues/1106

    # Bug Report: Asymmetric UTF-8 autoterm detection corrupts user charset settings

    **Date:** 2026-03-28
    **Affects:** Synchronet BBS v3.20+ (confirmed on v3.21)
    **Component:** `src/sbbs3/logon.cpp`, `src/sbbs3/answer.cpp`
    **Related commit:** `aa0539b89` ("What appears to be a more complete fix for auto vs manual terminal adjustment", 2026-01-03)

    ---

    ## Summary

    There are two interrelated issues that combine to corrupt registered users' terminal charset settings:

    1. **One-way autoterm persistence in `logon.cpp`** — When autoterm detects UTF-8, the user record is upgraded to UTF-8, but when autoterm does NOT detect UTF-8 (i.e. CP437), the user record is never downgraded back. This means a single false positive permanently corrupts the user's charset setting.

    2. **False UTF-8 detection over WebSocket proxy** — The UTF-8 BOM probe in `answer.cpp` is timing-sensitive. When the connection path includes a WebSocket intermediary (e.g. `websocketservice.js` used by fTelnet web terminals), the additional latency causes intermittent false positives in the UTF-8 cursor displacement check.

    Either issue alone would be manageable, but together they create a ratchet effect: WebSocket latency occasionally triggers a false UTF-8 detection, and the one-way persistence ensures it sticks forever.

    ---

    ## How to reproduce

    ### Environment

    - Syn
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sat Mar 28 13:09:05 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1106#note_8698

    I've not been able to reproduce the "False UTF-8 detection over WebSocket proxy" issue as described on https://web.synchro.net, which uses ftelnect over the websocketservice.js and always autodetects "80x25 CP437 / ANSI" for clients connecting in this way.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sat Mar 28 13:32:01 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1106#note_8700

    Is the user in question's account configured for terminal auto-detect or not? --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sat Mar 28 13:57:38 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1106#note_8701

    The BBS in question is heavily modified from stock/default, do we even know if the code in `logon.cpp` (`sbbs_t::logon()`) is being executed?

    In `sbbs_t::logon()`, any user that has the auto-terminal type detection enabled (and that should be almost *all* users), has their terminal-related 'misc' flags (including UTF8) overridden by whatever was auto-detected:
    ```
    if ((useron.misc & AUTOTERM) ...
    useron.misc &= ~manual_term; // these flags are forced off, Including UTF8
    useron.misc |= (AUTOTERM | autoterm); // Any auto-detected term flags (including UTF8) are set
    ```
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sat Mar 28 18:20:58 2026
    https://gitlab.synchro.net/main/sbbs/-/issues/1106#note_8702

    Do you have a screenshot you can attach that demonstrates "Observe that extended ASCII / CP437 box-drawing characters now render incorrectly (the BBS is sending UTF-8 encoded output to a CP437 bitmap font terminal)"?
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)