DNS Problem - WiFi vs. Mobile

Librem Phones (Librem 5)
1

Hello,

Since the beginning I have struggled a little with the data connections and so far I hadn’t understood why :slight_smile: Now I took the time and understood the error.

When I log into my WiFi, I get the following DNS servers (typical):

nameserver 192.168.0.1
nameserver 127.0.0.53

If I deactivate the WiFi or lose the connection because I leave the house, then I usually never have a data connection and have to deactivate and/or activate “Mobile Data” or “Data Roaming” in the modem settings so that I can can establish a data connection.

By manually activating the data connection, two new DNS servers of the provider have now been added and suddenly I have a data connection.

nameserver 2a01: 860: 0: 300 :: 53
nameserver 2a01: 860: 0: 300 :: 153
nameserver 192.168.0.1
nameserver 127.0.0.53

As far as ok, except for the manual intervention.

But when I connect to my WiFi again, I have an incredibly sluggish DNS resolution, which makes use almost unbearable, since the DNS server in my WiFi should be addressed by the mobile provider - not a good idea.

How can one deactivate the DNS server of Mobile or downgrade in priority?

1 Like
2

I am not an expert on this but I’ll try to help.

One might think to change the of entries in /etc/resold.conf . But I’ve read that the file will be automatically overridden?

Does the L5 use systemd-resolved for DNS? Then I think you can set NIC specific DNS servers. So some for Wifi, some for mobile and some for Ethernet if necessary.

Maybe something like this:

sudo systemd-resolve --interface wlan0 --set-dns  192.168.0.1

I guess there is a manpage for systemd-resolve.

3

I have noticed that too. It isn’t handled correctly yet.

Appears so.

systemctl status systemd-resolved

lists details of the service.

I don’t think that has been a good idea for a long time, long before the Librem 5.

It says “Do not edit.” and it is in any case a symlink.

resolv.conf -> /run/systemd/resolve/resolv.conf

I don’t think this is a DNS problem.

Possible hackaround: Boot up your Librem 5 with the WiFi off and the mobile on (confirm internet access via mobile) - then switch on the WiFi. Then, later on, leave the house. @execrable ?

4

@prolog and @irvinewade thanks for your feedback!

Ok, what could be a solution? In principle, you would have to create and determine a priority for a gateway / connection and this would have to be updated in resolv.conf - depending on the connection.

What irritates me, however, is why does the modem not provide a DNS entry when registering? Why do I have to click a button :)?

Can I possibly enter my own IPv4 and IPv6 DNS servers for all connections and those of the providers are generally ignored ?! I would not like to hand over the DNS requests to a mobile provider - they already know enough :slight_smile:

My gut feeling tells me that Purism has to solve it.

I’m listening to a podcast … as soon as it’s through, I’ll work on the network again

5

My understanding is the 127.0.0.53 is the local dns server running on the phone and you’re querying yourself before that then does lookups against the server(s) your dns server is configured to use. Basically it’s masking part of the DNS settings.

I would expect there to be a way to add (as an example) 1.1.1.1 as a forwarder to your dns server config which should be available and reasonably fast from both wifi and cellular.

With that said, I would expect DHCP to just work and what I’m describing my alleviate the symptom but I don’t think is addressing the root issue.

6

Yes. (Not exclusively what is configured but also what is dynamically selected based on what interfaces are up and what interfaces are down. And only for those clients that bypass the recommended name resolution mechanisms.) Refer man systemd-resolved about the above IP address and how configuration is determined.

It can be useful to diagnose with

resolvectl status

But I don’t see 127.0.0.53 at all on my Librem 5 in /etc/resolv.conf. Just the actual DNS servers provided by the (preferred) link that is up.

Is this amber or byzantium, @execrable?

Undoubtedly but the DNS server would have to be on the internet and prepared to answer general queries from you (but not answer general queries from other people, which may be a security challenge).

I think it’s just not working properly yet.

7

Maybe I’m not fully understanding the issue, but try opening /etc/resolvconf/resolv.conf.d/head in a text editor and adding DNS servers there, like so:

nameserver 1.1.1.1
nameserver 1.0.0.1
8

