GUVWAF

> I do not yet understand how traceroute is implemented It will be called upon as a module, and then modifies the payload, before adding it to the Tx queue...

It might just be we’re not agreeing on what the “(local/problem) area” is. In my opinion it doesn’t really matter where the additional rebroadcasts happen, if they are unnecessary then...

> "Users are probably trying to reach only people very close to them, and packets should be discouraged from travelling longer distances." (unless I have badly misunderstood your example scenario...

@erayd Unfortunately this won't work as it will lead to duplicate packets in the apps and on MQTT as I mentioned above. Even if it's still in the Tx queue,...

@h3lix1 Now we're back to the original reason why this PR wasn't merged yet. Either we return `false` in `wasSeenRecently()` such that all logic gets redone, but that has the...

Sorry for keeping you busy all the time ;) This looks quite good, but it’s not only `sendToPhone()` that's problematic. Calling the modules again also triggers things like the TextMessageModule,...

It should be fixed with >=2.7.6 (it needs #7634 also).

This original issue was about rebroadcasts being canceled when the ACK came via UDP, this is fixed with #7589 (and #7634). Instead of not acknowledging when receiving via UDP, we...

Hmm, upon a second look, it looks like #7589 only prevents canceling a rebroadcast (if the packet originated from someone else), but when a packet from yourself gets ACK-ed via...

I believe this is because of this: https://github.com/meshtastic/firmware/blob/e7802d960fac813e58e6b0e8ed085d91801e5dd8/src/sleep.cpp#L171-L172 This will not work because during `delay()`, ArduinoThread will not call the `NotifiedWorkerThread` of RadioLibInterface and thus it won't reach `TRANSMIT_DELAY_COMPLETED`, keeping...