Node never gets a /node/[id] page despite confirmed MQTT delivery and correct config

[rci27]

My node's MQTT uplink is confirmed reaching the broker live and correctly, yet it never gets a /node/[id] page — even after a full identity reset with clean data from birth.
Setup: Portduino (meshtasticd) node on a Raspberry Pi, msh/US/PA root topic, public mqtt.meshtastic.org broker.

What's confirmed working:

• MQTT config matches another Portduino node I run that does have a working Malla page (same broker, root topic, uplink settings)
• Directly verified via mosquitto_sub that packets under my node's own topic (msh/US/PA/2/e/LongFast/!) reach the broker in real time
• Periodic NodeInfo broadcasts firing correctly on schedule, with the correct owner name
• Valid Ed25519 public key
• Correct fixed-position coordinates (confirmed via device's own --info output)
• Node correctly resolves by name when referenced in other nodes' packet histories (e.g. shows as sender/recipient on a nearby node's page) — so data is clearly being ingested at the packet level
• nodedbCount on the device itself is 139 and climbing, confirming it's actively hearing/participating in the mesh

What doesn't work:

• /node/[my-decimal-id] returns "Node not found," indefinitely

To rule out anything stale/cached, I did a full reset: wiped the device's local state to generate a completely fresh node identity and keypair, reconfigured everything from scratch with correct position data from the start (rather than potentially-empty fields), confirmed the new identity also reaches the broker correctly via mosquitto_sub. Same result — still "Node not found" on the fresh identity.

• Old ID: !1885a097 (decimal 411410583)
• New ID (current): !eb95d473 (decimal 3952465011)

Question: is there a specific requirement for node_info record creation that I might be missing — a minimum packet count, a specific packet type/order, something particular to Portduino nodes? I noticed from the docs that node_info is a separate table from packet_history with its own cleanup logic — is there a code path where a node can be logged in packet_history indefinitely without ever populating node_info?

my node is on the newer firmware (2.7.26) vs. my working comparison node (2.7.15)

Happy to provide raw packet IDs, timestamps, or any other data that would help debug this.

[motababravo]

Hi rci27,

Your node ID has changed:

• Old ID: !1885a097 (decimal 411410583)
• Current ID: !eb95d473 (decimal 3952465011)

From Malla's perspective, these are two completely different nodes. The encryption keys don't matter in this case—the node ID is what identifies the device.

Malla needs to receive a NodeInfo packet from the new node before it can recognize it. The easiest way to do this is to have another node on the same channel send a Request NodeInfo to your device.

Also, make sure you're running the latest version of Malla.

[rci27]

The reason for the node changes was that it was my first attempt to solve the issue. I ran a few exchanges to clear the node, and request nodeinfo from my other node with mosquitto_sub watching my node's topic live throughout. Caught it in real time — my node's log showed Send owner !eb95d473/BACH/BACH and Asked module 'nodeinfo' to send a response, and in the same second, mosquitto_sub printed a genuine publish to msh/US/PA/2/e/LongFast/!eb95d473 (134 bytes). Directly observed.

Checked /node/3952465011 several minutes after — still "Node not found."

This is about as strong a proof as I can produce that my node's NodeInfo response genuinely reaches the broker correctly. I think I've exhausted what's testable from my end — happy to provide the raw MQTT payload bytes or anything else that'd help you trace this through the capture pipeline whenever you get a chance to look.

Still trying to figure out what version of Malla is being run for phillymesh

[rci27]

Confirmed with a second independent node. Repeated this test using a completely different device (SALIERI, via MQTT Client Proxy) instead of MOZART. Same result: SALIERI's NodeInfo request, traceroute, and position exchange to my node all appear correctly in Malla's packet list (From: SLRI, To: d473). But my node's responses — independently confirmed via live mosquitto_sub to reach the broker on the same topic — never appear anywhere in the packet log as From: my node.
So this is reproducible from at least two different requesting nodes, not something specific to one device's behavior. The pattern is consistently direction-based: traffic to my node captures fine; traffic from my node doesn't, regardless of packet type (NodeInfo, position, or PKI-encrypted).

[zenitraM]

Can you try to run a local instance of Malla connected to that MQTT and see if there's any error or message showing on the malla-capture log?
Sounds like the packet failed to decode or be decrypted somehow when being recorded from MQTT, but that would only show up on the malla-capture logs, not on the web interface.

[rci27]

Working on it now.

[rci27]

I deployed a local Malla instance using the same public broker, then let it sit for 45 minutes with zero restarts or config changes on my node — just letting it publish normally. Zero packets from my node reached the subscriber in that window, despite my node's own logs confirming it published normally the whole time.

I then did one single restart of my node, which forces an immediate NodeInfo broadcast. That one broadcast was received and correctly decoded — Malla built a complete, accurate node record from it (name, hardware model, role, all correct).

Malla's decode and node-building logic is not the problem — confirmed working correctly when a packet arrives. The actual issue may be that packets from my node don't reliably reach the subscriber at all, and that failure happens even under completely undisturbed conditions, not just around reconnects. Something between "my node publishes" and "a subscriber receives" is dropping packets intermittently, for reasons I can't diagnose from my side — I don't have visibility into the broker's own delivery/session logs.

Possible cause, unconfirmed: the one thing that correlates is a fresh reconnect on my node's side sometimes succeeding where undisturbed steady-state publishing fails — which is a strange enough pattern that it may point to something broker-side rather than anything wrong with my node's config, which I've verified is correct

.