[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Handle a broadcast storm

From: address@hidden
Subject: Re: [lwip-users] Handle a broadcast storm
Date: Fri, 22 Mar 2019 21:05:38 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]