Dear Tapo Support Team / Engineering Team,

I am reaching out regarding a persistent connectivity issue with the Tapo L520 smart bulb when used with high-end routers (specifically the ASUS GT-AX6000).

After analyzing the router syslogs, I have identified a significant flaw in how the bulb handles Wi-Fi reconnection and security handshakes.

Technical Observations from Syslogs:

1. 4-Way Handshake Timeouts: The bulb frequently triggers a 4-way handshake timeout (f) even with a strong RSSI of -63 dBm. This indicates the bulb's firmware is failing to respond within the timing window required by modern Wi-Fi 6 routers, even when set to WPA2-Personal.

2. Exponential Backoff / Inactivity: Following a failed handshake or a router service restart, the bulb enters a state of "inactivity" (reason: Disassociated due to inactivity (4)).

3. Passive Recovery Logic: Once the bulb fails a few connection attempts, it seemingly stops sending Probe Requests or attempting to associate for an extended period. It requires a physical power cycle (manual reset) to initiate discovery again.

Relevant Log Snippet:

wlceventd: wlceventd_proc_event(685): wl0.2: Auth 74:FE:CE:43:3F:DF, status: Successful (0), rssi:0
wlceventd: wlceventd_proc_event(722): wl0.2: Assoc 74:FE:CE:43:3F:DF, status: Successful (0), rssi:-63
wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind 74:FE:CE:43:3F:DF, status: 0, reason: 4-way handshake timeout (f), rssi:-63
wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind 74:FE:CE:43:3F:DF, status: 0, reason: Disassociated due to inactivity (4), rssi:-63

Proposed Firmware Improvements:

• Aggressive Reconnection: Please optimize the exponential backoff timer. The bulb should attempt to reconnect more frequently after a failed handshake rather than going "silent."

• Handshake Optimization: Increase the processing priority of the WPA2 handshake within the bulb's MCU to avoid timeouts on low-latency, high-performance network environments.

• Network Recovery Mode: Implement a "Fast Recovery" mode where the bulb actively scans for the SSID more aggressively if it was previously connected but lost the session.

I hope this data helps your engineering team improve the stability of the L520 series. I am available for further testing if a beta firmware is available.

Best regards,
Frankie