Using Jolla2026 as a simple router via IP over USB

General
1

Coming from a FX(tec) pro1 with Sailfish OS 4.x I tried to set up the Jolla 2026 as a router. What I did on the pro1:

  • Enable forwarding: echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
  • Enable masquerading: iptables -t nat -A POSTROUTING -j MASQUERADE

That way I could have a static IPv4 address on the phone and the PC - easy. Now I still can do that and the phone acts as a router. Unfortunatelly the Jolla itself looses the capability to resolve hostnames via DNS. The problem seems to be the MASQUERADE rule. I also tried to do MASQUERADE on any other interface except lo, without success.

I suspect some “systemd magic” is causing the problem.

There is now an alternative called “USB tethering” with downloading another package via pkcon, selecting a different mode instead of developer mode and being forced to use DHCP then. Why must it be so difficult? Is there any advantage regarding cyber security doing it that way? Simple routing worked so fine! It avoided that additional mode.

Could anyone explain to me, why a simple MASQUERADE rule could throw of DNS?

2

What is difficult about that?
I fully expect something that connects me to the Internet to also serve me IP addresses i can use - anything else would be difficult.

3

USB tethering should just be an option in the settings. By default.

1 Like
4

Maybe “difficult” is not the correct term. I want to know, why another peace of software has to be installed and why DNS stops working, when MASQUERADING is active. If nobody can answer this, I’ll have to look st the sources for myself.

Real tethering also didn’t give an IPv6 address, so I wonder, what the advantage of tethering vs. simple routing would be.

2 Likes
5

It is not installed by default because Jolla is not quite happy with the quality. See e.g. lack of ipv6. But apart from that, what is difficult?

With it installed it is just a simple setting in settings.

And i mean difficult with it. That masquerading breaks stuff is nobodys problem but yours.

As i said; DHCP is kind of essential - how are you doing that with your “simple routing”?

6

Hi,

The tethering option is mimicking the share network via USB of Android.
Average user are not expected to understand all the networking stuff.

I still think it should be installed by default, but I also see the wave of bug reports not being wanted.

Adding to the UI with a big beta status could be a solution.

Anyway, last time I asked Jolla :

image
image926×177 12.9 KB

4 Likes
7

Is this a connmann problem?

8

Instead of discussing what’s difficult or not I want to try to answer my own question:

It seems that Sailfish 5 uses systemd-resolved for DNS resolution, while Sailfish 4 used connman. And it turns out, that systemd-resolved doesn’t answer to all IP addresses that send DNS queries. MASQUERADE will modfiy the phones own queries source addresses.

I’ve no idea why a network stack is necessary for local DNS queries, but nowdays that seems to be the case. Maybe it’s necessary for security reasons for the possibly evil apps within the containers? Using a resolver daemon like systemd-resolvd might be necessary to enable DNSSEC.

Using the phone as router and still allow the phones own DNS queries is possible by excluding lo from masquerading:

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
iptables -t nat -A POSTROUTING ! -o lo -j MASQUERADE

However DNS queries from the host via USB get refused, most likely by systemd-resolved. The filter table seems not to filter it. It might be possible to configure somehow, that packets coming from USB should get answered, but I can’t find the motivation to investigate that.

The options now are:

  1. Install additional software to allow USB tethering and live with DHCP
  2. Use plain routing like before and use own DNS resolution
  3. Find out how to convince systemd-resolvd to allow queries from usb0

Any insights how to convince systemd-resolved to allow DNS queries from usb* are very welcome!

9

My question: would your method allow both IPv4 and IPv6 to work on the USB-connected device that uses the phone’s internet?

1 Like
10

No, unfortunately not. For IPv6 it’s more complicated in any case (tethering or routing), because the addressing mechanisms are different. I don’t know what tricks could be played with tethering. With classic routing there are at least the mechanisms SLAAC and DHCPv6 prefix delegation. Both mechanisms require

  1. additional software running on the phone (router advertiser or DHCPv6 server)
  2. and more than a single IPv6 /64 address given to the phone by the provider

At least 2 is quite uncommon as far as I know.

I’d really like to know, how IPv6 tethering could solve that problem! Could this be done by IPv6 NAT? Or does the phone somehow “share” its received IPv6 address with the host connected with USB?

Anyways: The DNS problem most likely is the same. The phone has to accept DNS queries from the host. With the current tethering packet that seems to be solved, so I should have a look into that.

