Testing CLAT for IPv6-only mobile networks

General
#62

A big thanks for the logs. From the error case it was quite obvious what causes that:

Feb 23 14:13:37 Xperia10III connmand[21419]: plugins/clat.c:clat_task_do_prefix_query() Trying to resolv ipv4only.arpa gateway (null)
Feb 23 14:13:37 Xperia10III connmand[21419]: plugins/clat.c:prefix_query_cb() state 1/prefix query status 8 GResolv 0x32bd9400
Feb 23 14:13:37 Xperia10III connmand[21419]: plugins/clat.c:prefix_query_cb() failed to assign prefix/resolv host, error -2
Feb 23 14:13:37 Xperia10III connmand[21419]: plugins/clat.c:prefix_query_cb() State progress or state change
Feb 23 14:13:37 Xperia10III connmand[21419]: plugins/clat.c:clat_run_task() state 6/failure
Feb 23 14:13:37 Xperia10III connmand[21419]: plugins/clat.c:clat_run_task() CLAT entered failure state, stop all that is running

It simply in that case cannot resolv the ipv4only.arpa. The error 8 means that there is no AAAA DNS record in the reply. Now this got me and Andrew thinking that could it be that 1) the DNS servers in some cases are set too late, or 2) the network has some glitch there, or 3) it is a bug somewhere in the depths of ConnMan completely elsewhere that is not easily triggered. It seems that the query is done twice as it should and both fail.

Your remedy of disable-enable would suggest a bug somewhere, or a network issue. However, will need to consider an approach to make CLAT try harder and longer to get a result for the address. However, the current one does indicate that DNS64 is not available. Will need to try to find a solution to this. Meanwhile, if you still encounter similar case that CLAT is not up because of unresolvable AAAA you could try what ping -6 ipv4only.arpa reports when you enter mobile data after losing WLAN and CLAT does not resume. Also, it is interesting to see what in that case ping -4 ipv4only.arpa gives.

2 Likes
#63

Thank you, i will do the ping tests next time and report back.

#64 
➜  ~ sudo ping -6 ipv4only.arpa
Passwort:
ping: bad address 'ipv4only.arpa'

➜  ~ sudo ping -4 ipv4only.arpa
PING ipv4only.arpa (192.0.0.171): 56 data b
ytes
ping: sendto: Network is unreachable
➜  ~

ping -4 to a webpage gave the same result.
ping -6 worked.

#65

So you only have an IPv6 from your provider, but their DNS server doesn’t support NAT64 and returns IPv4 addresses that you won’t be able to connect to? That’s really strange, I wonder what’s going on there.

#66

This was without CLAT interface. With working clat it pings with -4 and -6 switch but doesn’t get an answer.

#67

Hotspot still doesn’t work for me. Since the update, however, the Steam Deck no longer crashes when establishing a connection

#68

CLAT is only activated when NAT64 is detected, which is done by querying ipv4only.arpa and getting an IPv6 value back. If your DNS is returning IPv4 addresses for that, then connman has no reason to start CLAT. It can’t really do that anyway, as that query is also done to find out which prefix has been prepended to the IPv4 internet so it can use it for the CLAT network. It’s usually always the same one, but doesn’t have to be.

I’m wondering if that DNS result is cached somehow, or an old DNS resolver is hanging around when it should have been discarded.

1 Like
#69

Are the older versions still available on OBS or do they need a rebuilt? I would like to try tge 193.25 build and see if my problem with the crashing clat interface occurs too.

#70

Only the latest version is kept in the OBS repo. The easiest way to rebuild an older one would be to fork my project and edit the service file to point to the older tag. Otherwise check out connman and build it locally, if you have that set up.

1 Like
#71

I forked your repo and it build fine on OBS. But sadly i searched the commits of JB52923 of GitHub - LaakkonenJussi/connman: Sailfish OS fork of https://01.org/connman repo and couldn’t find the ones in your changelog. So i don’t know which revision i have to add to my service file. Any hint?

UPDATE: I figured it out myself.

1 Like
#72

Glad you solved it. If anyone else wants to do similar then I recommend going off the tags.

1 Like
#73

Out of curiosity, @abranson, my IPv6-only provider’s ipv4only.arpa cannot be pinged but I get its IPv6 addresses back. What is exactly the “query” to determine if the CLAT is needed or how to check from the command line that the CLAT “query” (or connection attempt) makes this decision ? Shall the ipv4only.arpa reply to a ping ?

[root@Xperia10III defaultuser]# ping -6 ipv4only.arpa
PING ipv4only.arpa (64:ff9b::xyzë:ab): 56 data bytes

--- ipv4only.arpa ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
[root@Xperia10III defaultuser]# getent hosts ipv4only.arpa
64:ff9b::xyzë:ab ipv4only.arpa
64:ff9b::xyzë:aa ipv4only.arpa

(I have failed to find the time to try your repo - I get the IPv4 from my IPv4-only ProtonVPN which is on all the time [but not during the above test]. I follow with interest the great work of your guys to get CLAT on SailfishOS!)

VPN doesn't work
#74

It shouldn’t be pingable - it’s not a real host. It’s a special reserved hostname that’s a shibboleth for a DNS64/NAT64 network. As the hostname suggests, it’s only defined as an ipv4 host (with two IP addresses), and if an IPv6 address exists for it then we can be sure that there is DNS64 happening, and from the result detect the subnet under which the network has wrapped the entire IPv4 internet.

So the new CLAT connman plugin queries for IPv6 records (AAAA) for that hostname.

If you don’t mind a bit of dry reading. The RFC explains it best:

1 Like
#75

I also get an ipv4 or an ipv6 address when pinging ipv4only.arpa.

@jlaakkonen

Testing the latest .30 release, no issues so far :+1:

1 Like
#76

Btw, the request to try pinging was just to do the DNS query. It wasn’t intended to be able to ping anything.

@miau Do you get v4 and v6 at the same time? You should only ever get one at a time.

Thanks for mentioning - .30 is now on OBS

1 Like
#77

@abranson

Yes, ping shows an IP address with both -v4 and -v6 switch. But the -v4 address is always a private one starting with 192.xxx.xxx.xxx. I can not check this right now, since i’m out of mobile coverage

#78

Yes, the real result of that host globally should be 192.0.0.170 and 192.0.0.171. If DNS64 is being used, then you’ll see 64:ff9b::c000:aa and 64:ff9b::c000:ab (usually, but the prefix could be different). Actually I think what you’re seeing is correct - you can still get the v4 results in DNS64, but it’s the presence of the v6 addresses that’s the important factor in enabling CLAT.

Btw, it turns out we actually have dig available if you want to use that instead, in the bind-utils package in the tools repo.

1 Like
#79

Hello,
Little feedback after two days
Lots of disconnection during days. I need to restart network service to resolving the issue.
I rollback to the official package
Thanks for you works

#80

Glad you figured it out somehow. I need to do occasional cleanups and squashes there to have it in some reasonable state as during development the commit amount can get difficult to handle.

Cool. We have .31 soon in the repo that might be one of the last ones. There was some old code that used to work but was a bit overlooked when adding IPv6 support.

#81

Looking forward to the next releases. In tge last days i only had the issue of the not upcoming clat interface 2-3 times :+1:

1 Like