NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Device flipping to celllular/disconnecting when on WiFi? Read this for possible solution!
Technical Analysis and Repeatable Evidence of DHCP/Routing Bug in Netgear Orbi 971 (Router Mode)
Summary of Issue
In environments using the Orbi 971 system in router mode, certain iOS/iPadOS devices (tested: iPhone 16 Pro Max and iPad Pro 2024) sporadically exhibit a failure state in which the device:
- Remains physically connected to the Orbi Wi‑Fi network (SSID displays as connected),
- Maintains a strong Wi‑Fi signal with excellent throughput (700–1200 Mbps),
- Yet silently fails over to the cellular interface (e.g., 5G), with no data traversing the Wi‑Fi path.
Others on the Netgear forums over the past months have posted similar failures, using both Apple and Android devices. My analysis and solution may be correct for other non-Apple devices and other Orbi routers.
This failure is not associated with actual signal loss and does not trigger any user notification other than the UI-level switch from Wi‑Fi bars to a 5G indicator. It self-recovers after 1–2 minutes.
No other devices on my network (macOS, smart TVs, Windows laptops) display similar behavior.
Summary of Solution
- For any device exhibiting drops/flips to cellular when on a good WiFi signal, change IPv4 address to a manual address, outside the router’s DHCP range.
- Also, change DNS address to a manual entry – it can either be your router (192.168.1.1 usually) or a 3rd party DNS server of your choice.
- Finally, you must disable IPv6 on the 970 router – Advanced tab, expand the Advanced section in the sidebar, choose IPv6 and disable.
To learn more as to what the problem may be, read on.
My Environment
- Netgear Orbi 971 (Wi-Fi 7), latest stable firmware (9.13.1.2) as of July 2025.
- Router mode (default DHCP and NAT).
- IPv6 disabled at the router level.
- iPhone and iPad running latest iOS/iPadOS 18.5.
- Orbi system is sole DHCP and DNS provider on LAN.
- WAN is Comcast/Xfinity (stable, no packet loss during tests, 2100/300 dl/ul plan).
- Orbi clients tested within 15 feet of router or satellite in clear line-of-sight — eliminating signal strength as a factor.
Problem Behavior
When in default DHCP configuration (automatic IP and DNS):
- iOS devices periodically experience a silent failover to cellular (5G).
- Devices retain visible SSID connection.
- Internet connectivity is routed over cellular until the issue self-resolves.
- The issue is sporadic, occurring 1–5 times per week for me (others have seen higher failure rates) under default conditions.
- Disruptions have been reported on non-iOS devices on the Netgear forums.
- I wrote and tested an Apple Shortcuts automation that will trigger when the Apple device it is running on does a Wi‑Fi disconnect. It does not fire, confirming that SSID association is intact.
Testing Methodology and Key Finding
I conducted controlled testing to isolate the failure cause. After numerous incidents in DHCP mode, I applied the following configuration to both iPhone and iPad:
- Manually assigned IPv4 address within the LAN’s valid range (outside the DHCP pool to avoid collision).
- Manually assigned IPv4 DNS server set to 192.168.1.1 (Orbi’s own LAN IP).
- IPv6 explicitly disabled at the router.
This configuration has now been running for over 5 consecutive days as of the date of this posting, with no recurrence of the issue. Devices have remained on Wi‑Fi, and no visible or functional failovers to cellular occurred.
Why Disabling IPv6 Was Critical
On iOS and iPadOS, users cannot manually configure IPv6 addresses or DNS servers via the system interface. As a result, if IPv6 remains enabled on the network:
- iOS will continue to obtain IPv6 connectivity using SLAAC or DHCPv6 (often via Router Advertisements from the Orbi),
- Even if IPv4 is statically assigned, IPv6 may still be selected for outbound traffic when iOS considers it preferred (which is often),
- This reintroduces reliance on the Orbi’s IPv6 DHCP or routing stack, which in prior testing exhibited instability and routing failures, often leading to connectivity loss or fallback to cellular.
Thus, disabling IPv6 at the router level is a necessary precondition to ensure the device fully relies on the statically configured IPv4 path — eliminating Orbi-managed DHCP lease/route state from the equation entirely.
Theory: Root Cause Analysis
I propose the following sequence of events under default DHCP operation:
- iOS frequently initiates DHCP lease renewal or INFORM messages more aggressively than other OSes (due to roaming, sleep/wake cycles, and Apple’s proactive network health checks).
- The Orbi 971’s DHCP server intermittently fails to respond promptly (or at all) to these renewal or rebind requests.
- During this silent DHCP stall, the iOS device:
- Still has a valid SSID association and a cached IP,
- But considers the Wi‑Fi interface non-functional due to:
- Missing or expired lease,
- Failure to renew default gateway,
- Unsuccessful DNS resolution,
- Or failure to receive HTTP 204 from captive.apple.com.
- iOS silently switches to cellular, even with Wi‑Fi Assist disabled (which I did a long time ago), because it considers the Wi‑Fi path “connected but unusable.”
- Eventually, the Orbi responds again, routing is restored, and iOS resumes Wi‑Fi traffic — all without disconnecting or notifying the user.
Supporting Factors
- No failure symptoms observed under static IPv4 + DNS configuration with IPv6 disabled.
- Monitoring showed no WAN outage or SSID drop during incident periods.
- When using dynamic DHCP/DNS, the issue persists in high signal-strength environments, ruling out RF-related causes.
- IPv6 had previously been associated with similar instabilities and was disabled early in the test cycle.
Recommendations to Netgear Engineering
I recommend the following areas be prioritized for investigation:
- DHCP Server Responsiveness
- Analyze handling of frequent DHCP RENEW/INFORM messages from Apple devices.
- Investigate whether ACK or lease confirmations are being dropped or delayed.
- Internal Lease Table Integrity
- Confirm whether memory or timing issues affect DHCP state or ARP caching.
- Routing Table Consistency
- Validate propagation of default routes across mesh nodes, especially post-roaming or post-sleep.
- IPv6 Handling (if re-enabled)
- Evaluate Router Advertisement stability and DHCPv6 consistency.
- Provide user-accessible controls for IPv6 lease time and DNS relay.
- Debug Logging Tools
- Enable deeper client-specific DHCP logging in future firmware versions to support field diagnosis.
Conclusion
The silent failover of iOS devices to cellular, despite strong Wi‑Fi signal, appears to be rooted in intermittent failures of DHCP IPv4/IPv6 or routing state management by the Orbi 971. Disabling IPv6 and bypassing DHCP/DNS with manual configuration eliminated the issue so far — confirming the failure lies not in radio or ISP connection, but in the Orbi’s handling of dynamic IP and DNS lease logic under typical iOS behavior.
I welcome the opportunity to collaborate on further testing or provide supplemental logs to support engineering review.
15 Replies
lostinphotoland did you ever try doing the three things I suggested above, (a) disable IPv6 on the router (b) manual IP address on the device, outside the dhcp range (c) manual dns address(es), using any external servers (8.8.8.8, 1.1.1.3, etc.) but not the router as dns? Mine has been rock solid with no disconnects once I tried this workaround, for several weeks now...
UPDATE:
Starting with iOS 18.6.1 (I'm now on 18.6.2) I've found that I no longer "drop" my connection, at least according to the Wi-Fi icon, but I do have data transfer issues until my Wi-Fi changes from 3 of 3, then 2 of 3 "bars" to a full 3. It seems to be about the same amount of time I would see the Wi-Fi icon leave and I'd transition to 5G, only to return to Wi-Fi.
I had setup an active ping of my device while within the house and this seems to happen at random times throughout my home. Whatever the issue is, the phone and Wi-Fi are NOT happy with each other still.
While ping isn't to solely be relied on, especially on Wi-Fi issues, I can confirm that each time I'd see a drop in signal strength, I'd lose about 5-7 pings. I could be watching a YouTube video, browsing the web, playing an online game, or even the device is idle... the disruptions are still continuing.
I have also tested with disconnecting 1 of the 2 Wi-Fi nodes, which to my surprise didn't seem to adversely affect interior Wi-Fi service, but the issue did still continue to occur.
Ping statistics for 10.168.168.29:
Packets: Sent = 1336, Received = 1189, Lost = 147 (11% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 2279ms, Average = 68msHas your issue above continued to be resolved with the modifications to the config as detailed in your first post? I believe I have the same issue with my iPhone 16 Pro Max when connected to my Orbi 963. I wondered if getting the 970 series would resolve it, and it seems not, or maybe, now?
Hi WilliamGr I had to make one slight mod to the solution in my post. Instead of the manual DNS being the router at 192.168.1.1, I made it an external server - I used Cloudfare, 1.1.1.3, 1.0.0.3. You could use Google or any DNS servers of your choice. I still had flips to 5G, and I realized DHCP/DNS was still in play until I stopped using the router entirely.
Now that being said, I do still see about 1 flip to 5G a week. It's only on my iPhone 16 Pro that supports MLO/5GHz+6GHz connections; it's a problem with managing the simultaneous connections of the 5GHz and 6GHz bands. But it's a lot less now.
Unfortunately there is not a reliable way to turn off 6E on the iPhone 16, it favors that band so even if you change the setting WiFi 6E from automatic to Off, it will flip it back on at times. I also tried moving the iPhone to a dedicated IoT network, nothing else on it, since that only supports WiFi 5 - but again, the device favors 6E connections, so even if the main 6E network is 'forgotten', with the SSID/password in the Apple password keychain, it will grab it and connect there! I could have deleted the password from the keychain, but it's not worth the trouble.
On the 960 series, it does not support this WiFi 7 MLO technology, so I would not go to a 970 without trying this solution on your phone first. Here are my updated instructions, try it on your 963 and report back!
- Disable IPv6 on the router
- Go to your router admin web page, Advanced tab, LAN Setup, and change your DHCP range to something like 192.168.1.2 starting, 192.168.1.150 ending. This is to make room to create some manual address(es) outside the DHCP range, to avoid collisions; one for each device experiencing dropouts. The assumes your router IP address is 192.168.1.1.
- Go into settings for your iPhone WIFI connection, and for each device set a MANUAL IP address to something like 192.168.1.152 (or later; anything above your DHCP pool range set in #2), subnet 255.255.255.0, router 192.168.1.1.
- On the same page on your iPhone WiFi connection, set a MANUAL DNS address - add two routers there. Choose Google (8.8.8.8, 4.4.4.4), Cloudfare (1.1.1.3, 1.0.0.3), or another external DNS server of your choice. DO NOT point it to the router at 192.168.1.1. By steps 3 and 4 we are eliminating DNS/DHCP conversation between the phone and router.
- Do these steps on any other device seeing connection drops/flips to cellular. But start with your phone as a test case.
- Wait to see the WiFi connection icon at the top right of your phone, then test the connection via Speediest or browser to ensure all is set up and working ok!
See how that works. By ensuring there is no DNS/DHCP messaging with the router on either IPv4 or IPv6, for me the drops have 95% gone away.
lostinphotoland Try doing these steps on your iPhone 15 Pro Max; post here if you are unsure how to do any of them. My bet is this will likely eliminate the flips to cellular on your iPhone 15 Pro Max, since it supports the 6GHz band and not 5GHz+6GHz MLO that the iPhone 16's do:
- Disable IPv6 on the router (I think you have done this, be sure it's done on the router as you cannot set this on the phone)
- Go to your router admin web page, Advanced tab, LAN Setup, and change your DHCP range to something like 192.168.1.2 starting, 192.168.1.150 ending. This is to give us room to create some manual address(es) outside the DHCP range, to avoid collisions. The assumes your router IP address is 192.168.1.1.
- Go into settings for your iPhone 15 WIFi connection, and set a MANUAL IP address to something like 192.168.1.152, subnet 255.255.255.0, router 192.168.1.1.
- On the same page on your iPhone WiFi connection, set a MANUAL DNS address - add two routers there. Choose Google (8.8.8.8, 4.4.4.4), Cloudfare (1.1.1.3, 1.0.0.3), or another external DNS server of your choice. DO NOT point it to the router at 192.168.1.1. By steps 3 and 4 we are eliminating DNS/DHCP conversation between the phone and router.
- Do these steps on any other device seeing connection drops/flips to cellular. But start with your phone as a test case.
- Wait to see the WiFi connection icon at the top right of your phone, Then test the connection via Speediest or browser to ensure all is set up and working ok!
See how this works and report back!
After repeat testing I have discovered using internal DNS in addition to external DNS still causes the issue, once I set my DNS to EXTERNAL only, I was unable to reproduce the issue. The only thing I've noticed while stationary on my desk is that I seem to drop a level on the Wi-Fi indicator, and then it immediately returns. I've done various speed and load tests with no adverse issues indicated.
iOS 15.5
iPhone 15 Pro Max
lostinphotoland exactly - among other issues, there is a failure mode tied to either the Orbi’s DNS relay or 6 GHz bridge/ARP handling. Static IPv4 protects against DHCP lease loss, yet when you use a static DNS assignment to the router, the device still relies on the Orbi for both DNS resolution and layer-2 forwarding, both of which can silently break while Wi-Fi remains associated. We want ALL DNS/DHCP messaging to the Orbi eliminated, per my steps above!
I see there is new iOS 18.6 being made available. Anyone been trying these new iOS versions?
I just tested using an iPhone 15 Pro Max on iOS 18.6 (22G86) and not only did the issue return when set to "automatic", it failed to re-connect to the Wi-Fi on its own for about a minute, which is more than the usual 10-15 seconds I previously observed.
After this encounter, I tested and re-tested moving around the house. Disabling Wi-Fi for a minute, turning back on and testing around the house again. I used airplane mode and disabled Wi-Fi as well, waited a minute and re-tested. I even went into the Wi-Fi settings menu and could see a spinning circle on the SSID for my house.
Test methodology was:
- 1 round of walking around the hosue and stopping in various rooms and placing the phone down.
- 1 round of using SpeedTest.Net's iOS App to run their video test which helps generate traffic across the connection while moving to various rooms and also placing the phone down. During testing, I would note that the signal strength indicator for Wi-Fi would drop 1 bar, but would return within a few seconds. I never dropped the Wi-Fi the entire time according to the status icons.
Approximately 30-45 minutes later, I was playing a mobile game and received a Wi-Fi connection alert. I checked and sure enough I had showed as disconnected. I ran down to my office and checked a "ping -t" I had running against my phone and confirmed "Destination host unreachable" as well as various request time outs during the incident.
Ping statistics for 10.168.168.129:
Packets: Sent = 2833, Received = 2802, Lost = 31 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 1221ms, Average = 44msReply from 10.168.168.129: bytes=32 time=14ms TTL=64
Request timed out.
Reply from 10.168.168.129: bytes=32 time=126ms TTL=64
Reply from 10.168.168.129: bytes=32 time=118ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Reply from 10.168.168.128: Destination host unreachable.
Request timed out.
Reply from 10.168.168.129: bytes=32 time=20ms TTL=64
Reply from 10.168.168.129: bytes=32 time=82ms TTL=64
Reply from 10.168.168.129: bytes=32 time=7ms TTL=64
Reply from 10.168.168.129: bytes=32 time=108ms TTL=64
MikeM4937 thanks for the reply. I don't have an IoT or Guest network set up, so no risk of an issue there.
One thing you said, "Apple assumption is 6GHz and 5GHz are operating on different SSIDs", is not correct - Apple’s current “Recommended settings for Wi-Fi routers and access points” support article (updated May 1 , 2025) says to “Make sure that all routers on your network use the same name for every band they support. If you give your 2.4 GHz, 5 GHz, or 6 GHz bands different names, devices might not connect reliably to your network, to all routers on your network, or to all available bands of your routers. If your router is providing a Wi-Fi 6E network that isn't using the same name for all bands, Apple devices that support Wi-Fi 6E will identify the network as having limited compatibility." Check the article out here:
https://support.apple.com/en-us/102766
This makes sense too, as the router can't perform band steering or Multi-Link Operation (MLO) if the SSIDs are all different (which I don't believe Orbis support anyway, likely for these reasons).
You did say at the end, that your priority devices are set up with a static DCHP leases on the RBE971 - that's exactly what I said to do in my OP. Are you able to set static IP/DNS for IPv6 on Android devices? I can't on Apple - which is why IPv6 needs to be disabled. The issue I see is that DHCP messages need to be stopped, so that the router either dropping or delayed in response doesn't cause a flip to cellular for the device's internet access. It's possible your Android devices have different timings, or that they are not as aggressive as Apple devices in DHCP traffic, health checks, etc. I have seen late-model Apple devices with 30-50 DHCP messages an hour in the log! Have you looked at your router log to see how much DHCP traffic you have from your priority devices?
And you are right, a lot of these issues only affect WiFi 6 and 6E devices - older ones have no issues (this includes issues with IPv6 only with 6/6E devices imho). I would turn off 6/6E support as well, as 5GHz is plenty fast, but Apple devices have the annoying habit of flipping the setting back on without you knowing it!
I understood in your OP that you set your static IPv4 on the iPhone/iPad’s device settings. What I am doing is still using DHCP assigned IPs. I am using the “Address Reservation” setting on the “LAN Setup” page of the Netgear router. In my logs the only excessive DHCP requesting clients are 2x La Crosse wifi clocks. These go through every 20 to 30 seconds requesting an IP or trying to renew. Which per La Crosse is by design and normal for their clocks.
Via http://192.168.1.1/debug.htm if you enable “Enable LAN/WAN Packet Capture” and let it run for a few hours. You can review the packet captures contained within zip. To see if the RBE971 is doing the proper replies/ack. When I get time I actually plan to run a capture and review the packet captures on my home network to see. If the RBE’s DHCP process is working on my network.
I personally have not noticed this issue. Are you SSID setup and enabled where say it has main as 'Netgear', IOT as 'Netgear-IOT', and guest SSID 'Netgear-Guest'? Or are they different where none of them share a common string or naming? Example main as 'Family', guest as 'BobWIFI', IOT as 'IOT-network'? If you have approach as 'Netgear' and 'Netgear-IOT' when you connected from a WIFI 6E or 7 compatible Apple device it may have asked about connecting with the other similar SSIDs. I think Apple assumption is 6GHz and 5GHz are operating on different SSIDs. Which is not the case on the main SSID for the RBE97x series. If you don't want to change your SSIDs or don't recall, you can do a forget SSID and reconnect. If you get the prompt after putting in your password, click the 'not now'. My SSIDs have a common name format but different passwords. In my household, I only have one iPhone 16 Pro Max (wifi 7) it shows in advanced devices as connection type '5GHz + 6GHz'. While a member’s iPhone 15 Pro Max (Wi‑Fi 6E) shows 6GHz only.
https://support.apple.com/en-us/102285 also look at https://support.apple.com/en-us/102766
What is the status of your "Private Wi-Fi Address" when connected to your SSID? Have you tried setting this to 'off'? For my family's devices I have them all set to off. With a most of my priority devices setup with a static DCHP leases on the RBE971.
Very Nice. Hoping this gives more direction for NG to check into this. Good work around for users in meantime.
I have a similar but slightly different issue that has been an ongoing issue for my iPhone 15 Pro Max, even during trial testing.
My RBE871 and connected 870's are on 10.5.16.325719
There was noted improvement of random disconnections (even upstairs).
My iPhone 15 Pro Max is configured for Wi-Fi6e AUTO.
IPv6 IS disabled.
Network settings were recently reset entirely on the iPhone to remove any potential hidden or undesirable settings.
My RBE871 hands my phone off to my basement RBE870 when I'm in the basement (approximately 60 feet away diagonally). While this seems to be a recurring issue, it's not isolated to ONLY the basement.
My RBE871 is approximately 90 feet to the RBE 980 and 140 feet to an upstairs RBE870 that is in my pantry that is roughly 50 feet diagonally and horizontally (meaning pantry is on the main floor with the 871 router).
Intermittently, whether with or without an active call, my Wi-Fi status icon will drop 1 bar to 2 of 3 bars.
Shortly thereafter a full disconnection will occur and I'll failover to a single bar of LTE (tough issue with my provider and unable to resolve).
IF I am on an active Wi-Fi call via ATT using voice and this behavior occurs, I must return to the upper level of my home to re-establish Wi-Fi connectivity and eventually Wi-Fi calling via ATT.
While reviewing settings to compare against recommended from apple (Recommended settings for Wi-Fi routers and access points - Apple Support), I noted repeat DHCP requests occurring during my outage window from the web-based log. I've filtered the MAC a little, but it's definitely the one for my Wi-Fi interface and the IP my device has been using and is well within the outage window.
[DHCP IP: 10.168.168.129] to MAC address ea:28:f9:xx:xx:xx, Tuesday, July 29, 2025 11:06:39
[DHCP IP: 10.168.168.129] to MAC address ea:28:f9:xx:xx:xx, Tuesday, July 29, 2025 11:06:24
[DHCP IP: 10.168.168.129] to MAC address ea:28:f9:xx:xx:xx, Tuesday, July 29, 2025 11:06:21
[DHCP IP: 10.168.168.129] to MAC address ea:28:f9:xx:xx:xx, Tuesday, July 29, 2025 11:06:20I'm able to provide logs (including of when the incident occurred today) to you if desired, but I can't help but wonder if the device is having DHCP trouble as possibly indicated below. In the interim, I'll test the OP's suggested work-around to see if this aids in my ongoing issue.
Edit: I also noticed a large amount of queries from my phone throughout the prior evening, and a healthy amount of queries from my AppleTV (4k).
FURRYe38 I was curious if you had seen my reply. This issue is still occurring anytime I come from upstairs to my basement.
