RX Router Queue Overflow Drops Oldest Packets

[robekl]

My ai thinks packets could be dropped. Is this worth pursuing?

Core issue

The router RX queue depth is fixed at 4:

• MAX_RX_FROMRADIO = 4 in src/mesh/Router.cpp:25

Overflow behavior in Router::enqueueReceivedMessage() is:

1. Try enqueue with no wait
2. If full, dequeue and discard the oldest packet
3. Retry enqueue until the new packet is accepted

Code:

• src/mesh/Router.cpp:151
• src/mesh/Router.cpp:154
• src/mesh/Router.cpp:156
• src/mesh/Router.cpp:158

So overflow is not backpressure or drop-newest; it is explicit drop-oldest.

---

Why this can drop routing control traffic

All inbound LoRa packets are fed to router in promiscuous mode (before packet-class/port handling):

• src/mesh/RadioLibInterface.cpp:482
• src/mesh/RadioLibInterface.cpp:513
• src/mesh/RadioInterface.cpp:955

Other transports also enqueue into the same queue:

• MQTT: src/mqtt/MQTT.cpp:142, src/mqtt/MQTT.cpp:145
• UDP multicast: src/mesh/udp/UdpMulticastHandler.h:84

There is no type/priority classification at enqueue time, so routing control packets and normal payload packets are treated identically.

Routing logic (sniff/ACK handling) only runs later, after dequeue + decode + module dispatch:

• decode path starts in src/mesh/Router.cpp:708
• module dispatch in src/mesh/Router.cpp:755
• routing sniff in src/modules/RoutingModule.cpp:30, src/modules/RoutingModule.cpp:31

If packet is dropped at enqueue overflow, it never reaches routing logic.

---

Why overflow is plausible (not theoretical)

Per-packet processing on dequeue is non-trivial:

• copy encrypted packet for MQTT (src/mesh/Router.cpp:703)
• decrypt/decode attempts across channels (src/mesh/Router.cpp:468)
• module dispatch (src/mesh/Router.cpp:755)

Ingress can be bursty:

• LoRa frames are always enqueued promiscuously (src/mesh/RadioLibInterface.cpp:482)
• MQTT/UDP can inject additional packets into same queue (src/mqtt/MQTT.cpp:142, src/mesh/udp/UdpMulticastHandler.h:84)

With queue depth 4, short bursts can evict early packets.

---

How this manifests in behavior

1) Missed ACK/NAK processing -> unnecessary retransmissions -> MAX_RETRANSMIT failures

If ACK/NAK packet is dropped before routing module sees it:

• retransmission stop path is never triggered (src/mesh/ReliableRouter.cpp:147 to src/mesh/ReliableRouter.cpp:156)
• retransmission loop keeps sending (src/mesh/NextHopRouter.cpp:290)
• eventually emits MAX_RETRANSMIT NAK (src/mesh/NextHopRouter.cpp:282 to src/mesh/NextHopRouter.cpp:285)

User-facing symptom: “message failed / retries despite good RF conditions”.

2) Lost ACK/reply observations -> degraded next-hop learning and extra flooding

Next-hop learning is updated from ACK/reply observations in:

• src/mesh/NextHopRouter.cpp:90 to src/mesh/NextHopRouter.cpp:109

If those packets are dropped at RX queue overflow:

• next-hop table not updated
• more fallback to flooding behavior later (src/mesh/NextHopRouter.cpp:295 to src/mesh/NextHopRouter.cpp:303)

Symptom: elevated airtime and route instability even with stable topology.

3) Missed inbound want_ack handling at destination

If inbound want_ack packet to us is dropped:

• no ACK generated from ReliableRouter::sniffReceived() path
• sender continues retransmission until timeout/failure

Relevant ACK generation path:

• src/mesh/ReliableRouter.cpp:96 to src/mesh/ReliableRouter.cpp:130

---

Logging signatures to watch

Overflow event:

• "fromRadioQ full, drop oldest!" from src/mesh/Router.cpp:158

Likely downstream effects:

• "Sending retransmission ..." src/mesh/NextHopRouter.cpp:290
• "Reliable send failed, returning a nak ..." src/mesh/NextHopRouter.cpp:282
• "Resetting next hop ..." src/mesh/NextHopRouter.cpp:300

---

Observability gap

I don’t see a dedicated metric for router RX overflow drops.
Current local stats include duplicates/canceled-relays, but not router RX queue overflow:

• num_rx_dupe / num_tx_relay_canceled exported in src/modules/Telemetry/DeviceTelemetry.cpp:140, src/modules/Telemetry/DeviceTelemetry.cpp:141

---

Additional note

Protocol docs/comments emphasize TX prioritization for ACK/routing (src/mesh/generated/meshtastic/mesh.pb.h:518), but this RX queue has no analogous prioritization and can discard routing control packets under burst load.

---

Discussion questions

1. Is dropping oldest intentional for this queue, or should this be revisited for reliability-sensitive traffic?
2. Should ACK/routing frames get protected treatment on RX (priority lane or protected subqueue)?
3. Should we add an explicit router_rx_overflow_drops counter to telemetry/logging?