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

  • src/sbbs3/mqtt.c

    From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Wed Aug 9 18:28:43 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/bacc2eb16553c883400b3bf5
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    New MQTT topics that the terminal server will subscribe to for node changes

    <nelgin> can I push an intr instruction to a node with mqtt?

    node/#/set/status - set the node status value (to an integer)
    node/#/set/errors - set the node error counter (to an integer, e.g. "0") node/#/set/misc - set the node's miscellaneous attributes/flags value
    (hexadecimal values can be set by including "0x" prefix)

    The message (payload) doesn't matter for the following topics:
    node/#/set/lock - lock a node (no one but sysop can login)
    node/#/set/intr - interrupt a node (disconnect a user)
    node/#/set/down - down a node (not available for connections)
    node/#/set/rerun - rerun a node (reload config upon next connection)
  • From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Thu Aug 10 12:30:03 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/e7b1b02ea4167743a8fa6b22
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Allow a msg value of "0" to clear/unset the node/+/set/# topics/flags

    e.g. publishing "0" to node/#/set/intr will clear the node-interrupt flag.
    Any non-zero message value will "set" the flag. Same is true for the
    lock, down, and rerun topics/flags.

    These node attributes (misc) flags could be cleared previously
    by setting the 'misc' topic (e.g. to 0), but since that's not an atomic read/modify/write operation, other set misc flags could be lost clearing flags in that manner.
  • From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Thu Aug 10 12:30:03 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/7ae65021a8f4ffe3b47371ad
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Prioritize the node/+/input topics over the node/+/set/+ topics
  • From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Thu Aug 10 17:45:39 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/64d5e8d6623ea3c09fe8319f
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Allow triggering timed event or QWKnet call-out by publishing to MQTT topic

    - sbbs/BBSID/exec (publish the timed event's internal code)
    - sbbs/BBSID/call (publish the QWKnet hub's ID)

    The message contents are not case-sensitive.
  • From Rick Parrish to Git commit to main/sbbs/master on Sun Aug 20 16:48:10 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/42dc70557ff497584096de22
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Add a connect callback handler.
  • From Rob Swindell to Git commit to main/sbbs/master on Sun Aug 20 16:48:10 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/49e007b73339cd3c6300959c
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Merge branch 'Ree/mqtt-connect-callback' into 'master'

    Add a connect callback handler.

    See merge request main/sbbs!320
  • From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Wed Aug 30 18:12:59 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/622ffe3dceb089de77078f4d
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Remove MQTT message publishing from mqtt_connect_callback()

    A follow-up to commit 81d4575e

    Although I was not able to successfully reproduce the problem that Ree
    reported with his commit (even when changing the SCFG->Networks->MQTT->Publish QOS to 1: At least once) on Windows, I do see how this problem could theoretically happen. And like Ree said in the follow-up comment on the MR "maybe these two lines should have stayed in mqtt_startup", they don't really belong in the connection callback.

    The "client" topics only needs to be cleared upon startup or recycle (by publishing a null message) and it would be bad to clear these topics whenever the broker was reconnected (the server's clients didn't magically disconnect). So these "client" topic-clearing publishes are now only done during startup (again).

    The "recycle" topics don't really need to be published to here at all. I
    think I only did this for cases where someone published a non-null message to the topic and its stale message would remain afterward, appearing in MQTT browsers (like MQTT explorer) long after the server had recycled. The real solution to this cosmetic issue is to only publish null (0-length) messages to the "recycle" topics in the first place.
  • From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Sat Sep 9 17:02:11 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/789c71cd62692820df80c24d
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Add ability to send a node message via MQTT (to sbbs/+/node/+/msg topic)

    The node message should be terminated with a newline character.

    e.g.
    $ echo "Hey you" | mosquitto_pub -s -t sbbs/VERT/node/1/msg

    I'm considering the ability to send user message (telegrams) via MQTT too.
  • From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Tue Sep 12 17:43:27 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/207ed413b77f6f8025b130d5
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Always publish log messages to both .../logs and .../logs/<level> topics

    ... regardless of the configured MQTT protocol version (v5 or v3.x).

    Also include an MQTT v5 user-property ("time") with the message's origination time/date stamp in ISO-8601 format in all log messages (to both topics).

    This will at least double the amount of MQTT log traffic to the broker. When MQTT v5 is used, the additional user-properties will increase it even a little more.

    Is this what you were suggesting Ree?
  • From Rob Swindell (on Windows) to Git commit to main/sbbs/master on Tue Sep 12 18:32:39 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/5cb96ad3b35e851222452b86
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Fix log topic publishing when using MQTT v3

    Apparently if you call mosquitto_publish_v5() with a non-NULL properties pointer, it'll only publish via protocol v5 and doesn't work if you're using protocol v3 connection.

    Thanks Ree.
  • From Rob Swindell (on Windows 11) to Git commit to main/sbbs/master on Wed Dec 13 19:11:22 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/6abee6374eb0967feb398643
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Fix crash after failing to connect to MQTT broker

    We need to call mqtt_shutdown() instead of mqtt_close() to have the mosquitto (loop) thread stopped.

    Upon connect failure, call the mqtt_shutdown() *before* calling lprintf->lputs, which would eventually try to MQTT-publish the log message.

    The call to mqtt_connect() can block for a while, so raise the log severity
    of the "connecting to broker" message from DEBUG to INFO. Otherwise, a bad
    MQTT broker address or port would make the servers just appear to hang during initialization, for no reason.
  • From Rob Swindell (on Windows 11) to Git commit to main/sbbs/master on Wed Dec 13 20:02:50 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/1bc971266525652be3def0a6
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Change the MQTT broker-connect ... successful log message to DEBUG-level

    Since we're logging at INFO level when the connect is attempted, we can assume success when we start logging additional init messages.
  • From Rob Swindell (on Windows 11) to Git commit to main/sbbs/master on Sat May 4 16:05:17 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/f8f85f1e4ae337d9fbbc0caa
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Fix CID 493283: Incorrect expression (NO_EFFECT)
    Comparing an array to null is not useful: "client->protocol == NULL",
    since the test will always evaluate as true.

    or will always evaluate as *false* (the array won't ever be NULL). <shrug>
  • From Rob Swindell (on Windows 11) to Git commit to main/sbbs/master on Thu Jul 11 19:17:01 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/6d01d683c9a87a909bfae902
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    Clear (set to 0) each server's "highwater" topic upon startup

    The other server stats (e.g. error_count, served) are zeroed upon startup, so the highwater mark should be zeroed too.
  • From Rob Swindell (on Windows 11)@rob@synchro.net to Git commit to main/sbbs/master on Sun May 3 20:31:55 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/bc1ecf0980178ef81c5111c1
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    sbbs3 mqtt: escape control bytes in login_attempts payload

    The login-failure 'prot' and 'user' fields published to the retained
    topic sbbs/<sysid>/host/<host>/login_attempts/<ip> are attacker-
    controlled strings. The prior sanitize_field() only replaced tab,
    CR, and LF with spaces, leaving NUL, DEL, escape, and high-bit bytes
    to leak into the MQTT payload -- and into the terminal of anyone
    tailing the topic with mosquitto_sub or similar (terminal-escape
    injection risk).

    Replace with c_escape_str(..., ctrl_only=true), which renders all
    control bytes and high-bit bytes as C-style escapes (\t, \r, \xNN,
    \e, etc.). Tab/CR/LF field-separator integrity is preserved as a
    side effect since those are also control bytes.

    Local prot/user buffers grown to 4*field_size+1 to accommodate the
    worst-case \xNN expansion of every source byte.

    Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
  • From Rob Swindell (on Debian Linux)@rob@synchro.net to Git commit to main/sbbs/master on Wed May 6 22:36:57 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/77a712c064189539e761b224
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    mqtt: cast putnmsg to void in mqtt_message_received (CID 469140)

    The MQTT bridge forwards an inbound payload to the node; if delivery
    fails (node not running, etc.) there's nothing useful for the MQTT
    callback to do with the error. Make the discarded return explicit.

    Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
  • From Deuc╨╡@shurd@sasktel.net to Git commit to main/sbbs/master on Thu May 7 02:03:23 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/fb788069b14684762744d5de
    Modified Files:
    src/sbbs3/mqtt.c
    Log Message:
    mqtt.c: fix server state not published correctly on connect

    mqtt_server_state() only updated mqtt->server_state inside the publish
    block, so when mqtt->connected was false (race between synchronous
    TCP connect and async CONNACK callback), the state transition was
    lost. Move the state update before the publish so it's always tracked.

    mqtt_server_startup() hardcoded SERVER_INIT, overwriting the real state
    if the MQTT connect callback fired after the server had already
    transitioned to SERVER_READY. Use mqtt->server_state instead.

    On reconnect (server_version is NULL), re-publish the current state
    so the broker has the correct retained server-level status.

    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>