NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

cg49me's avatar
cg49me
Initiate
Feb 04, 2026

Wi-Fi SoCs to repeatedly spam IP requests to the DHCP server

Fellow RBK/R/S850 owner here...  I've also experienced this issue for some time, having it intermittently occur following a power outage.  I eventually found that I could usually resolve things with a manual firmware "update" of the router (even if just "updating" to the same firmware version already installed; never needed to do anything with the satellites), and things were running pretty well for me for awhile on 7.2.7.15.

 

Over this last weekend, my nodes all auto-updated to 7.2.8.2, and this issue resurfaced.  Unfortunately, the manual firmware update trick was no longer working - I even tried going back to 7.2.7.15, and up to 7.2.8.5 (available from the Netgear RBR/S850 websites), but no matter what I tried, I'd only get about 20-30 devices in the house to connect (normally have around 70; IoT junkie here), notably excluding phones and laptops.

 

I consulted the router logs (which, bluntly, suck), and discovered a couple of devices were being repeatedly assigned the same respective IPs over and over, about once every 30 seconds each.  Fortunately, both devices were also appearing under the router's "Attached Devices" menu with identifying details (a Litter Robot 3 and Litter Robot 4), so I was able to track them down and clear their Wi-Fi settings, removing them from the network at their respective endpoints.  Rebooted the router, and everything else in the house connected without issue.

 

Evidently it's not uncommon for some (particularly cheap) Wi-Fi SoCs to repeatedly spam IP requests to the DHCP server, regardless of assignment lease time.  If the DHCP server isn't designed to handle this behavior, it can bog down, preventing further IP assignments.  I'm not opposed to leaving the Litter Robots disconnected from the network (I lose status notifications, but they have status lights that I usually check daily anyway), but if I'd happened to have another device exhibiting the same behavior (robot vacuum, for example), I would be less accepting of the situation.

 

Moral of my story:  If you're encountering the same behavior as the rest of us on this thread, check your router log to see if any devices are being assigned the same IP multiple times in a short time frame, try to identify those devices (either by checking for them in the router's "Attached Devices" menu, or via a search of the offending MAC address), and then try removing them from the network (this part will be dependent on the specific offending device; e.g. may have to perform a factory reset) to see if the issue resolves (may still need to reboot the router after removing the offending devices).

1 Reply

  • FURRYe38's avatar
    FURRYe38
    Guru - Experienced User

    Something to try for some of these devices that you see spamming DHCP requests. If they happen to support user configurable DHCP options and have a manual or Static configuration, Set a static IP address ON these devices. You'll need to open up a portion of the routers DCHP pool and set aside an IP address range OUTSIDE of the default DHCP IP address pool for these Static IP addressed devices. Means just adjusting the default DHCP pool size smaller. 

    https://kb.netgear.com/24089/How-do-I-specify-the-pool-of-IP-addresses-assigned-by-my-Nighthawk-router

    Might slow down or stop causing the DHCP spamming effect. 

     

    Can also try using the separate IoT network for these devices and see if this helps any. 

     

    Might help to let the Mfr of these devices that seems to be spamming router DHCP requests to see if they can help make adjustments as well. Seen lots of sub par IoT devices not having good DHCP and IP address connectivity operations coming from some of these IoT mfrs. May not be lots of good quality for some in this area. 

     

    Also some IoT devices may not operate well with a multi signal source MESH system like Orbi systems. Had NEST controllers that would unnesseccarily ping pong around not able to lock on to one signal source. Worked with NG on this and was determined that NEST needed to make some changes on there side to help controllers lock on to a signal in a multi signal source environment.