Would it be possible that Fairphone publishes a software update that reverts the wifi firmware to an older firmware version, as mentioned in post 480 ?
I am keeping Wifi completely disabled until a fix is released, and using only mobile data.
Wow, that’s an important find, thank you for your investigation.
I’m also running an analysis and research discussion on this topic with AI and I think the conclusions it drew from your tests should be mentioned here.
So everything from this paragraph on has been written by the AI:
Summary
The results from #557 and especially #559 seem to allow a somewhat more precise conclusion about the failure location.
The important combination is:
- The NS for the affected GUA/ULA is visible on the wire/WLAN.
- The FP6 remains associated with the corresponding solicited-node multicast group.
- “Icmp6InNeighborSolicits” in the Linux kernel does not increase.
- The kernel does correctly answer other incoming unicast NS.
- No NA is transmitted for the affected GUA/ULA.
- The link-local address continues to respond.
- GUA and link-local use the same solicited-node IPv6 multicast address and the same Ethernet multicast destination.
- The APF program itself appears to contain the relevant IPv6 addresses and the expected NA-generation logic.
Taken together, this makes a conventional Linux NDP/NUD problem or a simple L2 multicast filtering problem increasingly unlikely.
More importantly, it suggests that the packet is being consumed or discarded after WLAN reception but before normal IPv6 processing in the Linux kernel, and that the decision is apparently dependent on the ICMPv6 target address.
That makes an address-aware ND offload mechanism in the WLAN subsystem a particularly interesting candidate. This could be APF/ND offload, vendor ND offload, or another Qualcomm WLAN-firmware mechanism. At this point, however, the measurements do not distinguish between these possibilities.
One experiment therefore seems especially valuable:
Keep the Android/NetworkStack version and network configuration identical, but change only the FP6 WLAN firmware/vendor blobs.
The existing LineageOS observation involving older FP6 Wi-Fi firmware is potentially very important in this context, but it would be useful to establish exactly which components were changed and whether the IPv6/ND behaviour was tested systematically.
If such an A/B comparison has already been performed elsewhere, it would be extremely useful to document the exact firmware versions and unchanged components.
In other words, the key unresolved question now appears to be:
«Does changing only the FP6 WLAN firmware change the probability of the address-dependent NDP failure?»
A controlled answer to that question would be considerably stronger evidence than another comparison between different Android ROMs.
I’m not gonna read all that AI stuff, but regarding this, it’s exactly this change:
The relevant part is the wpss firmware, regdb doesn’t actually differ and bdwlan didn’t seem to make a difference either, I just pinned these two too to avoid future mismatches.
I didn’t have specific tests, just observing the results of IP V6 test after a while of idle and multiple users confirmation in everyday usage.
Thank you for the clarification.
Because the details of #559 were collapsed, and because it was also very technical and rather difficult to understand, I asked AI to create a shorter and human readable explanation of the results:
The phone’s Wi-Fi chip has a bug: when another device on the network asks “who has this address?”, the chip answers those questions itself instead of passing them to Android — but it
only knows the phone’s first address, the one it memorized at startup before the real internet addresses were assigned. Questions about any of the phone’s actual IPv6 addresses get
quietly thrown away, so from the network’s point of view the phone simply doesn’t exist.
We’re certain because of two things we could see directly: on a network recording, asking about the phone’s real address got no reply at all, while asking about the startup address —
sent to the exact same destination on the wire, so nothing outside the phone could tell them apart — got an instant answer. And Android’s own internal counter of “questions
received” never moved during the failed attempts, which means the messages were being killed inside the Wi-Fi chip before Android ever saw them.
Did you ask claude to tell you if it is possible to fix the problem, as well? 
that would probably require giving claude access to a development environment that has access to the source code of the wifi firmware and related tools and hardware
Thanks a lot for the deep analysis, which confirms a lot of the observations which have been made before!
In principle, it should be possible to let a frontier AI model analyse the binary firmware assembly code, especially as the good and bad blobs have been identified. Things like this have been done before for reverse engineering. But the exercise would purely be academic, it is not like we could deploy any fix on that matter.
Sorry to keep repeating myself, but the Fairphone team needs to take this more seriously and act faster. If a single independent maintainer found a quick solution to roll back the firmware, you should have released a hotfix patch yesterday! It is unacceptable to have to open an app, turn Wi-Fi on and off 50 times a day, and then force-close the app because it gets stuck loading indefinitely—all for the most basic functionality on a €500 smartphone. I should have returned the phone, but in a busy life, that isn’t easy either. Please provide a solution, send an email to your customers updating us on the fix status with an estimated timeline, and offer a discount code; otherwise, you will soon lose our support. I used to be a huge fan of this project, but now what am I supposed to say to a friend who asks for my opinion?
To be clear, I’ve found other bugs like brightness issues and battery drain with Bluetooth, but I understand and haven’t complained about those—I can turn off auto-brightness, charge more often, or use my phone less. But stable Wi-Fi is essential. I’m sorry to write like this, but please provide feedback.
I Hope the fairphone 6+ dont have the Problem too.
It does, it’s exactly the same behavior - but I’d expect it’s the same chipset and the same software, so not surprised.
Hello,
Same problem in France, i got an Fairphone 6 and when i’m connected to an network provided by “Free”, i got the problem.
I already try a lot of things like all of you guys, and i think the Fairphone Team take a lot of time to solve this issue.
It’s really a bad experience…
The phone is not working properly but the price is high.
Kind Regards
It would be nice to get a new reaction from Fairphone, whether the recent analysis was helpful, whether they need more data, etc. So far I haven’t heard anything.
I spent a lot of time over the last weekend, probably 6-8 hours overall, to get to those results. I hope it was worth it!
As mentioned many times before, this is not an official communication channel with fairphone. If you want to communicate with them, do it over the support. But I doubt putting prompts into an LLM will be of any use.
Yes, but have a look at reply 487 here.
I agree that a simple reply from FP’s side would help, maybe a time window or whatever, I really want this (switching to a Fairphone with e/OS) to work but it gets harder when basic stuff doesn’t work…
I now have apps that don’t work anymore since the last e/OS update (there’s already an active topic on their forum) and this apps not loading data on wifi bug makes it very hard to use the phone normally.
Hi everyone! I also suffer from this, and also did extensive debugging, and can only confirm the findings - phone ignores Neighbour Solicitation packets destined to IPv6 multicast addresses of the phone.
I just created a ticket in Fairphone Support suggesting they just disable IPv6 on the phone level until they are able to fix the WiFi firmware. This should be an easy patch (maybe even with a on-off toggle), and will fix this issue.
UPD: oh shoot. I just saw that they say, that turning off IPv6 in Android is not supported… Very unfortunate