No, one should absolutely use the data provider provided servers, eg on my mobile connections I would not be surprised if traffic to port 53 is filtered out.
The issue at hand is that resolvd needs tonknow which dns servers to give priority and which to remove, if e.g. the mobile data connection is torn down.

I have never looked into how this works, but does a related issue exist in the purism issue tracker?

9

ok, I added my “own” DNS server IPs under

/etc/resolvconf/resolv.conf.d/head

It works with my private network (wifi) but not with my mobile provider. The mobile provider filters the inquiries - that’s a good project but a different topic :stuck_out_tongue_winking_eye:

So I can’t add my own DNS entries, because otherwise I have an unbelievable DNS latency with mobile connections.

I also find it strange that the mobile connection always needs a “touch” in the settings to set DNS entries.

I think there is still a construction zone … Where can i search for open issues?

https://tracker.pureos.net/
or here

10

It may be that you are running into some sort of routing conflict, or perhaps you’re seeing the effects of DNS caching?

From your description it looks like your WiFi adapter is getting a IPv4 address only? And the modem is getting IPv6 only? If your DNS queries are being cached you may run into an issue where the DNS cache has an IPv4 address but (because WiFi has dropped out, been disabled or just disappeared) the only available route is IPv6 so the address becomes unreachable, toggling mobile data may cause the system to do a fresh lookup rather than pulling from cache? Of course the issue may be presented in the opposite direction if your DNS cache has an IPv6 address but the mobile data disappears and only IPv4 routes are available.

FWIW, routing seems to be handled fine for me, I have configured my APs to serve the phone IPv4 addresses only, and the modem picks up an IPv6 only address from my cellular service. The phone prioritises Wifi with a route metric of 600 vs 700 for cellular. I rarely use WiFi so it may be I’m just not running into the DNS caching problem (if that is the issue at all), I also have the phone setup to use DoH (DNS over HTTPS) which due to how it’s setup probably averts any potential problems from caching.

I haven’t spent much time looking at so I may be incorrect, on the surface it seems that NetworkManager handles all network configuration on the phone so it’s probably not advised to edit resolv.conf directly but rather use NetworkManager, you can set DNS servers on a per connection basis.

You can check the DNS servers for each active connection via nmcli from the terminal…

For WiFi:
nmcli dev show wlan0 | grep DNS

For Cellular:
nmcli dev show cdc-wdm0 | grep DNS

You can also check routes for any conflicts…

For WiFi:
nmcli dev show wlan0 | grep ROUTE

For Cellular:
nmcli dev show cdc-wdm0 | grep ROUTE

The interfaces have to be up for any of the above to give output.

For routing conflicts it may be easier to check the routing tables, from the terminal…

For IPv4:
ip r

For IPv6:
ip -6 r

2 Likes
11

Thank you @Loki ,

the manipulation of the DNS entries was only because of the DNS problem. Configuring DNS individually is another topic. Since the DNS entries for the modem were not set voluntarily and I could not switch between WiFi and modem while surfing, I only started with it :stuck_out_tongue_winking_eye:

Possibly we approach the problem step by step :slight_smile:

After a restart I only have DNS entries for wlan0. If I deactivate WiFi, I have no DNS entries, so it is not possible to route via cdc-wdm0. The return of your commands are empty - at this point…

12

I have setup my phone back to a default networking config and I believe I can achieve a similar setup to yourself in that through WiFi I get an IPv4 address and through the modem I get an IPv6 only address.

I did a couple of quick tests, I performed a series of ping tests with the modem and WiFi in various combinations of states. I wanted to check basic connectivity and as ping gives IP address in it’s output and we are dealing with both IPv4 and IPv6 it also gives me a basic indication on routing, as I’m pinging by server names this would also show any DNS delays. I could also test some expected failure/timeout scenarios.

As WiFi is expected to get priority, I started with modem and mobile data enabled only to check route switching…

With modem enabled, mobile data enabled and WiFi disabled…

