Unfortunately, I’m also affected. The Wi-Fi freezes and reports poor signal quality. It even caused my Fairphone 6 to completely crash and restart during a Wifi reconnect. I’ve only had the device for a day; it’s brand new, and this is very frustrating. I hope it gets fixed quickly. Thanks
I had similar issues. I noticed that the loss of IPv6 connectivity only happened when the screen was turned off. Also, while I could not connect to IPv6 addresses outside my network, my phone could still ping other IPv6 hosts on its own subnet.
I interpreted this as a) definitely an issue with the RAs, and b) something to do with whether the phone receives/processes them when it’s asleep. This issue looks similar: Google Issue Tracker . I read through that entire thread.
Basically, what they say is that the issue is that phones try to preserve energy by not always processing multicast messages (including RAs) when the phone’s asleep. This leads to issues when the lifetime of the old RA runs out, without the phone having received a new one. A workaround is to configure the router to issue RAs whose lifetime is much (15x) longer than the interval at which RAs are sent.
I’ve tried this on my own network, and so far it’s looking good. Where before I could consistently get this issue to occur by letting my phone sleep for 10 minutes, after changing the RA configuration of the router, the issue seems to have gone away (the change is now 30 minutes old, so who knows).
For anyone also using a Ubiquiti EdgeRouter, this is the relevant part of the configuration:
router-advert {
default-lifetime 9000 /* this should be at least 15x max-interval */
link-mtu 0
managed-flag false
max-interval 300 /* don't set this too high */
other-config-flag false
prefix ::/64 {
autonomous-flag true
on-link-flag true
valid-lifetime 2592000 /* this should be at least 15x max-interval */
}
reachable-time 0
retrans-timer 0
send-advert true
}
You’re right (not that I doubted that). I checked the network details and there are no IPv6 addresses. At least I got rid of the annoying bug and I don’t have any problems in connecting to services on IPv4. When this is solved, I will change back to stateless.
An update from my side: I was using a Fritz!Box temporarily because our Unifi Cloud Gateway Max went haywire (every few days it would nuke a couple of VLANs). Last weekend I finally had time to factory-reset the Gateway Max and replace the Fritz!Box again.
Since I switched back to the Gateway Max, the issue has disappeared. Same configuration: IPv6 using prefix delegation + SLAAC, AdGuard DNS on the phone. So even though IPv6 RAs are the issue, it only occurs with the implementation in some routers.
We have to live with this problem until Fairphone releases a fix because we have a Fritz!Box from Vodafone. Our router doesn’t offer the option to disable IPv6. Vodafone restricts this option. I switched from a Nothing Phone 2 to the Fairphone 6 two days ago, and it’s a real shame. The Nothing Phone 2 also ran Android 16 and never had any problems.
hello @HoarseMantis is this a log- entry or a setup?
More confirmation from my side. I monitored router advertisements and the Unifi Cloud Gateway Max does not send advertisements to deprecate the prefix. Most likely the routers that do cause issues are using DeprecatePrefix on for radvd or something like that (which is kinda silly for ISPs that use static prefixes).
At any rate, the issue is clear from the AOSP bug tracker and a fix was also linked there. Should be easy for Fairphone to validate and incorporate.
Until then, the workarounds are disabling IPv6 (if possible), changing your router configuration to not deprecate the prefix if you have a static prefix and if possible, use 4G/5G-only, or in the worst case turn off/on WiFi every time. Possibly the situation could also be improved (but not completely solved) by using an IPv4 DNS server, because then at least the resolver does not get stuck.
This is the part of the configuration file that defines how the router sends router advertisements. It goes in the section interfaces ethernet <internal-interface> ipv6 router-advert etcetera. You can also set it up with set commands.
This sounds not unlikely, will also try this route over the next days. The thread also mentions increasing the DTIM to >=5, which is the thing I just configured first on my APs before going the default lifetime route next. Nevertheless, my access points have Multicast enhancements and UAPSD activated. In combination, Multicast RA should be converted to unicast according to the Google thread and stored until the phone requests these, so no RA ever be lost.
The workaround to disable IPv6 in my Fritzbox worked for me.
Thank you, this is exactly what happens to me and I was able to set up a few Authenticator apps that previously refused to work by turning Wifi off and on again. It’s nice to have an easy test for “is it this issue again”.
Disabling IPv6 is not really an option because I’m not the administrator of all Wifi networks I use
Disabling IPv6 is not really an option because I’m not the administrator of all Wifi networks I use
True. It became - not only because of this error - that I use wireguard on all wifis which i dont trust and/or i am not the admin. The wireguard i use is ipv4 only.
PS: yes, there a wifi I am the admin from but i dont trust (example company wifi).
Not fixed with the newest update…
Very annoying.
Yesterday, I had our Vodafone connection switched from DS Lite to Dual Stack. I now have a native IPv4 address in the Fritz!Box. However, I’m still experiencing Wi-Fi dropouts. After resetting the network settings on my Fairphone, it’s working a little better. The new Fairphone update that arrived this morning doesn’t seem to have fixed the problem yet. I’ll test it for a few more days and might send the Fairphone back. I’m really disappointed.
Problem not fixed… very disappointing. I stay with the app 1.1.1.1 that fixes the problem, but it’s a shame.
I confirm. It was not fixed with the last update. WiFi is still dropping.
The only workaround for me is to, every time, manually turn off and on the WiFi on my phone.
The Fairphone 6 is my first FP and might be the last if this bug is not fixed soon. No answers whatsoever from the support after 2 tickets. So disappointing.
The patch for this bug was not included in yesterdays update and the issue is investigated by Fairphone and potential fixes are already tested.
That’s good to hear but waiting for another month is really long. Maybe we get a hotfix? So let’s wait and hope for the best.
That’s good to hear and keeping my fingers crossed. Already thought from the patch notes, that this time no fix could be expected. I failed at all potential solutions in this thread so far which may have mitigated the problem from the outside.
Setting the DTIM to 5 (and later to 6) at the access points to influence the sleep mode of the phone had no effect. Also changing the default lifetimes of the router advertisments on the router as proposed by @HoarseMantis changed nothing. Tried default-lifetime of 9000 and max-/min-intervals of 600/300 and 200/100 respectively. Router defaults appear to have been 1800 (lifetime) and 600 (max) to 198 (min).
Confirmed these settings by running tcpdump listening for RAs on the router. RAs have been sent out exactly as specified. I could also not find an RA with a lifetime of 0 or any deprecations, so the problem here seems to be different from what @anon86108736 identified.
Single suspicious behavior I could see in the tcpdump traces was while and after running an IPv6-test (I wonder that test-ipv6.com did not already ban me because of the amount of tests I ran against them). While running the test successfully, I could see the router sending a Neighbor Solicitation for the phone’s global IPv6 address and the phone responding. A few seconds after the end of the test and me locking the phone, the router again asks for that same global IPv6 address, but there already was no reply from the phone. That should be a sign that the phone is no longer answering for its global SLAAC address after going idle.
After more than a minute, the traffic changed completely: then the exchange was only between the router’s link-local fe80::b6fb:... and the phone’s link-local fe80::ef2d:..., and both sides answer each other normally. That means the phone was still awake enough for local IPv6 neighbor discovery on the Wi‑Fi link, so this is not a total Wi‑Fi disconnect and not a total IPv6 collapse.
Please take all this with a grain of salt, I am not a network engineer, and wow, this stuff is complicated. I am afraid there is not much I could do from outside the phone beside disabling IPv6, but also wonder why not all networks seem to be affected. At least the family is happily chugging along with their phones undisturbed.
That shouldn’t matter in most cases anyway, DS-Lite vs. Dual Stack is on the other (external side) of the router.