Packet flooding can cause interface.poll()
to require excessive processing time
#848
Labels
interface.poll()
to require excessive processing time
#848
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: