Re: [lwip-users] Handle a broadcast storm

[address@hidden]

Am 22.03.2019 um 16:02 schrieb address@hidden:
> Thank you very much for your analysis, I was not able to do that by myself! I
> confirm that in the embedded device, even if I have set 3 rx buffer, there
> is a while loop going through the rx buffer and it seems they are loaded
> while I'm reading them so I'm reaching up to 400 while cicles in ethernet
> irq.
> I don't think it's possible to block them at HW level acting on MAC filters:
> if it's not possible the workaround you propose can help but doesn't solve
> my issue because a frame process takes about 20us in my HW with 8-9 for pool
> buffer allocation so even if I filter out the pool part and I avoid to call
> LWIP I can still have 11us*400 that is a lot of time.
> Thanks again for your analysis, I will have a look at the STM32, and I will
> post my proposed solution.

If you have performance problems, don't filter in ethernet_input() but
do it in the ethernet ISR as early as you can.

Keeping that aside: what do you want to achieve? You can implement the
best filter you can think of, but still someone could DoS your device by
sending a lot of *valid* packets passing the filter.

I'd probably disable RX for some time (e.g. until X pending RX frames
have been processed) to make it more stable. This can lead to lost RX
packets of course, but then again: if your device seems to slow to
handle traffic at wire speed, there's not much you can do...

But a very early filter that prevents even allocating pbufs for packets
that would be dropped later would be a good idea to not get packet loss
because of broadcast data. You could even limit broadcast RX to X
packets in a row...

Regards,
Simon