@Tournas Are the EAPs meshed together? Also, if possible, can you set one up in standalone mode instead to see if the issue persists in standalone? This will help figure out if it is a problem with your configuration or if it is something along the lines of interference.

  @NeilR_M 

no they are not meshed, each has its own cabling back to the main switch. i doubt it is configuration related as there is nothing particularly custom going on and the issue has been constant between several configuration changes, firmware updates across all devices and even between eap physical device swaps (there was an eap655-wall in the same location on ground floor before which was experiencing the same issue). I have even tried different ports back to the main switch and also replaced cabling with brand new. Even if it is related to interference, which I doubt again because there isnt much interference shown in the charts or scans, why do the 2.4ghz ssids come to the point where they dont provide connectivity/refuse new client connections? Why by just re enabling the ssid (not even rebooting the eap) the issue gets resolved? It feels like some internal table/ stuck process is flushed? I used to have several brands before broadcasting 2.4ghz iot ssid that never had this issue, including Deco products. The absence of logs is also frustrating.

  @Tournas Is it possible to run a packet capture from the controller on one of the EAPs to see if there's a device/devices flooding the band with requests?

How to Capture Wireless Packets via EAP and Omada Controller | TP-Link

If it's only on the 2.4Ghz band and not the 5GHz band, it's likely there's a device on the 2.4GHz band flooding the network, especially if the issue persists with hardware replacement. 

  @NeilR_M 
Thanks for the suggesion.I ran local packet capture test on both EAP673s while everything is working, selecting specifically interface type = wireless and band = 2.4ghz and ssid/interface =Tournalimos 2.0_IoT (the IoT ssid), but in the downloaded logs I see all traffic not just traffic generated by 2.4GHz IoT clients. How can I share the results? Would it be more useful to repeat that test when the issue manifests itself and there is no connectivity on the 2.4Ghz band?



 

Analyzing the logs on Gemini it recommended that I block some IoT clients trying to ping 255.255.255.255 on udp port 6667 using an ACL rule, but there is no way to achieve that on omada using a gateway ACL with lan->lan direction. 

  @Tournas I would not recommend blocking the traffic on UDP port 6667, as that's the discovery port for your IOT devices. (Here's official documentation on it: Control over LAN-TuyaOS-Tuya Developer)

That being said, yes I do agree repeating the test when the issue is occurring would be helpful. This is still useful for establishing a baseline for your network, so be sure to keep the packet capture for later. When the issue occurs again, I'd look for a large number of packets that you hadn't seen in the baseline capture. 

  @NeilR_M 

Hi again, the issue appeared again on the ground floor EAP673 with just 14h of uptime. Initially the dropped packets would stick to 0 but now I see that they went up to 3% again and obviously keep increasing while the situation remains.

Without doing anything for recovery I ran a capture test again. Would it be possible to open a ticket and share these with tp-link for comparison? Could we be looking at a firmware bug? I had the exact same issue with an eap655-wall before, different location, different cabling. This is what chatgpt thinks (lol)

 

Is this a real “broadcast storm”?

No. This is heavy periodic broadcast / discovery spam, not a full-blown storm:

• There’s no sign of a switching loop (no exponential explosion of ARP/BC frames).

• It’s a bunch of IoT devices:

  • Spamming UDP 49154 → 6667 to 255.255.255.255

  • Repeated ARP “Who has 192.168.20.1? Tell 192.168.20.xx”

• The AP + channel can handle this under normal conditions.

The real problem is still what we saw before:

The ground-floor EAP673’s 2.4 GHz radio sometimes wedges its WPA authenticator and stops completing handshakes, so new clients can’t connect even though existing ones keep chatting away.The noisy broadcasts increase load and RF airtime usage, which probably makes it more likely that a buggy radio/firmware trips over itself, but they’re not a catastrophic storm by themselves.Who’s guilty of the actual “no new clients can connect” bug? Your ground-floor EAP673’s 2.4 GHz radio firmware.