[BUG REPORT] RBRE960 Stops Responding to ARP Requests from WiFi Clients

**Device:** Netgear Orbi RBRE960

**Firmware:** V7.2.8.2

**Mode:** Router Mode (no satellites)

---

**Summary**

The RBRE960 intermittently stops responding to ARP requests from associated WiFi clients. Affected clients retain a valid DHCP lease and remain 802.11 associated, but lose all network connectivity because the router silently stops answering ARP broadcasts. The issue affects multiple device types and operating systems simultaneously and has been reproducible for over a year.

---

**Affected Devices**

- Windows 11 laptop (Intel AX211 WiFi 6E)

- Android Samsung Galaxy phones

- Linux desktop

- Most severely impacts WiFi 6E devices, but not exclusively

- Wired devices are never affected

---

**Symptoms**

- Device shows "Secured, No Internet" on WiFi

- Device has a valid 192.168.x.x DHCP address

- Device cannot ping the gateway

- ARP cache on affected device is completely empty for all unicast entries including the gateway

- Disconnecting and reconnecting WiFi immediately resolves the issue

- Multiple devices can be affected simultaneously

---

**Root Cause Identified via Packet Capture**

I captured traffic using tshark during a failure event. I am not comfortable sharing raw pcap files publicly. Below is sanitized tshark output limited to ARP traffic only, with MAC addresses anonymized.

**Capture 1 — During failure, before any fix applied:**

```

1 0.000000000 [client-wifi-adapter] → Broadcast ARP Who has 192.168.1.1? Tell 192.168.1.32

[repeats 24 times over 23+ seconds]

[zero ARP replies received from router at any point]

```

**The Orbi sends zero ARP replies across the entire 23+ second capture.**

**Capture 2 — During static ARP entry injection:**

```

1 0.000000000 [client-wifi-adapter] → Broadcast ARP Who has 192.168.1.1? Tell 192.168.1.32

[repeats 3 times then stops after static entry injected]

```

Immediately after the static ARP entry was injected for the gateway, ARP broadcasts ceased and full bidirectional traffic (DNS, TCP, TLS) resumed within milliseconds — confirming ARP resolution was the sole point of failure.

---

**ARP Table During Failure**

The following shows the ARP table on the affected device during the failure. Note the complete absence of any unicast entry for the gateway:

```

Interface: 192.168.1.32

Internet Address Physical Address Type

224.0.0.22 01-00-5e-00-00-16 static

224.0.0.251 01-00-5e-00-00-fb static

239.255.255.250 01-00-5e-7f-ff-fa static

255.255.255.255 ff-ff-ff-ff-ff-ff static

```

After static ARP entry injected and connectivity restored:

```

Interface: 192.168.1.32

Internet Address Physical Address Type

192.168.1.1 [router-mac] static

224.0.0.22 01-00-5e-00-00-16 static

224.0.0.251 01-00-5e-00-00-fb static

239.255.255.250 01-00-5e-7f-ff-fa static

255.255.255.255 ff-ff-ff-ff-ff-ff static

```

---

**Network Configuration**

- DHCP pool: 192.168.1.2 - 192.168.1.254

- Active devices: ~8 (well within pool)

- IPv6: Disabled

- UPnP: Enabled

- No satellites

---

**What This Is Not**

- Not DHCP exhaustion (253 address pool, 8 active devices)

- Not IPv6 conflict (disabled)

- Not a client driver issue (affects Windows, Android, and Linux simultaneously)

- Not a signal or band issue (clients remain 802.11 associated throughout the failure)

- Not ISP related (wired devices are never affected)

- Not a single device issue (multiple devices affected simultaneously)

---

**Workaround**

Manually injecting a static ARP entry for the gateway on each affected device restores connectivity without requiring a reconnect:

```

netsh interface ipv4 add neighbors "Wi-Fi" 192.168.1.1 [router-mac]

```

This is not a viable long term solution, particularly for Android devices without root access.

---

**Request**

This is a fundamental Layer 2 failure — a router that does not respond to ARP requests from its own associated WiFi clients is non-functional for those clients. Please escalate to the firmware team.