Closed madsci77 closed 11 months ago
PeterBorisenko
commented
1 year ago Hello In case of a broken link while packet is receiving we will be out of fragments very soon and so we will have to return to the outer loop and catch that semaphore timeout again. After we discover that link is broken it will take 500ms more to recover.
madsci77
commented
1 year ago The issue is detecting when the link comes back up. If there's traffic being received immediately, the link check is never done and the netif is never put 'up' again so nothing can be sent. In my testing this occurred because I had an incoming RTP stream and the continuous UDP packets would keep it from detecting that the link was up. If it's accepting broadcasts as well, that can be enough to keep it from doing the link check on a busy network.
PeterBorisenko
commented
12 months ago I see. So receiving restarted before samaphore is timed out and we do not notify lwip that link is up again.
PeterBorisenko
commented
11 months ago
In spi_if_input(), the link state is only checked if xSemaphoreTake() times out (set to 500 ticks). This means that if there's at least one packet received on the network during that 500 tick interval, the link change is not detected. You can plug the cable back in and lwIP never knows that the interface is available again because the driver never polls.
If the netif state is down on receipt of the semaphore, the driver needs to poll the PHYCFGR for the hardware link state and report it to lwIP if it's back up.
It'd also be a good idea to use the FreeRTOS macro to take the timeout in milliseconds rather than ticks, since there's no telling what the tick rate is going to be.