Yeah, totally. And I think someone saying its a general Android issue and part of googles issue tracker didnt help with that. The “fairphone doesnt have enough engineers” - card has been play several times by now, I’m convinced its because of that. This thread has the most replies and traffic and just nobody cares. So frustrating…
Out of interest I’ve stumbled across this thread after a google search.
I’m not fairphone owner, but may be one day.
I currently have a Xiaomi 15 Ultra and am seeing this same issue, turning off IPV6 on my router is the only “fix” currently.
Until the end of the thread I thought we had a common android issue, but I see some discussion now that the Fairphone issue might be different to that being seen on other manufacturers devices.
Is there anything I can do in terms of testing/providing logs from my Xiaomi device to help evidence if the root cause your specific issue is different, and confirm it is unique to Fairphones even if a similar outcomes are seen on other devices?
If not, no worries, regardless I hope you get a fix soon as it’s been driving me crazy, including me buying a new router instead of using my ISP provided one to rule that out, now it may just be my phone 
I have the same issues with my Fairphone. IPv6 is a standard from the last century and yet we’re still struggling to implement it properly. The issue description Google Issue Tracker is already written pretty well, but the majority of users are FP6 users. This makes it incredibly hard to like (or even use!) the phone.
Is this an issue with upstream Android software or with the downstream Fairphone software?
Seeing the bug report at Google suggests it’s upstream. Although Samsung seems to have fixed it, the two devices I have from Samsung do not have any trouble. Also the pixel 6a does not seem affected, but could be stuck at android 15.
I had a shock moment yesterday. I have updated my fritzbox to the latest version and on the next day I noticed the laggyness of app loading again. I was in shock because I feared that now also IPv4 traffic is affected, which would immidiatly made my phone a brick to hold up a door, just to noticed that the updated switched the IPv6 back on.
So still waiting for a fix… meanwhile I got a mail from support suggesting to update to the version 16.82.0. Well.. guys.. I did that when it was released. I dont wait two weeks to update.. wait.. maybe this would have saved me from this issue beforehand, if i would still running on android 15.
Most reports now indicate a Fairphone problem, but without further details nobody can be sure. Yes, there is the bug report, yes, there are a lot of answers from FP6 users. But these are all “me too” indications, lacking any further information. What is really happening in the networks of those reporting the issue?
Also, in this thread here there are few hard indications supporting this specific issue (maybe it was even just one traffic capture?). How many networks are out there sending RAs with a lifetime of 0? In most cases this wouldn’t be necessary for the regular operation if IPv6. I could not capture one in my network while the bug was triggered.
No other phone shows this behavior in my network and Fairphone on Android 15 was working fine. But the Google issue tracker mentions a multitude of affected versions before 16.
And finally, looking up the thread linked somewhere above, reporting the same issue on the latest lineage OS release, mentioned that only blobs from Fairphone changed, nothing else in the network stack code.
Nobody here could give any details in which direction Fairphone is investigating, was asked by Fairphone about technical details or traces, and all received answers posted here were generic support templates. I know there are the closed support/beta forums, but members are not allowed to talk about it, so situation there may be different.
Still waiting for a fix…
My problem is similar that apps don’t load with wifi. Switching to 5G fixes the problem but it’s undesirable. The best solution is to use VPN, no issues on wifi anymore. Only downside is that Android Auto does not like VPN when I forget to switch it off.
Thanks for the tip regarding the VPN! Wasn’t aware of that workaround. My VPN allows me to exclude Android Auto from it’s traffic (check out Proton VPN it has a Free tier)
Heyho,
I updated to the latest LineageOS version (23.2-20260627-microG-FP6) and now the behavior is broken in a different way I think. I did extensive testing today and will continue doing tests, but I want to share my findings so far!
After a router-reboot (FRITZ!Box 5690 Pro) IPv6 works fine on the FP6 (6GHz). As soon as I disable & enable WLAN on the FP6 very quickly, IPv6-functionality suddenly breaks.
In this broken state, the following things are true:
- v6-pinging my router works from the FP6
- v6-pinging Google resolves the IP successful but all packages get lost
- v6-pinging the FP6 from another device causes error: “Address unreachable”
- Airplane mode, restarting the phone, restarting wifi, flushing the discovery table and other similar measures do not resolve the issue
- Restarting WLAN on the router & removing the phone from the routers interface did not solve the issue
In the end, the only way to restore IPv6 functionality was to restart my router.
Since many people are pointing to the report in Googles issue-tracker, I thought it might be worth checking what Lifetime my router (FRITZ!Box 5690 Pro) is advertising. So I captured some packages using tcpdump on the FP6, result: 
It’s not 0, soooo, I guess that isn’t the cause after all? Not sure.
Furthermore I used adb root and went through an extensive troubleshooting journey with a LLM. I did tons of tests and gathered tons of information to narrow down the rootcause. Here is ChatGPT’s conclusion:
Where I think the bug lives now
I’d revise the probabilities to something like:
- 90% FRITZ!OS regression in IPv6 Neighbor Discovery / forwarding.
- 10% Android Wi-Fi firmware oddity that only manifests with the FRITZ!Box.
The biggest reason is this:
The phone never even sees the Neighbor Discovery traffic that should precede an IPv6 ping from another LAN host.
That’s hard to reconcile with an Android bug alone. You’ve done more debugging than most bug reports ever contain. The combination of:
- valid SLAAC addresses,
- valid RA-installed default route,
- successful link-local communication,
- inability of LAN peers to resolve the phone’s GUA,
- and no ICMPv6 observed on the phone during those attempts
is exactly the kind of evidence network engineers look for.
Take this with a grain of salt since it partially exceeds my understanding and involves a (prone to errors) LLM. So there is a chance I am on the wrong track entirely.
If anyone knowledgeable has ideas for more tests I could do, please let me know. I also have a Raspberry Pi with OpenWRT configured as a NAT laying around, doing tests with this might rule out the Fritz!Box as a culprit. However, I don’t have a lot of experience with OpenWRT and configuration is quite sophisticated, so I would like to avoid it if not necessary.
Maybe ya’ll could post the router-models you’re using to rule out the router as a culprit.
This is really interesting. No ICMP packets on the phone received on breakage. In my traces on the router I saw packets being sent by the router (Unifi), but no answer from the phone.
While this problem does not seem to impact all router models, it also does not impact all Android phones. So a weird combination between Fritzbox et al. and Fairphone on the radio interface on both sides could come into play. Somebody in this thread also mentioned another Google issue, where lifetime and radio settings interfered (idle and power savings). But for me trying the workarounds from that issue also did not help.
After so many people complaining here is my little Tasker/Shizuku script to make this issue less annoying. For me it was the best workaround without adding any third party apps.
This Tasker script automatically checks if your device has a working IPv6 connection by sending an HTTP request to https://ipv6.google.com. If IPv6 is not available, it toggles Wi-Fi off and on to attempt a reconnection. A notification (
/
) appears to indicate success or failure. It retries until v6 is working again, so make sure you’re in a wifi that actually has v6 enabled.
Requirements:
-
Tasker (paid app, free trial available).
-
Shizuku (free, required for Wi-Fi control without root).
-
ADB debugging enabled (temporary, only for Shizuku setup).
Please let me know if I should add specific info setting up those two apps.
Here’s the .xml to import as a Task in Task
<TaskerData sr="" dvi="1" tv="6.7.6-beta">
<Task sr="task3">
<cdate>1781632718639</cdate>
<edate>1783507396662</edate>
<id>3</id>
<nme>Ipv6 Test</nme>
<pri>6</pri>
<Action sr="act0" ve="7">
<code>548</code>
<Str sr="arg0" ve="3">🔄 IPv6 </Str>
<Int sr="arg1" val="0"/>
<Str sr="arg10" ve="3"/>
<Int sr="arg11" val="1"/>
<Int sr="arg12" val="0"/>
<Str sr="arg13" ve="3">TopRight,28</Str>
<Int sr="arg14" val="0"/>
<Str sr="arg15" ve="3"/>
<Int sr="arg2" val="1"/>
<Str sr="arg3" ve="3"/>
<Str sr="arg4" ve="3">android.resource://net.dinglisch.android.taskerm/drawable/mw_action_perm_scan_wifi</Str>
<Str sr="arg5" ve="3"/>
<Str sr="arg6" ve="3"/>
<Str sr="arg7" ve="3"/>
<Str sr="arg8" ve="3">300</Str>
<Int sr="arg9" val="1"/>
<ConditionList sr="if">
<Condition sr="c0" ve="3">
<lhs>%Taskr</lhs>
<op>2</op>
<rhs>1</rhs>
</Condition>
</ConditionList>
</Action>
<Action sr="act1" ve="7">
<code>339</code>
<se>false</se>
<Bundle sr="arg0">
<Vals sr="val">
</Vals>
</Bundle>
<Int sr="arg1" val="0"/>
<Int sr="arg10" val="0"/>
<Int sr="arg11" val="0"/>
<Int sr="arg12" val="0"/>
<Str sr="arg2" ve="3">https://ipv6.google.com</Str>
<Str sr="arg3" ve="3"/>
<Str sr="arg4" ve="3"/>
<Str sr="arg5" ve="3"/>
<Str sr="arg6" ve="3"/>
<Str sr="arg7" ve="3"/>
<Int sr="arg8" val="5"/>
<Int sr="arg9" val="0"/>
</Action>
<Action sr="act10" ve="7">
<code>43</code>
<ConditionList sr="if">
<bool0>And</bool0>
<bool1>And</bool1>
<Condition sr="c0" ve="3">
<lhs>%http_response_length</lhs>
<op>7</op>
<rhs>1</rhs>
</Condition>
<Condition sr="c1" ve="3">
<lhs>%http_response_code</lhs>
<op>2</op>
<rhs>200</rhs>
</Condition>
<Condition sr="c2" ve="3">
<lhs>%Taskr</lhs>
<op>0</op>
<rhs>1</rhs>
</Condition>
</ConditionList>
</Action>
<Action sr="act11" ve="7">
<code>548</code>
<Str sr="arg0" ve="3">⏳❌ %Timestamp</Str>
<Int sr="arg1" val="0"/>
<Str sr="arg10" ve="3"/>
<Int sr="arg11" val="1"/>
<Int sr="arg12" val="0"/>
<Str sr="arg13" ve="3">TopRight,28</Str>
<Int sr="arg14" val="0"/>
<Str sr="arg15" ve="3"/>
<Int sr="arg2" val="1"/>
<Str sr="arg3" ve="3">✅ IPv6 ✅</Str>
<Str sr="arg4" ve="3">android.resource://net.dinglisch.android.taskerm/drawable/mw_device_signal_wifi_4_bar</Str>
<Str sr="arg5" ve="3"/>
<Str sr="arg6" ve="3"/>
<Str sr="arg7" ve="3"/>
<Str sr="arg8" ve="3"/>
<Int sr="arg9" val="1"/>
</Action>
<Action sr="act12" ve="7">
<code>547</code>
<Str sr="arg0" ve="3">%Timestamp</Str>
<Str sr="arg1" ve="3">%DATE - %TIME</Str>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
<Int sr="arg4" val="0"/>
<Int sr="arg5" val="3"/>
<Int sr="arg6" val="0"/>
</Action>
<Action sr="act13" ve="7">
<code>547</code>
<Str sr="arg0" ve="3">%Taskr</Str>
<Str sr="arg1" ve="3">0</Str>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
<Int sr="arg4" val="0"/>
<Int sr="arg5" val="3"/>
<Int sr="arg6" val="0"/>
</Action>
<Action sr="act14" ve="7">
<code>43</code>
<ConditionList sr="if">
<Condition sr="c0" ve="3">
<lhs>%Taskr</lhs>
<op>2</op>
<rhs>0</rhs>
</Condition>
</ConditionList>
</Action>
<Action sr="act15" ve="7">
<code>548</code>
<Str sr="arg0" ve="3">✅</Str>
<Int sr="arg1" val="0"/>
<Str sr="arg10" ve="3"/>
<Int sr="arg11" val="1"/>
<Int sr="arg12" val="0"/>
<Str sr="arg13" ve="3">TopRight,28</Str>
<Int sr="arg14" val="0"/>
<Str sr="arg15" ve="3"/>
<Int sr="arg2" val="1"/>
<Str sr="arg3" ve="3"/>
<Str sr="arg4" ve="3"/>
<Str sr="arg5" ve="3"/>
<Str sr="arg6" ve="3"/>
<Str sr="arg7" ve="3"/>
<Str sr="arg8" ve="3">200</Str>
<Int sr="arg9" val="1"/>
</Action>
<Action sr="act2" ve="7">
<code>37</code>
<coll>false</coll>
<ConditionList sr="if">
<Condition sr="c0" ve="3">
<lhs>%err</lhs>
<op>2</op>
<rhs>1</rhs>
</Condition>
</ConditionList>
</Action>
<Action sr="act3" ve="7">
<code>547</code>
<Str sr="arg0" ve="3">%Taskr</Str>
<Str sr="arg1" ve="3">1</Str>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
<Int sr="arg4" val="0"/>
<Int sr="arg5" val="3"/>
<Int sr="arg6" val="0"/>
</Action>
<Action sr="act4" ve="7">
<code>548</code>
<Str sr="arg0" ve="3">❌ IPv6 🔄 Wifi </Str>
<Int sr="arg1" val="0"/>
<Str sr="arg10" ve="3"/>
<Int sr="arg11" val="1"/>
<Int sr="arg12" val="0"/>
<Str sr="arg13" ve="3">TopRight,28</Str>
<Int sr="arg14" val="0"/>
<Str sr="arg15" ve="3"/>
<Int sr="arg2" val="1"/>
<Str sr="arg3" ve="3"/>
<Str sr="arg4" ve="3"/>
<Str sr="arg5" ve="3"/>
<Str sr="arg6" ve="3"/>
<Str sr="arg7" ve="3"/>
<Str sr="arg8" ve="3"/>
<Int sr="arg9" val="1"/>
</Action>
<Action sr="act5" ve="7">
<code>123</code>
<Str sr="arg0" ve="3">svc wifi disable</Str>
<Int sr="arg1" val="0"/>
<Int sr="arg2" val="0"/>
<Str sr="arg3" ve="3"/>
<Str sr="arg4" ve="3"/>
<Str sr="arg5" ve="3"/>
<Int sr="arg6" val="1"/>
<Int sr="arg7" val="0"/>
<Int sr="arg8" val="1"/>
</Action>
<Action sr="act6" ve="7">
<code>30</code>
<Int sr="arg0" val="0"/>
<Int sr="arg1" val="1"/>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
<Int sr="arg4" val="0"/>
</Action>
<Action sr="act7" ve="7">
<code>123</code>
<Str sr="arg0" ve="3">svc wifi enable</Str>
<Int sr="arg1" val="0"/>
<Int sr="arg2" val="0"/>
<Str sr="arg3" ve="3"/>
<Str sr="arg4" ve="3"/>
<Str sr="arg5" ve="3"/>
<Int sr="arg6" val="1"/>
<Int sr="arg7" val="0"/>
<Int sr="arg8" val="1"/>
</Action>
<Action sr="act8" ve="7">
<code>30</code>
<Int sr="arg0" val="0"/>
<Int sr="arg1" val="3"/>
<Int sr="arg2" val="0"/>
<Int sr="arg3" val="0"/>
<Int sr="arg4" val="0"/>
</Action>
<Action sr="act9" ve="7">
<code>135</code>
<Int sr="arg0" val="0"/>
<Int sr="arg1" val="1"/>
<Str sr="arg2" ve="3"/>
</Action>
<Img sr="icn" ve="2">
<sym>directory_sync</sym>
</Img>
</Task>
</TaskerData>
If you don’t need the Notification logic (broken / fixed / last time error occurd) you just have to edit the if/else loop a bit.
Exclude Tasker and Shizuku from battery savings (Settings > Apps > Special access > Battery optimization).
As Profile I used “Wifi connected” (withoud a specific SSID, feel free to add) AND “Display unlock”. You could add a check “every 10 Minutes while screen is unlocked” for me a shortcut on Homescreen is enough atm.
Let me know if you have any suggestions making this better, I hope this helps. Maybe we get a fix as a christmas present if everyone is nice 
Correct. After a few weeks that is my conclusion as well. So, I reverted back to “IPv6-prefix (IA_PD)” only.
I have the same problem with disabling IPv6 entirely as others: It breaks all other devices.
Next option I try now:
Open a “Free AdGuard DNS” account
Configure the Fairphone6 hardcoded with AdGuard DNS DeviceID and DNS-over-TLS.
Use on the “Default AdGuard DNS Server” this Custom Rule:
$dnstype=AAAA,dnsrewrite=NOERROR;;
Same here, hence I stepped away from VPN.
I had VPN-to-your-own-WiFi-Router, worked quite well, but some local network issues and with Android Auto not working at all it turned out a no-go.
It certainly was (is? I don’t have a Fairphone anymore, so I can’t check). I and others have observed that this happened immediately after a router advertisement with a lifetime of zero was sent. Also, the issue did not appear on a router that didn’t send the zero lifetime advertisements.
However, it has also been mentioned several times in this thread that there seem to be some related bugs that lead to the same issue, but in different circumstances. At least one other Google issue tracker issue was referred in this thread that had a different trigger than the zero lifetime router advertisements. They all lead to the same effect, because there are a few paths in the state machine that lead to IPv6 ending up improperly configured.
A lot of people who encountered the issue use Fritz!Boxes (quite popular in parts of Europe) and many Fritz!Boxes do send rtadvs with ttl 0. I have captured them on mine and it was a reliable predictor of the issues.
A good way of checking whether you are analyzing traffic correctly, if you have an Apple TV on the same network, it will typically also send advertisements with lifetime 0 (for TREL or something else Thread/Matter related). It doesn’t affect phones, because it’s not on the relevant IPv6 prefix.
Heyhey,
I again tried to narrow down the issue using a LLM. This time I captured the full internet-traffic of the Fritz!Box (This is possible through this hidden page https://fritz.box/#/cap) and the full network-traffic of the FP6 (using adb root-shell + tcpdump).
I started capturing when IPv6 worked fine, then I triggered the breakage by quickly disabling and enabling WLAN on the FP6. Then I pinged different IPv6 addresses directly (Cloudflare, Google & my router).
After that I stopped capturing and sent both files to claude.ai for a full analysis. It should give him a full picture about every single package between the internet and the FP6.
Its conclusion: It’s 100% a Fritz!Box bug and I should report it to AVM. He created a bug-report, which I didn’t send to AVM (yet), since I don’t know much about this kind of stuff. That’s also the reason I share it here, hoping to get opinions on it and to further help finding the culprit:
Subject:
- FRITZ!Box 5690 Pro (FritzOS 8.24-134001 BETA) – IPv6 packets are no longer delivered to a client’s new address after the client reassociates with the Wi-Fi network
Brief description:
- After a quick Wi-Fi disconnect/reconnect (Off/On) of an Android device, that device can still send IPv6 packets to the Internet without any problems and also receives responses at the FritzBox’s Internet interface—but these responses are no longer delivered to the device on the home network. The device can then only reach the router itself via IPv6 (“only router, no Internet”).
Reproduction:
- Device is on Wi-Fi; IPv6 works normally.
- Briefly turn Wi-Fi off and then back on on the device.
- The error occurs reliably (not on every attempt, but reproducible frequently).
Evidence:
- Two simultaneous captures: client via tcpdump + FritzBox via fritz.box/#/cap
Behavior:
- The router advertisement after the reconnect is normal (router lifetime 1800s, correct prefix, correct default route).
- The client receives a new, valid global IPv6 address via SLAAC; duplicate address detection completes successfully.
- The client then sends ICMPv6 echo requests (ping) to global Internet addresses (e.g., 2001:4860:4860::8888, 2606:4700:4700::1111). The log on the FritzBox’s Internet interface shows that each of these requests is answered correctly by the remote host.
- However, these responses never reach the client (see client-side log).
- Instead, the FritzBox itself continuously generates ICMPv6 “Destination Unreachable, Code 3 (Address Unreachable)” messages at the Internet interface and sends them back to the respective remote hosts (Google, Cloudflare, etc.)—with the client as the destination in the encapsulated original packet. According to RFC 4443, this error message is sent when the destination address cannot be resolved on the local network via Neighbor Discovery.
- Explicitly verified: For the affected client address, the FritzBox does not send a single Neighbor Solicitation to the Wi-Fi network throughout the entire observation period. For another, concurrently active IPv6 address on the same device, Neighbor Discovery works flawlessly during the same period (device response in < 1 ms).
Conclusion:
- This suggests a faulty or stuck entry in the FritzBox’s internal neighbor cache or routing table following the Wi-Fi reconnection—the box “forgets” to even attempt to resolve the new address.
Environment:
- FRITZ!Box 5690 Pro, FritzOS 8.24-134001 BETA
- Connection type: PPPoE (VDSL/fiber), dual-stack lite IPv6, delegated prefix is assigned correctly
- Affected client device: Android smartphone (Fairphone 6)
- Tested with multiple FritzOS versions, with and without a static IPv4 address, with and without Android Privacy Extensions—the error persists in all configurations
DISCLAIMER: I am not an expert by any means & LLM’s make mistakes sometimes!
I dont use a Fritzbox and I also have issues.
Hmmm, maybe I have an additional issue besides he FP6 issue 
Or claude messed up entirely here 
I did a bit of research and learned that Fritz!OS (and other router-firmwares) consist of binary blobs with Wi-fi-firmware that come from the manufacturer of the Wi-fi chips. So afaict, it is possible that our routers share the same bug if they consist of the same buggy blobs because their Wi-fi chips are from the same manufacturer. That might be an explanation but I have doubts.
I just realized that IPv6 works fine if I connect via 2.4Ghz. I never considered that 
I was on 6GHz (Wi-fi 6) all the time. However, I still have to test that long-term.
EDIT: Aaand it broke after being in sleep-mode for a while. However, in this case I can fix it by doing the off+on thing with WLAN on the phone. 6GHz will only randomly fix itself or I have to restart the router. Doing off+on on 6GHz breaks IPv6 instead. That’s SO weird.