:~$ ping ns1.cloudflare.com
PING ns1.cloudflare.com(abby.ns.cloudflare.com (64:ff9b::adf5:3a64)) 56 data bytes
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=1 ttl=55 time=42.8 ms
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=2 ttl=55 time=41.4 ms
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=3 ttl=55 time=38.4 ms
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=4 ttl=55 time=38.8 ms
^C
--- ns1.cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 38.426/40.351/42.785/1.807 ms

You can see that the replies are coming from an IPv6 address as expected.

Then I left modem and mobile data enabled and also enabled WiFi and re-ran ping…

:~$ ping ns1.cloudflare.com
PING ns1.cloudflare.com (173.245.58.100) 56(84) bytes of data.
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=1 ttl=57 time=31.6 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=2 ttl=57 time=28.10 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=3 ttl=57 time=30.2 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=4 ttl=57 time=23.7 ms
^C
--- ns1.cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 23.693/28.593/31.560/2.983 ms

You’ll note the replies are now coming from an IPv4 address, this confirms that WiFi is getting priority. I will also note that when running these tests I am not seeing any delays from initiating the ping to getting a response which suggests that DNS is also working fine.

Then I kept WiFi enabled and modem enabled but disabled mobile data…

:~$ ping ns1.cloudflare.com
PING ns1.cloudflare.com (173.245.58.100) 56(84) bytes of data.
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=1 ttl=57 time=33.4 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=2 ttl=57 time=18.6 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=3 ttl=57 time=40.4 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=4 ttl=57 time=34.10 ms
^C
--- ns1.cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 18.573/31.842/40.419/8.092 ms

Ping functions as expected and replies continue to come from an IPv4 address.

Then I kept WiFi enabled and re-enabled mobile data (I wanted to check that WiFi retained priority and there wasn’t some sort of LTP (Latest Takes Precedence) rule going on)…

:~$ ping ns1.cloudflare.com
PING ns1.cloudflare.com (173.245.58.100) 56(84) bytes of data.
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=1 ttl=57 time=30.4 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=2 ttl=57 time=45.9 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=3 ttl=57 time=39.7 ms
64 bytes from abby.ns.cloudflare.com (173.245.58.100): icmp_seq=4 ttl=57 time=24.10 ms
^C
--- ns1.cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 24.979/35.239/45.883/8.094 ms

Again, ping performs as expected with replies from an IPv4 address.

And finally back to modem enabled, mobile data enabled and WiFi disabled. This would check/confirm that routes are transfered back through modem when WiFi is disbaled/dropped/lost.

:~$ ping ns1.cloudflare.com
PING ns1.cloudflare.com(abby.ns.cloudflare.com (64:ff9b::adf5:3a64)) 56 data bytes
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=1 ttl=55 time=41.8 ms
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=2 ttl=55 time=51.5 ms
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=3 ttl=55 time=40.7 ms
64 bytes from abby.ns.cloudflare.com (64:ff9b::adf5:3a64): icmp_seq=4 ttl=55 time=56.10 ms
^C
--- ns1.cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 40.691/47.748/56.980/6.795 ms

And yes, we are back to ping replies coming from an IPv6 address.

All of this tells me that routing and DNS are functioning correctly at my end.

I then tried to induce failures, with the modem and mobile data enabled and WiFi disabled, I started a ping. With ping running I then enabled WiFi, at this point ping continues to receive replies from an IPv6 address as expected. Then, with ping still running, I disabled mobile data, at this point ping’s output changed to “ping: sendmsg: Network is unreachable” indicating the expected failure. The connection was established on the IPv6 cellular interface, with that interface gone there is no way to route the ping requests.

When the output went to “ping: sendmsg: Network is unreachable” I terminated ping and immediately restarted it, ping came straight back with replies from an IPv4 address.

I also tested this in reverse, i.e. With just WiFi enabled I started a ping and received replies from an IPv4 address, I left ping running and enabled mobile data then disabled WiFi. As expected, when disabling WiFi ping’s output went to “ping: sendmsg: Network is unreachable”. Terminating ping and immediately restarting it has ping come straight back with replies from an IPv6 address.

This all tells me that networking and routing on the phone is pretty solid (for me at least).

13

Tonight or tomorrow I will completely reset the phone.

