[MQTT Broker] Repeatedly changing node ID from TWMQTT causing node list pollution #1

New Issue

2026-10-05T06:09:46+02:00

adam commented

2026-10-05 06:09:46 +02:00

Summary

A software MQTT client named TWMQTT (short: TWM) is repeatedly injecting
packets into the official Meshtastic MQTT broker with a new node ID on every
reconnect, causing severe node list pollution across the MeshTW channel.

We have made multiple public announcements in our local community over several
days, but the operator has not responded.

Evidence

Screenshot attached showing 17+ distinct TWMQTT node IDs accumulated over
just 3 days (2026-04-08 to 2026-04-10).

https://meshmap.pro/nodes?search=TWMQTT

Packet Characteristics

Long Name: TWMQTT
Short Name: TWM
hwModel: PRIVATE_HW
macaddr: AAAAAAAA (fake/placeholder)
Transport Mechanism: MQTT (not RF)
Channel: MeshTW (channel 1)
Portnum: NODEINFO_APP

Critical Pattern: Non-Random Node ID Prefix

All observed node IDs share the same prefix: !abcd****
(e.g., !abcd6ab3, !abcd2b5c, !abcdea04, !abcdc2f8, !abcd5898 ...)

Only the last 4 hex digits change on each reconnect. This fixed prefix (abcd)
may correspond to a specific MAC OUI, software seed, or configuration value —
and could be used by broker administrators to identify or filter the client.

Scale & Frequency

17+ unique node IDs generated in 3 days
11 new IDs on 2026-04-10 alone
Approximately 8 restarts in a 4-hour window (17:17–21:15 on Apr 10)
High packet activity observed: up to 76 packets/24h per node ID
The client is not only broadcasting NODEINFO — it is also injecting
substantial amounts of other traffic

Impact

Every regional node accumulates dozens of ghost TWMQTT entries
High-frequency reconnects cause repeated NODEINFO floods
Significant unnecessary traffic load on the broker
Community cannot clean up node lists as new IDs keep appearing

Request

Could broker administrators use the !abcd node ID prefix pattern and/or
MQTT connection logs (client ID / source IP) to identify and contact the
operator?
If the operator remains unresponsive, could their client connection be
suspended?
As a long-term mitigation, would it be feasible to implement broker-side
rate limiting for NODEINFO broadcasts per MQTT client connection, or flag
clients that generate excessive unique node IDs?

Thank you for your help.

## Summary A software MQTT client named **TWMQTT** (short: TWM) is repeatedly injecting packets into the official Meshtastic MQTT broker with a **new node ID on every reconnect**, causing severe node list pollution across the MeshTW channel. We have made multiple public announcements in our local community over several days, but the operator has not responded. ## Evidence Screenshot attached showing **17+ distinct TWMQTT node IDs** accumulated over just 3 days (2026-04-08 to 2026-04-10). <img width="1861" height="988" alt="Image" src="https://github.com/user-attachments/assets/f15c339e-74b8-40da-81e1-1c46a74c8309" /> https://meshmap.pro/nodes?search=TWMQTT ## Packet Characteristics - **Long Name:** TWMQTT - **Short Name:** TWM - **hwModel:** PRIVATE_HW - **macaddr:** AAAAAAAA (fake/placeholder) - **Transport Mechanism:** MQTT (not RF) - **Channel:** MeshTW (channel 1) - **Portnum:** NODEINFO_APP ## Critical Pattern: Non-Random Node ID Prefix All observed node IDs share the same prefix: **`!abcd****`** (e.g., !abcd6ab3, !abcd2b5c, !abcdea04, !abcdc2f8, !abcd5898 ...) Only the last 4 hex digits change on each reconnect. This fixed prefix (`abcd`) may correspond to a specific MAC OUI, software seed, or configuration value — and could be used by broker administrators to identify or filter the client. ## Scale & Frequency - **17+ unique node IDs** generated in 3 days - **11 new IDs on 2026-04-10 alone** - Approximately **8 restarts in a 4-hour window** (17:17–21:15 on Apr 10) - High packet activity observed: up to **76 packets/24h per node ID** - The client is not only broadcasting NODEINFO — it is also injecting substantial amounts of other traffic ## Impact - Every regional node accumulates dozens of ghost TWMQTT entries - High-frequency reconnects cause repeated NODEINFO floods - Significant unnecessary traffic load on the broker - Community cannot clean up node lists as new IDs keep appearing ## Request 1. Could broker administrators use the `!abcd` node ID prefix pattern and/or MQTT connection logs (client ID / source IP) to identify and contact the operator? 2. If the operator remains unresponsive, could their client connection be suspended? 3. As a long-term mitigation, would it be feasible to implement broker-side rate limiting for NODEINFO broadcasts per MQTT client connection, or flag clients that generate excessive unique node IDs? Thank you for your help.

adam commented

2026-10-05 06:09:47 +02:00

謝謝您的報告，我們看看。
Thanks for the report, we're taking a look.

謝謝您的報告，我們看看。 Thanks for the report, we're taking a look.

adam commented

2026-10-05 06:09:47 +02:00

Maybe this script

https://github.com/pdxlocations/Meshtastic-Python-Examples/blob/3c56832f3668f8a68cd99139edfe2bdf4c222cdb/MQTT/send-mqtt-packets.py#L32

Maybe this script https://github.com/pdxlocations/Meshtastic-Python-Examples/blob/3c56832f3668f8a68cd99139edfe2bdf4c222cdb/MQTT/send-mqtt-packets.py#L32

adam commented

2026-10-05 06:09:48 +02:00

We've blocked a few interesting things. Still WIP.

We've blocked a few interesting things. Still WIP.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/mqtt#1