lwipthread stops MAC input processing when PBUF allocation fails Topic is solved

[iggarpe]

I've found this bug in lwipthread.c when working with other drivers and I'm pretty sure it's present too in ChibiOS examples that use MAC.

The problem is as follows: lwipthread listens on the receive events broadcasted by the MAC driver. When a receive event is detected lwipthread proceeds to read packets from the MAC input queue until it's empty. The latter is very important because if, for example, three packets were received and the receive event broadcasted three times before lwipthread was woken up, processing only one packet would leave two in the MAC input queue unprocessed.

The problem is that the packet processing loop will stop as soon as low_level_input() returns NULL, which happens if:

1- The MAC input queue is empty [CORRECT]
2- A PBUF could not be allocated [WRONG]

Thus if a PBUF could not be allocated the packet processing loop stops leaving packets in the MAC input queue. Best case the input queue is not full and the next packet reception will process also those packets, worst case the input queue is full and no more reception events are signaled. MAC reception stops forever.

The attached patch modifies low_level_input() to return a boolean representing whether the MAC input queue is empty, and that is the only condition used in the thread to stop processing input packets. In addition, a pbuf is returned that MAY BE NULL if pbuf allocation failed, and the packet processing loop just skips that packet, but keeps processing packets until the input queue is empty.

[Giovanni]

bump

[steved]

Pretty confident this was incorporated along with the other updates a while back

[Giovanni]

Thanks, closing then.

Giovanni