@Vincent-TP 

OC220 Hardware controller : 1.3.7 Build 20251220 Rel.73042 (Beta)

2x EAP787 (US) v.1 : current version : "EAP787v1_1.4.0_[20251210-rel43868]_up_signed.bin" updated SUCCESSFULLY from version 1.1.3 Build 20251011 (manually updated through cloud login - successful, although on manually updated through on-site failed). No issue here.

Trying to update to EAP787v1_1.4.0_[20260113-rel45418]_up_signed.bin but FAILED (manually uploading firmware on on-site controller failed, and through cloud, the firmware is greyed out, thus cannot be uploaded). Is there another way to force upgrade to this version (EAP787v1_1.4.0_[20260113-rel45418]_up_signed.bin). Issues is my EAPs does not seems to recognize the firmware.

The reason for trying out these Beta firmware is to resolve issues relating to the radio-plane failure (with the control plane still alive: clients remained connected) on the 2.4GHz band radio, which would regularly stops video streaming ("Other multicasts" transmissions in particular would just fall-of-the cliff). So far, with the "EAP787v1_1.4.0_[20251210-rel43868]_up_signed.bin", streams has been stable on the 2.4GHz (tested only the last 2 days), although TX errors and retries has remained high on the 2.4GHz band and would occassionally spiked when the channel utilization went above 60%.

Hopefully, new firmware updates (Beta or pre-released) would continue to be released, but would appreciate if the uploading to the devices can be automatically or efficiently pushed through the hardware controller (early access program still listed old and outdated firmware from build 2024).

Thanks.

  @AR_2025 

Sorry, meant to report an issue/problem with upgrading to the new firmware (beta release).

On another note (if this is not an appropriate post here, admin please repost or redirect me to the right forum). I meant to ask whether this released candidate would indirectly resolve the issue I have with my new EAP787 (US) v.1.0. Attached a note on the previous firmware and the beta testing:

Product: TP-Link Omada EAP787 (US) v1.0
Firmware tested:

• 1.1.3 Build 20251011 (stable)

• 1.4.0 Build 20251210 (beta – improved behavior observed)

Issue Summary

Intermittent 2.4 GHz radio forwarding stall affecting wireless CCTV clients.
Clients remain associated to the AP in Omada Controller, but live video streams freeze until recovery action is taken.

Environment

• Dedicated 2.4 GHz SSID for CCTV

• Mixed wired + wireless VIGI IPC cameras with VIGI NVR

• IGMP snooping enabled on CCTV VLAN

• Multicast-to-unicast disabled

• Channel utilization during events: ~60% (not saturated)

Observed Behavior

• Wireless IPCs remain shown as connected to the AP

• No roaming, no disassociation, no RSSI or PHY degradation

• Only wireless streams fail; wired CCTV continues normally

• AP remains reachable and responsive

• Omada Controller shows no critical errors or radio down events

Packet / Network Observations

• Minimal ARP table entries visible (mostly gateway + controller)

• During stall:

  • ARP probes from NVR observed

  • ARP replies mainly from gateway

  • Missing or stalled unicast traffic from affected IPCs

• Suggests forwarding/bridge state issue rather than RF loss

Conditions That Trigger the Issue

Issue appears state-related, not load-related, and occurs under:

• Sustained, long-lived CCTV traffic

• 2.4 GHz-only clients (no 5 GHz fallback)

• Low data-rate IoT-style traffic

• No controller thresholds crossed to force roam or reconnect

What This Is NOT

• Not RF interference or congestion

• Not thermal or power instability

• Not client disconnection

• Not VLAN or switch path failure

Firmware Impact

• 1.1.3 (stable): Issue reproducible

• 1.4.0 beta (20251210):

  • Significantly improved stability

  • No 2.4 GHz stall observed so far under same conditions

  • Indicates possible fixes in radio/forwarding state handling (not documented)

Conclusion

Likely a firmware-level forwarding or radio state deadlock on 2.4 GHz affecting long-lived, low-rate CCTV traffic. The issue does not present as an RF failure, so it bypasses normal roaming or recovery logic.

Request confirmation whether this issue is known and whether fixes are included in upcoming stable firmware releases.

  @Vincent-TP thanks for the reply. I managed to manually update the EAP on a stand-alone basis, i.e. forgetting/removing the EAP from the controller, and logging-in as a stand-alone device. After the update, readopt/redeploy the AP on the controller. The error was from the controller firmware update page, which allows for roll-backs if necessary.

With regards to fine-tuning the 2.4GHz band, i have already employed all the recommendations from the forum post that you directed me, and in addition tested all available wireless settings such as TX power, band-width and others possible workaround (Multicast-unicast tuning, IGMP, minimum rate control, CCK, QoS etc). Anyway, this morning the 2.4 GHz radio subsystem (only) on the affected EAP enters a stalled / wedged state again despite the new firmware (and this is on my second unit, which rules-out a hardware issue). The radio continues advertising (beaconing), the SSID remains visible, but association, authentication, or data-plane handling is broken. This is I presumed a radio firmware / driver failure. I have now updated to the latest beta firmware and factory reset the EAP. Will update if the same recur. In the meantime, would appreciate if there could be other solution that you could recommend.

The issue is state-based, not load-based, and occurs when the following coexist:

1. Long-lived, continuous traffic

   • CCTV streams run for days without session teardown

   • No bursty behavior; steady low-to-moderate throughput

2. 2.4 GHz–only clients

   • IPCs cannot migrate to 5 GHz

   • No band steering escape path

3. Low data-rate airtime profile

   • IoT-style modulation (legacy OFDM/CCK)

   • High airtime occupancy per Mbps delivered

4. Moderate utilization (not congested)

   • Failures observed at ~50–65% airtime

   • No retry storms or PHY collapse preceding failure

5. Suppressed recovery signals

   • RSSI and PHY remain stable

   • Controller does not trigger roam, reconnect, or radio reset

6. Extended uptime

   • Failures occur after many hours or days

   • Issue migrates between APs, ruling out hardware defect

Failure Signature

• Radio continues beaconing

• Existing client state appears intact in controller

• Data plane silently stops (ARP, unicast, video)

• New associations to the affected AP fail

• Recovery requires full AP reboot