However the solution for IPv6 get’s implemented, the IPv4 solution via simple routing would always work independent from that (dual stack).

1 Like
11

At first you need IP address of phone in USB subnet in /etce/resolv.conf as nameserver.
For WiFi sharing it is:
nameserver 172.28.172.1
This works with DNS server runing at 127.0.0.1 but, most likely, for systemd-resolved you have to forward DNS ports from theter ip to systemd-resolved.
Alternatively you can try DNS-Alternative

12

IPv6

Thanks. Pity.

FWIW, have you considered configuring DNS for the attached device? It might be a good choice privacy-wise anyhow.

1 Like
13

Yes, using classic routing and resolving a localy configured DNS instead of the DNS relay of the phone is the second option in my list above. I don’t know if that is a gain of security. First of all I like the idea that I can trust my Jolla phone :slight_smile: and second I’d have to find a trustworthy DNS server and doing things like DNSSEC for myself.

I’ll eventually pull myself together and try to figure out, how to get the Jolla phone to work as a DNS relay on USB, like it’s doing with the availlable USB tethering mode. And I want to find out, how IPv6 could work without having at least a /62 prefix from the provider on the phone.

14

FWIW, maybe you can try the software from Rob Braxman…

The BraxRouter software (created by Rob Braxman) runs on Raspberry Pi devices and is designed to manage privacy features for both protocols. It includes specific safeguards against IPv6 leaks, ensuring that traffic is routed through the VPN or TOR even when IPv6 is active, preventing direct IPv6 connections that would bypass the privacy tunnel.

The BraxRouter software (created by Rob Braxman) runs on Raspberry Pi devices and is designed to manage privacy features for both protocols. It includes specific safeguards against IPv6 leaks, ensuring that traffic is routed through the VPN or TOR even when IPv6 is active, preventing direct IPv6 connections that would bypass the privacy tunnel

https://rumble.com/v1e8dxy-your-home-privacy-appliance-braxrouter-vpn-tor-router.html

15

I’m one step further: systemd-resolved could listen on additional sockets for DNS queries, so it could act as a DNS relay in a network. By default the phone configures itself the IP 192.168.2.15 on USB after turning on “develper mode” and connecting a host to the USP port of the phone.

I created a new file /etc/systemd/resolved.conf with this content:

[Resolve]
DNSStubListener=yes
DNSStubListenerExtra=192.168.2.15

Restarting with

systemctl restart systemd-resolved

Unfortunately this files doesn’t get used or I missed something else. The phone doesn’t listen on UDP port 53 on IP 192.168.2.15. At least this is what ss tells me:

ss -ulpnt

I opened up the firewall (INPUT), but this is useless until systemd-resolved starts listening on 192.168.2.15:53 first.

Why gets /etc/systemd/resolved.conf ignored? I even tried squeezing the three lines above into another already existing .conf file in that directory - to no avail!

1 Like
16

@jollus Sorry for not replying until now. My goal is to use the phone as a simple router without installing additional software. There is already enough magic going on - just look at “ps”!

17

Could it be that support for DNSStubListenerExtra is not available in the systemd version used?

1 Like
18

@makrolon Wow! When I first read your answer I thought: what a nonsense!

But you are absolutely right! “DNSStubListenerExtra” has been added in systemd verison v247, release on Nov 26, 2020. In SailfishOS 5.2 it’s version v238, released on Mar 5, 2018.

Crazy.

19

I think the version used in SFOS includes fixes and features which have been backported to it by Jolla, so it isn’t always very straightforward to compare it to the upstream version. But with the numbers you quoted it sounds like this mystery was indeed solved.

1 Like
20

I just looked at the release notes for 5.1.0.11 when in their words:

A major part of this update are “just” updates to libraries and components that are not so much directly visible to the average user.

The changelog shows:

systemd - 238+git23-1.15.1.jolla – 238+git26-1.16.3.jolla

  • Tue Oct 14 2025 Pami Ketolainen - 238+git26
    [systemd] Disable DNSSEC by default. JB#63704

  • Fri Apr 11 2025 Jussi Laakkonen - 238+git25
    [systemd] Enable resolved and myhostname in build. JB#63311

  • Fri Jan 31 2025 Matti Lehtimäki - 238+git24
    [systemd] Fix build with gcc 13 and newer. JB#62204

Which gives an insight to the Jenga they play trying to update the stack. The last change came in October, and it wasn’t until May that they were able to actually release it.

1 Like