lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Handle a broadcast storm


From: Patrick Klos
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):
      if (!(netif->flags & NETIF_FLAG_ETHARP)) {
        goto free_and_return;
      }
      /* skip Ethernet header (min. size checked above) */
      if (pbuf_remove_header(p, next_hdr_offset)) {
        LWIP_DEBUGF(ETHARP_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_LEVEL_WARNING,
                    ("ethernet_input: IPv4 packet dropped, too short (%"U16_F"/%"U16_F")\n",
                     p->tot_len, next_hdr_offset));
        LWIP_DEBUGF(ETHARP_DEBUG | LWIP_DBG_TRACE, ("Can't move over header in packet"));
        goto free_and_return;
      } else {
================= Insert begin ===============
        /* filter out packets with a broadcast source address */
        if ((p->payload[0] == 0x45) &&
            (p->payload[12] == 0xff) &&
            (p->payload[13] == 0xff) &&
            (p->payload[14] == 0xff) &&
            (p->payload[15] == 0xff))
            goto free_and_return;
================= Insert end ===============
        /* pass to IP layer */
        ip4_input(p, netif);
      }
      break;

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.

Good luck!

Patrick


reply via email to

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