Hardware:

• EasyMesh Master: TP-Link Archer AX53 v2 (192.168.1.10)

• EasyMesh Node 1: TP-Link Archer AX23 v1.2 (192.168.1.11) - wired backhaul, no issues

• EasyMesh Node 2: TP-Link Archer C6 v4 (192.168.1.12, MAC: 5C:62:8B:95:27:EB) - wired backhaul, ROOT CAUSE

• Upstream ISP router: Technicolor FGA2235 (192.168.1.1)

• Switch: unmanaged 8-port PoE gigabit switch

• Subnet: 192.168.1.0/24, DHCP served by AX53

Bug description:

Whenever the Archer C6 v4 is connected to the network as an EasyMesh node (wired backhaul), it generates a continuous, high-rate ARP broadcast flood that brings down the entire network.

The C6 repeatedly broadcasts the following ARP request at thousands of packets per second, indefinitely:

"ARP Who has 192.168.1.1? Tell 192.168.1.12"

This is the C6 attempting to resolve the MAC address of the upstream ISP router (192.168.1.1). The C6 never caches the response, never backs off, and never stops. It floods the broadcast domain continuously with no rate limiting whatsoever.

Effect on network:

• Complete degradation of all wired and wireless clients

• LAN-to-LAN communication severely impaired (wired devices cannot reach each other)

• DHCP failures: clients repeatedly re-send DHCP Discover/Request with the same Transaction ID, receiving no response

• Internet access unavailable

• Periodic ping oscillation (hundreds of ms to full timeout)

Verified with Wireshark: flood captured on a wired PC connected directly to the switch. Source MAC confirmed as C6 v4 (5C:62:8B:95:27:EB). Packet rate: hundreds to thousands per second continuously.

Isolation tests, definitive proof:

The following tests were performed to isolate the root cause:

Test 1: AX53 alone (C6 disconnected): C6 v4 physically disconnected from the network. AX53 v2 was then stress-tested in three ways:

• Software reboot via admin interface

• Power cycle (unplugged and replugged)

• LAN cable disconnected and reconnected while running

Result: [YES] Network remained fully stable throughout all three tests. Zero broadcast storm, zero degradation. All wired and wireless clients (served by AX53 + AX23) continued operating without interruption.

Test 2:C6 reconnected: C6 v4 reconnected to the switch.

Result: [NO] Broadcast storm returned immediately upon reconnection. No reboot of any device required to reproduce.

Test 3: AX23 v1.2 (same role, same wired backhaul configuration): AX23 operating as EasyMesh node with wired backhaul throughout all tests.

Result: [YES] No issues at any point. Identical topology to C6, no ARP flooding observed.

Conclusion: The AX53 v2, the AX23 v1.2, and the network topology are definitively ruled out as root cause. The bug is isolated to the C6 v4 firmware.

Root cause:

The C6 v4 firmware does not implement ARP request rate limiting or exponential backoff. When operating as an EasyMesh wired backhaul node, the C6 continuously attempts to resolve the gateway MAC address (192.168.1.1) without ever successfully caching the result. Instead of backing off after failed attempts, it retransmits at maximum rate, generating a broadcast storm that overwhelms the entire L2 network segment.

The AX23 v1.2 in identical configuration does not exhibit this behavior, suggesting this is a C6 v4 firmware-specific defect.

Expected behavior: ARP requests should be sent at a low, standard rate with exponential backoff on failure. A cached ARP entry should prevent continuous re-querying.

Actual behavior: Thousands of identical ARP requests per second, continuously, with no backoff and no caching. Causing a broadcast storm that makes the network unusable.

Workaround: Disconnecting the C6 v4 from the network resolves the issue immediately. A managed switch with Storm Control can mitigate the impact but does not fix the root cause.

Firmware versions:

• Archer AX53 v2: 1.0.5 Build 20251225 rel.81769(4555)

• Archer AX23 v1.2: 1.1.3 Build 20250905 Rel. 39233

• Archer C6 v4: 1.15.0 Build 250729 Rel.63726n(4555)

Request: Please investigate the ARP handling in the C6 v4 EasyMesh node firmware and issue a fix that implements proper ARP rate limiting and response caching.