I connected my PC to FP3 hotspot while my home WLAN was switched off.
I confirmed that I could normally (i.e. slowly) access internet pages from the PC.
And just for your reference, the APN settings on FP3 following Telekom recommendations: APN Name: Telekom Internet IPv6 APN: internet.v6.telekom Benutzername: telekom Passwort: tm
Nutzen Sie ein Gerät mit Android, tragen Sie bitte noch zusätzlich folgende Informationen ein: APN Protokoll: IPv4v6 APN Roaming Protokoll: IPv4
Then, as you requested, going to the test page obtained the following result.
And just to confirm (mobile network coverage at my home is bad) I carried out a second run:
NAT64 is ‘mostly harmless’ unless the software uses a specific protocol or the server-side software is broken in some way. In this case, I’d guess that all features you mentioned use HTTPS. I don’t see any use case for FTP or a VoIP protocol in car traffic information.
If that test gets a 10/10, then I’m inclined to blame the car, or the car manufacturer’s server configuration.
(Do you also get the NAT64 warning if you visit test-ipv6.com on your phone over a mobile network?)
Today I managed to capture some network traffic between the Corolla and the FP3 hotspot using Wireshark in monitoring mode on my notebook. For this test I configured the FP3 with the APN that causes the trouble.
Unfortunately the forum does not allow to attach Wireshark log files. If someone is interested in the full log then please contact me so I can send it by email.
The following happens:
The car makes two DNS requests for both IPv4 and IPv6 for telematics.toyota-europe.com and receives two responses:
91.233.118.37 (IPv4)
64:ff9b::5be9:7625 (IPv6)
Then the car sends a TCP package to 91.233.118.37 and receives the following ICMP response: Destination unreachable (Network unreachable)
On my desktop computer I can access both https://91.233.118.37 and https://telematics.toyota-europe.com, although Firefox issues a security warning because Toyota has set up a bad certificate (SEC_ERROR_UNKNOWN_ISSUER). I’m not sure if that could be the cause of the problem (at least I would expect something like “certificate error” rather than “network unreachable”).
I think it would be mostly interesting to compare the log with one from an IPv4-only connection. This ICMP packet is strange given it’s from the v4 address.
I tried to simplify the test setup and not use the car at all. The hotspot behaves differently depending on the APN type, even when using a notebook as client:
when connected to FP3 hotspot with APN type IPv4/IPv6: “not reachable (ERR_ADDRESS_UNREACHABLE)”
when connected to FP3 hotspot with APN type IPv4: “insecure connection (ERR_CERT_COMMON_NAME_INVALID)”
when connected to home router: “insecure connection (ERR_CERT_COMMON_NAME_INVALID)”
The hotspot of Fairphone 3 with Android 10 seems to turn certificate errors into network errors when the APN type of its mobile connection is set to IPv4/IPv6.
Do I understand you correctly that also fairphone.com does not load over the IPv4/v6 connection? I am wondering, why you were able to access test-ipv6.com if that is the case.
(fairphone.com offers no IPv6 as far as I see, so you need IPv4 to connect to it)
Please run the test-ipv6.com on your phone while connected to mobile network - maybe the NAT64 error indicated some fault in the IPv4 routing of the hotspot rather than your ISP’s setup!
I happen to be on an IPv6 connection as well today, though without NAT64 and without a phone in-between (it’s wired.) I just get an invalid certificate when going to that IP address in my browser.
This sounds like a contradiction. Maybe, you get different IPv4 addresses from DNS when you are on NAT64? Do you have any custom DNS settings that would prevent using your ISP’s DNS?
Edit: and what does your phone’s browser do when browsing to the IP address?
$ nslookup fairphone.com
Server: 192.168.43.253
Address: 192.168.43.253#53
Non-authoritative answer:
Name: fairphone.com
Address: 84.22.101.48
Name: fairphone.com
Address: 64:ff9b::5416:6530
$ ping 84.22.101.48
PING 84.22.101.48 (84.22.101.48) 56(84) bytes of data.
From 192.168.43.253 icmp_seq=1 Destination Net Unreachable
From 192.168.43.253 icmp_seq=2 Destination Net Unreachable
^C
--- 84.22.101.48 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms
$ ping 64:ff9b::5416:6530
PING 64:ff9b::5416:6530(64:ff9b::5416:6530) 56 data bytes
64 bytes from 64:ff9b::5416:6530: icmp_seq=1 ttl=239 time=52.3 ms
64 bytes from 64:ff9b::5416:6530: icmp_seq=2 ttl=239 time=41.3 ms
^C
--- 64:ff9b::5416:6530 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 41.338/46.821/52.304/5.483 ms
$ ping fairphone.com
PING fairphone.com(lb1.ivaldi.nl (64:ff9b::5416:6530)) 56 data bytes
64 bytes from lb1.ivaldi.nl (64:ff9b::5416:6530): icmp_seq=1 ttl=239 time=58.9 ms
64 bytes from lb1.ivaldi.nl (64:ff9b::5416:6530): icmp_seq=2 ttl=239 time=54.5 ms
^C
--- fairphone.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 54.459/56.694/58.929/2.235 ms
That’s the same IPv4 address for fairphone.com I get on my desktop PC (connected to an IPv4 network), but it does not work over the IPv4/IPv6 connection.
The phone’s browser also cannot access 84.22.101.48.
I see what is happening, websites get an IPv6 address assigned using the NAT64 tunnel.
5416:6530 is the hexadecimal representation of 84.22.101.48, and 64:ff9b:: routes that through the tunnel. Together that forms 64:ff9b::5416:6530. You are supposed to ping or visit that address and clients that understand IPv6 will automatically do so.
I now see that the address your car got, 64:ff9b::5be9:7625, also ends in a hexadecimal representation of the corresponding IPv4 address 91.233.118.37.
Conclusion: Your car fails to connect to IPv6 when it is available. And that causes it to fail on NAT64 networks, because you have to use IPv6 for everything on those networks.
Yep, seems that I have to blame Toyota after all (or actually Panasonic).
Precedence rules for IPv4 vs. IPv6 look quite complex according to this article but in general it makes sense to prefer IPv6 over IPv4 and that is what the car fails to do.
So I’m going back to my workaround (use the old APN) and hope that there will be a firmware update for the car that fixes this issue.
Thank you for helping! I learned some interesting new things during this investigation.
Don’t forget to contact Toyota support. They might not immediately take action but if more people inform them that their services are unreachable on Telekom’s mobile network (you’re likely not the only one on NAT64), they might look into it at some point. While the setup used by Telekom is ugly, you are definitely hitting a car firmware issue here.
Thanks to AlbertJP and Harald for your analysis. It looks like I am having the same problem with VW Passat and a car-net connection using a telekom ipv6 apn since upgrading to Android 10 on my fp3
I changed the apn protocol to ipv4 however without success.
@harald could you tell me what apn settings you changed in order to bypass the error?
In addition, I would like to verify, whether VW has the same problem. However I don’t know how to prove it. The analysis was done with win10 correct? So how have you been able to prove the root cause being the car hardware?
Hi @fymwpm, which operator are you using? This is important to know as the unusual IPv6 setup of Deutsche Telekom was a major factor (even though the blame lay with the car hardware.)
We indeed used a laptop for analysis, to rule out problems with the phone’s IPv6 implementation. It looks like the FP3 implements IPv6 correctly, hence I don’t think we need to repeat the whole process.
I have some simple questions for you instead:
Could you post a screenshot of test-ipv6.com on your phone while connected to mobile internet?
Do other devices (laptops or phones) have internet access when connected to your hotspot?
I think it will not work changing only the protocol in the APN settings. You will also have to use a different APN network address, and maybe change other settings. It is also important to reboot the phone after changing APN settings, or the new settings won’t be used.
If it helps I could post the settings for German Telekom cards. APN settings for all providers should be available free on the Internet.
To analyze the communication between phone and car I used Wireshark on my Linux notebook. Wireshark is a popular network analysis tool and available for several platforms (also Windows).
However, I’m no longer sure that is is really a problem of the car’s software…
A week ago I did another test with the Telekom SIM card and the IPv6 APN settings, but instead of using the FP3 I inserted the card in my old FP2 - and it worked! The same car, the same SIM card, the same APN settings - working on FP2 with Android 7, not working on FP3 with Android 10.
Currently I don’t have the time to do deeper investigations but it might turn out that Fairphone (or Google) messed something up, not Toyota (or any other car manufacturer).
@AlbertJP
Thanks for your response.
I have the same provider as Harald, German Telekom. When connecting to the mobile phone hotspot with my notebook I have access to the internet. I recently provided internet to another phone and that worked as well. Please find a screenshot from test-ipv6.com, taken from my phone while connected via mobile network:
I would indeed be interested to try your settings on my FP3. So far, I did only change the protocol (and rebooted afterwards) but that was not getting me anywhere.
@harald, it would be interesting to see why the FP2 works. A quick Google search indicates that IPv6 hotspots were introduced as of Android 7, and that some Android phones run an IPv4-to-v6 translator called clatd. Maybe the FP2 is using this translator while the FP3 doesn’t have it or it doesn’t work for hotspots.
@fymwpm if a laptop can get a connection over this hotspot, then, in my opinion, so should a car. I don’t see any good excuse for car manufacturers not to support this setup if other devices do.
I can’t test anything on my own mobile internet connection, as I don’t have IPv6. My operator only enables it for ‘select’ devices and hasn’t published the APN settings to do it yourself. Their online how-to for the FP3 uses an IPv4 APN. (Simply changing the network type in the APN does not work.)
I learned some interesting new things during this investigation.
