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 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?