• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 158 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1831: High IRQ on ICMP flooding

mans.andersson
Intellectual 540 points
Part Number: WL1831

Tool/software:

We've got reports from customers running one of our devices with the WL1831 chipset that the CPU was highly affected by the wifi network causing a Denial of Service on the device. Upon closer inspection it was seen that the devices were getting flooded by ICMP broadcast packets which caused the IRQ line to go high continuously and the kernel having to manage all the traffic.

We have the same device in production running also a Broadcom chipset which does not behave the same way. The only difference here is the chipset, the wifi firmware and the driver. All the other parts of the Linux system is identical.

Therefore, we are investigating if there is a configuration option on the driver level which we could trigger to have the wifi firmware filter out these messages better?

We are running with the driver in mainline linux kernel 6.1.126 together with wl18xx-fw firmware 8.9.1.0.2.

  • 0
    TI__Mastermind 30830 points

    Hi Mans,

    I'm not aware of a feature on the WL18xx that would drop particular frames. Are you looking to drop all IPV6 frames or just one from misbehaving IPv6 address? Do you understand the reason of why this misbehaving device is sending ICMP and flooding the network?

    How does the broadcom device handle this situation? Are you sure the CPU doesn't receive the packet at all? The architecture of the WL18xx devices follow transceiver methodology; meaning that the device simply moves packets between the Access Point (or connected clients if using AP mode) and the attached CPU. 

  • 0 in reply to Sabeeh Khan1
    Intellectual 540 points

    Hi

    We are still investigating on our end if there's anything we can do so please bear in mind that some of my answer here could be incorrect and only based on current assumptions on our end.

    1) We are not looking at dropping all IPv6 frames. I guess basically what we are hoping for was some DoS protection which would identify easily identifiable malicious patterns and block those from even hitting the CPU. For example a smurf attack, or multicast traffic we aren't actually subscribing to.

    2) We don't understand the reason behind the misbehaving device. We only saw this during a short visit at one of our customer's facilities. It was claimed to be a brand new Windows computer recently connected to the network. Unfortunately we did not have the possibility to investigate if the device had any malware on it.

    3) We are not sure whether the Broadcom device forwards the traffic to the CPU or not yet. We have however seen one interesting difference in the driver implementation. The TI driver uses threaded irq while Broadcom does not. At the moment we are therefore considering if the increased CPU load could be blamed on the extra context switches needed for the TI driver to drop/ignore the traffic while Broadcom can do that immediately at the interrupt time.