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

Packet flooding can cause interface.poll() to require excessive processing time #848

Closed
ryan-summers opened this issue Oct 12, 2023 · 0 comments · Fixed by #954
Closed
Labels

Comments

@ryan-summers
Copy link
Contributor

The logic behind interface.poll() repeatedly processes packet ingress and egress. However, in cases where packets may be arriving faster than they can be read and processed (i.e. heavy multicast/broadcast traffic, slow transfer times with the MAC/PHY), this can cause the interface.poll() function to block for indefinite periods of time.

I specifically encountered this while streaming UDP multicast traffic on a LAN at ~40MBps on a separate device, and observed an unrelated piece of hardware (on the same physical network, both running smoltcp) then encounter a watchdog and reset (the watchdog had a 4s timer, streaming was occurring for ~10 seconds).

I believe this could potentially be used as a fault injector and/or DoS mechanism on firmware projects. Would it make sense to limit the infinite process loop in interface.poll() to some theoreticaly maximum packet count, and then allow the user to call the function again?

@ryan-summers ryan-summers changed the title Packet flooding can cause interface.poll() require excessive processing time Packet flooding can cause interface.poll() to require excessive processing time Oct 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

2 participants