It is absolutely stable for me to reproduce that I have no DNS entries for my modem after a restart of my phone - I have deactivated WiFi via a kill switch, so that there can be no reason.

14

Sorry, I completely missed this bit of detail first time around. Is it always the case that mobile data connection does not get established when restarting the phone? Or, is it the case most of time or more occasionally?

I have seen that a few times myself but it is very rare. Sometimes, if mobile data does not get established immediately on boot, it will come up after a short period of time (within a minute or so), other times after leaving it for a good few minutes with no change, I have gone in and manually toggled mobile data off/on and that has brought it up but I think I’ve only had to do that 2-3 times so far.

I’ve been fortunate over the years with my exposure to modems in linux networking, things have mostly “just worked” so my troubleshooting knowledge in this area is probably not great. There may be better ways to approach this.

When the phone comes up and no mobile data connection is established, from the terminal you could try…

sudo journalctl -b | grep 'WWAN.*state'

This will check that NetworkManager is aware of the modem and if it thinks it should be brought up or not. This should return some detail including "WWAN enabled by radio killswitch; enabled by state file"

I did run into an issue on one occasion where WiFi would not come up even though the state file appeared to hold correct values. I have no idea why but simply removing the state file then power Off/On the phone and WiFi came back to life. The state file also holds the state of mobile data, it might be worth removing that state file (it gets rebuilt automatically on boot) if for nothing else just ruling it out. The state file lives at /var/lib/NetworkManager/NetworkManager.state

As far as I’m aware, the connection is initialised by ModemManager then handed over to NetworkManager for the actual configuration. You could check the state of the modem with ModemManager via mmcli note that it is “mm” not the usual “nm”

First find your modem…

mmcli --list-modems

You should see some output similar to…
/org/freedesktop/ModemManager1/Modem/7 [QUALCOMM INCORPORATED] 0

You want the number after “Modem/” in the case above it’s 7, with that you can query modem state…

mmcli --modem=7

Substitute 7 with the number you get from from the --list-modems command.

There may be quite a lot of output in which case pipe it through more (use space bar or enter to advance through output)…

mmcli --modem=7 | more

The output should contain a line stating “state: connected” and all going well you should see a line in the output (probably near the end) that starts with “Bearer” this is the APN settings, it should look something similar to "Bearer | dbus path: /org/freedesktop/ModemManager1/Bearer/7". If there is no Bearer line in the output then the modem hasn’t picked up the APN settings.

Keep in mind that if all you wnat is the state, bearer or some other distinct value you can pipe the output through grep e.g. mmcli --modem=7 | grep state and mmcli --modem=7 | grep Bearer will filter output specifically for these terms.

Taking the number after the “Bearer/” (in this case 7) you can then check the status of the network…

mmcli --modem=7 --bearer=7

Again, substituting the numbers 7 with those from your own output, this should show the state of the network connection and details of IPs, gateways, DNS etc,. You should also see a "Status | connected:" line in the output, hopefully with “Yes” on the end. The output will be a lot so you may wish to pipe through more again.

I would think that when the mobile data connection does not come up automatically that the output of the above commands may help point to where in the chain things are not going according to plan.

15

I had some time to spare and curiosity got the better of me so I looked at this a little more.

I did manage to get my phone into a state where the cellular modem was connected, the settings app showed mobile data to be enabled but there was no connectivity. I have no idea how representative of your issue it was but the symptoms were the same or at least very similar.

The short version, the details in the data bearer indicated that there was an attempt to bring up the data interface but for some reason was unsuccessful. I noticed that the system then retries after some random period of time. The interface always comes up on the first retry (second attempt), for me at least.

The random time period between retries seems to be anywhere from ~10 seconds through to several minutes. I didn’t pay too much attention to exact timings but on a couple of occasions it seemed to be upwards of 5 minutes before retrying. You can however kick it into action earlier either by toggling the mobile data option in settings or via nm.

I’d guess there is some timing issue between phone and cellular provider that causes something to get ahead of itself during initialisation.

NetworkManager logs interface state changes to the journal, there may be more detail in there if the notion to investigate further takes you.

1 Like