You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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
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 theinterface.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?The text was updated successfully, but these errors were encountered: