A typical broadcast storm generated from a specific device will have the following characteristics:

• A significant number of broadcasts per second (thousands and more)
• In most cases, the broadcasts will be from a single source; but in the case of attacks, they can be from multiple sources
• Usually in constant packet/second rate, that is, with intervals between frames that are nearly equal

Let us see how we can find a broadcast storm according to the parameters mentioned in the preceding list in the next three screenshots.

In the following screenshot, we see a large number of broadcast packets sent from a source MAC (HP network adapter) to ff:ff:ff:ff:ff:ff:

As seen in the preceding screenshot, the time column is configured in seconds (which means the delta between the timestamps of two successive packets will be reported in seconds). You can configure it by navigating to View | Time Display Format.

The rate of packets can be viewed by navigating to Statistics | IO Graph. The following screenshot shows the rate of the broadcast packets is 5,000 packets/second:

By navigating to Statistics | Conversations option, we can see conversations between the devices from the perspective of Ethernet, IPv4, TCP/UDP. In the top portion of the following screenshot, we can see an enormous number of broadcasts between two MAC addresses, while the bottom portion of the screenshot reports the same conversions but from the IPv4 addresses' perspective. In summary, this has 87,142 broadcast packets captured in the time duration of 18 seconds.

In the preceding case, the problem was due to a service called SMB mailslot protocol. Simple trial and error to find out what this service is and disabling it on the station solved the broadcast storm problem.

Also, I would recommend that you run Wireshark again to confirm that no broadcast flooding is seen.