Since the update from 1.4 to 1.5 (Android 10 to 11) on my FP3 WiFi-Calling no longer works.
On 1.4 WiFi-Calling was working without any problems. So Provider supports Wifi-Calling, Wifi-Calling is activated on the Phone and prefered when dialing
I hoped that 1.6 will fix it but it didn’t. So I rolled back to Fairphone-OS and installed a fresh /e/OS 1.6.
→ WiFi-Calling is still not working.
I tried every Tipp or Workarround an this Forum, but nothing fixed the Problem.
OS Verision now: /e/OS 1.6-20221129238947-stable-FP3
Would be great if someone could help.
Works for me on 1.6-s-20221201239247-dev-FP3 with a Telekom SIM card.
You could ask your mobile network provider whether they can currently see a problem with this on their end.
I called my provider (congstar), they checked everything and told me it’s all correct and Wifi-Calling should be working. I also made a Wifi-Call with my SIM in another Phone. It worked.
I think it must be my phone because wifi-Calling stopped working directly after the update from 1.4 to 1.5 (Android 10 to 11).
I fould these two posts from other users:
If there is a bug then I wonder under what circumstances it appears, because I doesn’t seem very spreaded.
Is there a way to compare ALL for Wifi-Call necessary settings of the FP3? … including permissions and the “advanced privacy” settings?
Thanks for your help.
Usually I don’t use Wi-Fi Calling, so I don’t know much about what could go wrong (apart from the whole thing in general for more or less comprehensible reasons).
For testing I …
- enabled Settings - Network and Internet - SIMs (I only have one) - Wi-Fi Calling
- in the same place made sure Calling Preference was set to Call over Wi-Fi
In Settings - Advanced Privacy my real IP address is exposed.
Thank you for your answer. I tried everything you said and other things too. I checkt allot of the settings twice, but still no Wifi-Calling.
But today something strange happend: I got a Call with Wifi and Airplanemode on and it said: incomming Wifi-Call !!! So I was surprised by it.
Immediately after the call I tried to make a call over Wifi. But then the old message popped up again:
“Mobile network isn’t available. Connect to a wireless network to make a call.”
What is going on? Seems like there is only a problem with MAKING a call and not getting one!
do you set any DNS servers yourself, either on-device or custom ones via dhcp? if so, give the ISP supplied a try. But this used to be only an issue with Vodafone that infers eligibility from the used DNS - might be moot with congstar. Incoming working but outgoing? really weird. Do you filter udp port 500 and 4500 ?
I didn’t change any DNS settings at my Router or FP and think they are all default.
On the FP3 under DNS:
Use network DNS is ON
only if I turn it OFF I can see “Enter DNS IP” it’s set to 22.214.171.124
looking at “
adb logcat” while trying to place a wifi call (you can set it to prefered so it will give it a try first) maybe yields a verbose reason for it to fail?
From your description the reason must be on-device. But still would be helpful to tcpdump at the router if any dns querys for 3gppnetwork.org occur and packets to udp 500/4500 leave the device.
here’s a (lengthy) german article on the wifi perspective, but as I said I think issue must be on-device.
I think @Liquid77 that you might continue your research with your carrier on the basis that this might be an APN settings issue.
When I search the internet for “congstar + wifi calling + APN” I got many hits.
Another hint to this idea is that you just Upgraded Q → R; in /e/OS -r- branch, prebuilt/common/etc/apns-conf.xml · v1-r · e / os / android_vendor_lineage · GitLab there is no match for “congstar”, while in the Q branch there are two hits.
<apn carrier="congstar Internet" mcc="262" mnc="01" apn="internet.telekom" type="default,supl" protocol="IPV4V6" roaming_protocol="IP" authtype="1" user="congstar" password="cs" mvno_type="spn" mvno_match_data="congstar" bearer_bitmask="1|2|3|9|10|11|14|15" />
<apn carrier="congstar Internet" mcc="262" mnc="01" apn="internet.telekom" type="default,supl,mms" protocol="IPV4V6" roaming_protocol="IP" authtype="1" user="congstar" password="cs" mvno_type="spn" mvno_match_data="congstar.de" mmsc="http://mms.t-mobile.de/servlets/mms" mmsproxy="126.96.36.199" mmsport="8008" bearer_bitmask="1|2|3|9|10|11|14|15" />
This post does not give conclusive advice, nor does it mention wifi-Calling, but does demonstrate some of the issues found with #apn + #fp3 FP3 roaming/APN not working.
Of course they cannot see the APN settings on your device, and they may think that their settings have been issued to you on the fly. I suggest you call them again and ask to have the full APN settings sent direct to your device.
You can check your settings and try to edit them manually from Congstar’s own published APN settings. In my searches I found unusual variance in recommended settings as in this article (which I do not particularly recommend, but include only because it seems to show up unusual issues with Congstar’s settings).
Settings > Network and internet > Mobile network > Advanced > Access point names
Thanks for your answer. It took a while and I talked to congstar asking them for the right APN Config. I changed some settings back an forth, but no luck with the Wifi-Call. Still the same problem.
Now I finally figured out how to make the log-File and I put it in here.
For me it is difficult to see the error or problem in the log-text but hopefully one of you can find the problem there.
My phone was on Airplane-Mode ON (although the text says it is OFF - but maybe I misunderstand something here)
Does anyone see the Problem why Wifi-Calling is not working ?
— I don’t know how to post such a long text-file so I put it here: log-Wifi-Call-Problem
from the log it seems it stays in the cellular connection at all times, no try at wificall at all. I’ll be with a FP3 next weekend that has known to work wificall (with telefonica) and document the loglines. I found these relevant, but hardly a hint on what is going on or missing:
[ 02-03 20:21:58.721 1171:10934 D/ConnectivityService ]
requestNetwork for uid/pid:10138/6578 NetworkRequest [ REQUEST id=296, [ Transports: CELLULAR Capabilities: IMS&TRUSTED&NOT_VPN Specifier: <TelephonyNetworkSpecifier [mSubId = 1]> Uid: 10138 AdministratorUids:  RequestorUid: 10138 RequestorPackageName: com.qualcomm.qti.cne] ]
The cne is a connectivity helper determining network quality and capability. Maybe it’s denying the use of the wificon - lots of speculation. Will update next weekend.
Wow… thanks allot for your help. I’m excited. After month of trying I’m so happy to see some progress - no matter where it will lead to at the end.
Wifi-Call at my home is very important because very often there is no mobile connection. So most of the time Wifi is the only way of getting mobile calls at all.
imho you have missing system libs at /system/ for whatever reason. But the comparison isn’t clean as my FP3 is already on Android S, maybe it had different libs in R but that’s unlikely.
WifiCalls were possible at all times with the FP3 and Telefonica. I could post the full log of successful call initiation, but I think it’s obvious you’d need to solve the “dlopen failed” (well, file missing) at
[ 01-29 15:02:13.576 1999: 2648 E/AndroidRuntime ]
FATAL EXCEPTION: FrameworkReceiver
Process: .qtidataservices, PID: 1999
Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/system_ext/lib64/libvndfwk_detect_jni.qti.so" needed or dlopened by "/apex/com.android.art/lib64/libnativeloader.so" is not accessible for the namespace "vendor-classloader-namespace"
... 7 more
I have the lib at that place
FP3:/ # ls -l /system/system_ext/lib64/libvndfwk_detect_jni.qti.so
-rw-r--r-- 1 root root 10848 2009-01-01 01:00 /system/system_ext/lib64/libvndfwk_detect_jni.qti.so
are you able to reflash any version again? please do so. Maybe pick the S dev variant
(to just see the call init, I looked at it with “
adb logcat Dialer Telecom TelephonyProvider QCNEJ/WlanStaInfoRelay QCNEJ *:S”)
Thanks allot !!! That’s so strange.
On my phone there’s the lib-file at the same path, too. So it’s not missing.
I can make a clean install again. But I wonder why at first place the system libs didn’t come back. I mean, I already rolled back to FairphoneOS as the problem first appeared. Then I installed /e/OS 1.6 over EasyInstaller.
Why didn’t this fix the missing system libs? Do I this time have to do it different? Should I include or consider this time something more? Is there a way to “clean” the phone-memory?
don’t know… selinux has also a say in what can be accessed. Really don’t know what went wrong, but the exception is obvious that a this time the process can’t access it - can be a permissions issue. Welp, not sure how to think of reasons, I’d just reflash
Thanks again. You helped me a lot. I will wait for 1.19-s and reinstall again. I will post the result.