|Subject:||Re: [lwip-users] Handle a broadcast storm|
|Date:||Fri, 22 Mar 2019 09:57:58 -0400|
|User-agent:||Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3|
On 3/22/2019 3:17 AM, address@hidden wrote:
Dear all, thanks for all your replies and sorry if I didn't add enough information. I'm not able to reply to your questions now, I have to check with ITD to try to discover that device. As you can see the problem I'm experiencing in my embedded board is that the packets it is sending are very near each other and I was able to count up to 400 of them. Again I'm not an expert of ethernet but is there a way to handle this type of conditions? Do you have any suggestion? The best would be to filter at HW level but I don't know if it's possible or I could do something disabling temporarly Ethernet Irq but I would like to know if there is a common way to handle these conditions to avoid just to try. I attached a pcap file. thanks again Michele broadcast_storm.pcapng <http://lwip.100.n7.nabble.com/file/t1187/broadcast_storm.pcapng>
Hello again Michelle,
The PCAP file really helps shed some light on your situation.
Based on the OUI, the device that is sending out the bogus TCP broadcast is made by Microhard S.R.L - that may help you identify that device. (they seem to make various vending machines if that helps?)
It turns out that the Digi Board device that is responding with the (even more bogus) TCP broadcasts is actually not one, but 5 devices from Digi, each one sending out a single response.
While your IT department should be concerned with removing bad devices from your network, you still want your device to be able to tolerate bad packets and not hang up when they happen.
I'm not sure how you're seeing 400 packets in a short period of time? Or is that count after a few minutes of running?
Either way, you could attempt to filter out at least some of the bad packets as early as possible. If you're using ethernet_input(), you could filter the bogus Digi packets with the following code (or something similar):
case PP_HTONS(ETHTYPE_IP):This code is near line 185 in ethernet.c from LwIP 2.1.2.
It would be better if you could do a similar filter in your ethernet driver before it even gets into LwIP.
|[Prev in Thread]||Current Thread||[Next in Thread]|