Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bugfix for low-priority packet replacement when TX queue is full #5827

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

erayd
Copy link
Contributor

@erayd erayd commented Jan 12, 2025

Add the intended replacement packet (not the packet that was just removed, which was clearly a typo) to the TX queue after dropping a lower-priority packet. Fixes a use-after-free.

Also corrects the function comment, and adds some debug logging when packets are dropped due to a full TX queue.

Might resolve #5826; testing on that by @Talie5in is pending.

@erayd erayd marked this pull request as draft January 12, 2025 04:41
@erayd
Copy link
Contributor Author

erayd commented Jan 12, 2025

Somehow replaceLowerPriorityPacket is getting called twice for the same packets. I do not yet know why. That should never happen...

Screenshot 2025-01-12 at 17 46 04

@@ -139,8 +147,11 @@ bool MeshPacketQueue::replaceLowerPriorityPacket(meshtastic_MeshPacket *p)
for (; refPacket->tx_after && it != queue.begin(); refPacket = *--it)
;
if (!refPacket->tx_after && refPacket->priority < p->priority) {
LOG_WARN("Dropping non-late packet 0x%08x to make room in the TX queue for higher-priority packet 0x%08x",
refPacket->id, p->id);
packetPool.release(refPacket);
Copy link
Contributor

@esev esev Jan 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no call to erase the refPacket from the queue. The queue size doesn't decrease. If the queue was full, this will loop back in to replace the lower priority packet again.

Copy link
Contributor Author

@erayd erayd Jan 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. That explains the loop we were seeing earlier 🙂.

I should have spotted that the first time around. Apologies for missing it!

Copy link
Contributor

@esev esev Jan 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries! It took me a few times to spot it as well. I kept assuming packetPool.release was taking care of removing it.

@@ -124,9 +131,10 @@ bool MeshPacketQueue::replaceLowerPriorityPacket(meshtastic_MeshPacket *p)
// Check if the packet at the back has a lower priority than the new packet
auto &backPacket = queue.back();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest removing the reference here. Maybe auto *backPacket to make it clearer what the type is.
Calling pop_back while holding a reference might not always be safe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: ROUTER_LATE on LongFast - Packets sometimes dont TX
3 participants