-
Notifications
You must be signed in to change notification settings - Fork 443
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
ARP requests not coming through UDP "flood" #319
Comments
Wait. Which buffers get full? The ARP request is not queued anywhere; it is generated on the fly instead of the outgoing packet (the UDP packet in this case) when there is no cache entry. Do you have a log at TRACE verbosity? |
Oh, that's a good point! I'll see if I can extract a trace log, but probably after Christmas. Thanks for the heads up, I hadn't looked deep enough in the code. |
Ok, I have some more details now. First, I reduced the ENTRY_LIFETIME in the neighbor cache to 5s, to speed up reproduction. I disabled the trace messages for UDP "buffer to send ... octets" and "sending ... octets", to be able to keep the data rate at the full 100 MBit/s. When switching the log level to trace, the problem went away - the log looks like this
with the last 3 lines repeating in 5s intervals. After some trial and error, I removed the I then replaced the debug call by a simple (not-optimized-out) delay loop, and by tuning the length of the loop I could make the problem appear and disappear. That leads me to believe that the problem must be on the STM32 side, and there's some race condition that prevents sending that ARP packet or swallows it. |
Sounds about right. Closing as not an issue in smoltcp. |
Which STM32 driver are you using? |
https://github.com/stm32-rs/stm32-eth - is there another one I could try? |
@birkenfeld: There is a basic version for STM32H7… at https://github.com/quartiq/stabilizer/blob/master/src/eth.rs, which might be similar. We've had some fun with memory coherency, but off the top of my head, that shouldn't actually be a problem for the Cortex-M4 core in the STM32F4 series. |
Reopening since this was narrowed down to an issue in the ARP code in stm32-rs/stm32-eth#10. |
I think I found another problem that might be the cause of the missing ARP. During socket egress, there is a call to Lines 1593 to 1623 in cc85616
On the first call to poll just after the address expired, the call in Lines 175 to 186 in cc85616
This will cause Lines 630 to 648 in cc85616
which will just hit a The underlying problem is that we set the @whitequark is my understanding of this correct ? If so, do you have a preferred way to address this ? |
Thanks everyone for figuring this out! |
I'm using smoltcp as the network stack on a STM32 embedded controller via https://github.com/stm32-rs/stm32-eth (cc @astro )
I've written a small test firmware that sends out UDP packets as fast as possible, saturating the 100 MBit link, and the device stops sending after 60 seconds, which is the timeout for the receiver's IP address in the ARP neighbor cache.
It looks like when the buffers are full (they are pretty small of course), smoltcp can't find anywhere to queue the ARP request and a kind of a deadlock is the result: no packets can go out anymore. Once I send a packet back to the device, this fills the cache and resolves the deadlock until the timeout hits again.
Do you think this is an issue with smoltcp, with the stm32-eth driver or is it to be expected and won't fix?
The text was updated successfully, but these errors were encountered: