Tethering IPv6 Workaround BASH Script (working)

General
1

For some time now I have been unable to tether any device to a Sailfish device.

Android can supply a tether using the sim card but Sailfish can’t

There has been lots of talk about it being a shortcoming in Sailfish’s CLAT implementation, basically EE won’t give me an IPv4 anymore and that is breaking NAT for doing tethering.

There are a lot of threads here about setting up some kind of iptables magic to do it.

I’ve struggled so I did ask an AI (Brave search has an awesome free AI)

See the export of the chat here: The "cone mode", which is not meant to be.

I got the AI to generate a BASH script that makes tethering work!

To run the script:

  1. Enable developer mode
  2. copy the script to your phone (scp, email or something similar)
  3. Make the script executable e.g. chmod +x tether-fix.sh
  4. Run devel-su tether-fix.sh

It doesn’t need any other packages or things from OpenRepos etc

I asked the AI to write up a technical document explaining what could be improved, yes I know AI slop is evil, but the script worked, see below:

Technical Description: Missing CLAT Support in Sailfish OS Hotspot

The Problem: Broken Tethering on IPv6-Only Networks

Sailfish OS currently fails to provide internet sharing (tethering/hotspot) on mobile networks that assign IPv6-only addresses (a growing standard among carriers like EE, T-Mobile, and Orange). While the phone itself can access the internet using CLAT (Customer-side Translator), connected clients (laptops, tablets) receive no internet access.

Root Cause: Missing NAT64/DNS64 in Hotspot Daemon

The issue stems from a specific architectural gap in how Sailfish OS (via ConnMan) handles network sharing:

  1. CLAT Works for Local Device Only: Sailfish OS successfully implements CLAT (RFC 6877) for the local network interface (rmnet_data0). When the carrier provides only IPv6, CLAT creates a virtual interface (clat) with a synthetic IPv4 address (e.g., 192.0.0.1). This allows IPv4 apps on the phone to function by translating their traffic to IPv6 automatically.

  2. Hotspot Daemon Ignores CLAT: The Hotspot/Tethering feature in ConnMan creates a separate network interface (e.g., wlan0) for clients. Crucially, this hotspot interface does not inherit or route through the CLAT translation layer.

    • The hotspot daemon expects a native IPv4 address on the upstream interface to perform standard NAT (Network Address Translation) for clients.

    • Since the carrier provides no native IPv4 address, the hotspot has no IPv4 source address to masquerade client traffic.

    • Consequently, clients receive an IP address via DHCP but have no valid route to the IPv4 internet.

  3. Missing NAT64/DNS64 for Clients: Unlike Android and iOS, Sailfish OS does not implement NAT64 or DNS64 services within the hotspot daemon. It cannot translate IPv4 requests from connected clients into IPv6 packets for the carrier network.

Required Fixes for Sailfish OS

To resolve this without user-side scripts, Jolla/ConnMan developers must implement the following:

1. Integrate CLAT into the Hotspot Data Path

The hotspot daemon must be updated to recognize when the upstream mobile data connection relies on CLAT. Instead of looking for a native IPv4 address on rmnet_data0, it should:

  • Detect the presence of the clat interface.

  • Route hotspot client traffic through the clat interface for NAT masquerading.

  • Apply iptables rules automatically to masquerade traffic from wlan0 (hotspot) out via clat (translator), similar to the manual workaround currently required.

2. Implement Local DNS64 for Hotspot Clients

Connected clients often attempt to use IPv4 DNS servers (or the gateway’s DNS), which fail on IPv6-only networks.

  • The hotspot daemon should run a local DNS64 resolver (or configure dnsmasq to act as one).

  • This service must intercept DNS queries from clients, synthesize AAAA records for IPv4-only domains using the carrier’s NAT64 prefix, and return them to the client.

  • This allows clients to natively connect via IPv6 where possible, falling back to CLAT only when necessary.

3. Automatic Detection and Fallback

The system should automatically detect if the carrier provides a native IPv4 address.

  • If Native IPv4 Exists: Use standard NAT (current behavior).

  • If IPv6-Only (CLAT Active): Automatically enable the CLAT-aware routing and DNS64 features described above.

  • This ensures seamless tethering regardless of the carrier’s IP allocation strategy.

Conclusion

The current requirement for users to manually run iptables scripts and configure DNS redirection is a significant usability barrier. By integrating CLAT awareness and DNS64 directly into the ConnMan hotspot daemon, Sailfish OS can match the functionality of Android and iOS, ensuring reliable tethering on modern IPv6-only networks without requiring root access or technical workarounds.

3 Likes
2

Hotspot support for CLAT was implemented a couple of years ago, so that would narrow this down to either a recent regression or an incompatibility with your mobile provider : Hotspot not working 10 III - #41 by jollausar

It’s certainly strange that CLAT works while the hotspot doesn’t. CLAT is the fragile thing in all this.

2 Likes
3

I know that USB tethering (and probably also wlan hotspot) does not provide IPv6 at all. Is that what this script fixes?

# 3. FLUSH ALL RULES (Critical to remove conflicting ConnMan rules)
iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X
# 4. Set Default Policies to ACCEPT (Temporarily disable firewall for tethering)

WTF that can’t be right. Do better, AI.

In cleartext:

This script will disable ALL firewall rules

1 Like
4

Honestly, it is not the AI’s fault. It is the material it is being trained with that is generated by people who have no idea what they’re doing or talking about. The crucial part here is to have someone with experience to go through the results properly. As you’ve started to do, thank you.

I’ll write a note here next week when back on my desk again.

1 Like
5

Umm, is this an AI analysis or self investigated? There are so many concepts off in this that the text here is, to say the least, misleading. I’ll write more next week but:

  • CLAT implementation supports tethering, and tethering is IPv4 only because of ConnMan not having proper IPv6 implementation (relies on kernel)
  • There is no hotspot daemon per se. Kernel, wpa_supplicant and ConnMan do things together.
  • DNS now is handled by, and requests are forwarded to, systemd-resolved. If there are some prefix issues to fix, we can do those of course.
  • CLAT implementation may have bugs as there is no upstream for it - we are the upstream in this case, so maybe it needs to be looked at after the Jolla Phone gets released.

EDIT: AI’s tend to hallucinate things, in Finnish there is a saying about fire “tuli on hyvä renki, mutta huono isäntä” (Fire is a good servant but a bad master). Just replace tuli/fire with AI.

2 Likes
6

Wait I always thought that was ConnMan’s fault. Are you saying without a presumably newer kernel there won’t be IPv6 tethering even with this script (which, afaics, sidesteps ConnMan)?

7

It is not a fault. It is something that hasn’t been implemented, not even in upstream ConnMan. Tethering is just IPv4 only.

Kernel updates have nothing to do with this. I meant that on IPv6, ConnMan is simply relying kernel to do things correctly. This is a loose referral from the previous maintainer of upstream ConnMan.

In regards CLAT, tethering can be enabled only when CLAT is working, i.e., the plugin/tayga has setup the IPv4 address and can reach ipv4only.arpa meaning that CLAT is working in the network. Then all tethering clients are being routed via the CLAT interface, which routes all traffic over the IPv6 connection.

If that script works, it indeed disregards all what ConnMan does setup. DNS is the only thing that has changed in this regard, now with 5.1 and onwards we use systemd-resolved instead of the internal DNS proxy. It should work similarly as the CLAT plugin does no DNS specific things.

However, if some operators do this differently we should get the logs out to see what is going on there. And now that I looked, tayga development has moved to GitHub - apalrd/tayga: Simple, no-fuss NAT64 for Linux · GitHub and is more active. We could use volunteers to test this as in Finland we have no networks supporting CLAT. I can make a test version of that later, when testing that does it need changes or not.

1 Like
8

Hi all thanks for your thoughts!

If the script can be improved then please make a pull request

If this script can be made really clean, then it’s more obvious to Jolla/SailfishOS devs what limitations this script is working around. If there is a way I can generate a tar.gz from logs from my phone to aid SailfishOS devs. I guess that would be useful