Testing CLAT for IPv6-only mobile networks

General
#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
#82

1.32+git193.31 now on OBS, which should fix problems with tethering so it should always work if CLAT is active now.

If people have tried this out, and haven’t already reported which mobile network is used, please let us know so I can compile a list of which ones are working and which aren’t yet. That’ll help manage people’s expectations, and identify networks that need further investigation.

5 Likes
#83

I still got the problem that the clat interface sometimes doesn’t come up, when the phone switches from wifi to mobile data. I will send the log.

1 Like
#84

Thanks for the logs. Those are really helpful as it shows the error happening in resolving of the ipv4only.arpa while running as the resolving is used periodically to determine whether CLAT should be still on. It simply fails to resolv the address, I guess few errors in resolv should be tolerated.

2 Likes
#85

It is really puzzling why the AAAA DNS request for the ipv4only.arpa sometimes starts to fail in your case after 2 successful ones or when the mobile data should be online. The reply clearly states that there is no answer for the request. The request is repeated every 10min (as the requirement of repeating it 10s before the record expires cannot be complied with yet because of ConnMan internal architectural requirements…) and it should not be treated as a DDoS of any sort. There is no clear indication in the logs about why it even happens. Is that a poor reception area you are located where network easily breaks?

But for the other issues I made changes that are in 1.32+git193.33 (address remaining hotspot issues and fix error in stopping CLAT when resolving fails). It may be available later on today/tomorrow.

1 Like
#86

Reception is good and i do not have any connectivity issues.

Nevertheless installing 193.33 right now :+1:

1 Like
#87

193.33 is now building in the OBS repo, and I’ve also moved the tayga package to use the proper sailfish repo now that’ll be in the next release.

3 Likes