DNS resolving issue with fixed IP setting (USB network)

Hardware Librem 5
18

OK, I’ve installed dig by using my cellular connection.
I switched back to my USB network connection and tried to use “dig puri.sm”.

purism@pureos:~$ dig puri.sm

; <<>> DiG 9.16.27-Debian <<>> puri.sm
;; global options: +cmd
;; connection timed out; no servers could be reached

Same for:

dig <My DNS IP> +noall +answer ns1.cloudflare.com

The results of ifconfig are:

        enx00e04c1604af: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.50  netmask 255.255.255.0  broadcast 192.168.0.255
        ether 00:e0:4c:16:04:af  txqueuelen 1000  (Ethernet)
        RX packets 56  bytes 3272 (3.1 KiB)
        RX errors 0  dropped 30  overruns 0  frame 0
        TX packets 39  bytes 5240 (5.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 251467  bytes 20371558 (19.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 251467  bytes 20371558 (19.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
19

I guess not. There’s no hard and fast rule. They aren’t essential to operation of the device - so maybe Purism is being more efficient in the use of disk space. For my money they should be installed though.

OK, so did you have an @ sign in front of the IP address?

Can you please be explicit: where are the DNS servers? Are they on your local network? Are they on the internet? Are they public DNS servers (like an ISP’s or Google’s or Cloudflare’s or …) or are they private DNS servers (employer’s or yours on VPSs or …)?

When diagnosing DNS problems … note the trailing dot - a hostname (like puri.sm) should be specified with a trailing dot (puri.sm.). A lot of the time it won’t make any difference but if you know you are having DNS problems, it could make a difference.

Can you confirm that this choice of the two DNS servers does work from other computers on your LAN?

This PC that you mention, is it running Linux or something else?

20

I’ve not used the “@” in front of the IP address.
Have done that now and the results are different:

; <<>> DiG 9.16.27-Debian <<>> @<ISP DNS server> puri.sm.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42654
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;puri.sm.                       IN      A

;; ANSWER SECTION:
puri.sm.                300     IN      A       138.68.253.24

;; Query time: 128 msec
;; SERVER: <>#53(<ISP DNS server>)
;; WHEN: Wed Apr 06 01:13:59 CEST 2022
;; MSG SIZE  rcvd: 52

The DNS servers are the servers from my ISP and they (DNS servers) are not within my network.
The settings work fine for all other computers within my LAN.
As asked, the PC that I’m currently using is a Windows PC.

21

OK then I think the answer is clear. However you managed to configure the DNS server IP addresses into the interface on the Librem 5, it didn’t have the desired effect e.g. doesn’t show up in /etc/resolv.conf

How much troubleshooting do you want to do?

You could take a punt and just edit the DNS server IP addresses into that file - syntax is e.g.
nameserver 1.1.1.1
(repeat such a line for each DNS server IP address)

(when things are working properly or half-working, changes to that file will get wiped out when you reboot but if things are really not working then changes won’t get wiped out)

or you would need to see, at least, whether the systemd-resolved service is starting properly e.g.
systemctl status systemd-resolved

and I would probably check NetworkManager too e.g.
systemctl status NetworkManager

or you could try changing your approach and use DHCP instead. You may have good reasons for wanting to avoid DHCP.

You may want to see whether there is any useful error message in the journal e.g.
journalctl | grep 'Apr 06' | grep enx00e04c1604af

NetworkManager stores settings in files in /etc/NetworkManager/system-connections so you might want to see how many files are in there, whether one obviously associates with your dock’s ethernet connection, and whether it obviously has the right or wrong DNS server IP addresses.

NB: Files in that directory are protected against read access i.e. to examine the content of such a file you would need
sudo cat /etc/NetworkManager/system-connections/whatever.nmconnection

22

Hi Irvinewade,

I’ve added my DNS IP into the file /etc/resolv.conf and tested it without rebooting.
Tested with dnslookup and now name resolution works.
Tested with updating inside Terminal: works
Tested with web-browser: works

Rebooted the L5 and as predicted resolv.conf was set back to it’s original state and content.

Next I checked the journal for error messages (used your command).
This is the output:

Apr 06 12:45:00 MyL5 NetworkManager[2200]: <info>  [1649241900.7589] manager: (enx00e04c1604af): assume: will attempt to assume matching connection 'pine64usb' (1b301fb1-857c-3cdf-b611-46f1c5c90664) (indicated)
Apr 06 12:45:00 MyL5 NetworkManager[2200]: <info>  [1649241900.7612] device (enx00e04c1604af): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume')
Apr 06 12:45:00 MyL5 NetworkManager[2200]: <info>  [1649241900.7804] device (enx00e04c1604af): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'assume')
Apr 06 12:45:00 MyL5 NetworkManager[2200]: <info>  [1649241900.8198] device (enx00e04c1604af): Activation: starting connection 'pine64usb' (1b301fb1-857c-3cdf-b611-46f1c5c90664)
Apr 06 12:45:01 MyL5 NetworkManager[2200]: <info>  [1649241901.9692] device (enx00e04c1604af): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'assume')
Apr 06 12:45:01 MyL5 NetworkManager[2200]: <info>  [1649241901.9750] device (enx00e04c1604af): state change: prepare -> config (reason 'none', sys-iface-state: 'assume')
Apr 06 12:45:01 MyL5 NetworkManager[2200]: <info>  [1649241901.9985] device (enx00e04c1604af): state change: config -> ip-config (reason 'none', sys-iface-state: 'assume')
Apr 06 12:45:02 MyL5 NetworkManager[2200]: <info>  [1649241902.0449] device (enx00e04c1604af): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'assume')
Apr 06 12:45:02 MyL5 NetworkManager[2200]: <info>  [1649241902.2371] device (enx00e04c1604af): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Apr 06 12:45:02 MyL5 NetworkManager[2200]: <info>  [1649241902.2552] device (enx00e04c1604af): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Apr 06 12:45:02 MyL5 NetworkManager[2200]: <info>  [1649241902.3088] policy: set 'pine64usb' (enx00e04c1604af) as default for IPv4 routing and DNS
Apr 06 12:45:02 MyL5 NetworkManager[2200]: <info>  [1649241902.3394] device (enx00e04c1604af): Activation: successful, device activated.
Apr 06 12:45:03 MyL5 NetworkManager[2200]: <warn>  [1649241903.0670] dns-sd-resolved[60f4d4d6218182ed]: send-updates SetLinkDomains@6 failed: GDBus.Error:org.freedesktop.resolve1.LinkBusy: Link enx00e04c1604af is managed.

The last line shows an error but I don’t know what next step I must take to find the cause of that error.
Also, is this error a serious error or can it be discarded?

Anyway, many thanks for your patience and helping me.

Something else I’ve noticed is that the display scale setting is back to 200% after a reboot.
Is this behavior linked to my DNS problem?

23

If you want to override that permanently then follow this post: Updating the system and git push is slow

I personally don’t like any solution involving manual changes to resolv.conf because you don’t get the correct dynamic behaviour. The way it is supposed to work is that when you dock, it will use the DNS servers dynamically associated with that interface, and when you undock, it won’t. When you switch on WiFi, it will go with that. When you switch on cellular, it will go with that. Whatever is on and connected gives you DNS servers and the set of valid DNS servers is maintained dynamically, automatically, behind the scenes.

So you have to
a) use DHCP, and
b) allow resolv.conf to change dynamically, in effect, as interfaces appear and disappear.

This was the whole reason that resolv.conf changed from its original, completely static, config file to something that is in effect dynamic.

For example, on my desktop, which admittedly doesn’t really need dynamic behaviour (unlike a laptop or a phone, both portable devices) … resolv.conf says only and permanently nameserver 127.0.0.53 and systemd-resolved listens on that IP address for DNS requests and it worries about interfaces appearing and disappearing so it knows where to relay DNS requests to.

I don’t know why that isn’t working for you.

Not a serious error. That relates to using DNS for service discovery. Since DNS isn’t really working properly at the moment for you, you won’t be using it for service discovery anyway (and even if DNS were working, I doubt that you need to use it for service discovery).

Unrelated to DNS. It may or may not be a bug. It may be intentional behaviour. Or not. Probably best to search the forum for discussion on that.

24

I’m not a fan either of changing this dynamic process into a static one.
The best solution would be to get the process working as it should.
And do I understand you correctly: The only way making this working is by using DHCP instead of fixed IP? :thinking:

25

This may not be helpful in your situation, but whenever I wanted something to have a fixed IP I went into the router settings and assigned my device a fixed IP there.

26

I’m looking into that now.
For testing purposes I’m setting up DHCP for 1 device and assign it to my L5 dock.
Maybe this will help troubleshooting the issue.

27

Just finished several tests and it seems that when using a static IP with manual DNS server settings, name resolution does not work.
After enabling DHCP on my router, all started working.
Reverting all settings back, name resolution failed.

Odd behavior noticed:
Changing the settings on my L5 from DHCP back to fixed IP and a reboot did kept name resolution working.

After shutting down the DHCP server on my router and rebooting the L5 once again resulted in a not working situation. :roll_eyes:

28

I might be misunderstanding what you’re saying (this isn’t really my wheelhouse) but I never shut down dhcp. I just set the router to assign a specific IP address to my device’s (in my case a pi hole) MAC address.

1 Like
29

That’s OK if you want to use DHCP.
I’ve just used it for testing purposes and my intention is not to use DHCP :wink:

30

@irvinewade
Oh yes, sorry i had not enough time yesterday and i only use sudo two or three times a year.

I’am still waiting for my Phone so i can’t check my suggestions by myself.

shopping4purism, have you access to your LAN DNS-Server Log and can take a look if your Librem drop a Message there, when you try to access? Some Routers with LAN/WLAN Management have “security settings” and will offer DNS-(Forwarding)-Access only if the Clients use DHCP, or be configured as trustworthy static Clients.

Yes irvinewade is right that its bad to change /etc/resolv.conf with static solutions, it can impair dynamic out of the Box Behavior. However i experienced mostly no trouble. It changed back after Flight-mode or reattached the Cable, USB-Modem or reboot and everything was fine. Just in case for a trouble Situation i wrote for every Step the undo/remove command too.

Later, after you found a Solution, it should not be hard to write a small On/Off Script for your Dockingstation usage.

If you have no access to that DNS-Server and stay in a filtered LAN. Maybe DNS over TLS is a solution but try to debug your issue first. I just thought you have no Mobile-Data Connection, just a slow WLAN somewhere and at Home that filtered Internet access like in Hotels but with filtered Internet through DNS.

Edit: When i wrote DNS-Server, its like in the (wrong) Home-User’s linguistic usage, it is mostly a DNS-Forward or DNS-Cache.

31

Hi Christal,
I have no access to the mentioned DNS servers, since they are owned and managed by my ISP, hence I have no access to their logs.

My router does not block DNS queries.
All devices within my LAN are configured with fixed IP and name resolution works fine.
Also, when I use my Pine phone (Mobian OS) with the same dock and same IP setup, there is no problem with name resolution either.

As far as I can conclude at this moment It must be a glitch within the software.

32 
dns-sd-resolved[60f4d4d6218182ed]: send-updates SetLinkDomains@6 failed: GDBus.Error:org.freedesktop.resolve1.LinkBusy: Link enx00e04c1604af is managed

Oh. You do not use a Router or Modem to manage your Line to your Provider? Like a small Raspberry or Router with dnsmasq and a NAT/Script for Routing the IP-Packages from your Network, over that single Line?

Normally in-House LAN, you’ll have that Modem or Router/WLAN Router to set up that Managed Network.

Your error Message i quoted, which you posted 10h before. Describe that your Link was Busy. And could not resolve your DNS-Request.

That’s why i wrote before about DNS-Forward and DNS-Cache.

If you have two Computers (or more Devices) on the same (Internet)-Line, which sending Messages unmanaged, someone got that Links is busy Error. Its just about Time.

Think about, Data Packages are like Trains on a track and if you try to send two together at the same time, (on one Line from two devices) they will crash. The Signals will overlay and the result is trash if sender and receiver did not communicate well.

If you have Trains with light speed, and they are on a X Miles Way to next Station and Y Miles (1, 2, 16, 20…) long. They need some time to arrive. And some time to start. If two Computers send trains on the same Line, and the Device is busy you will drop or Lost Information.

Sometimes like TCP it will request and remanage to re-send Parts. But it may be Bad with to many Trains on the same Line and firing together.

If you set up a Computer/Router/Accesspoint (just one System from your Home) with a fixed IP in your LAN and Providers Net, which will Manage the different Requests from your LAN to your Internet, DNS-Forward and else. I think you will get rid of your issues. Because this Computer route your Network-Requests in the exact timing to transmit 100% of your packages without timing/packages collisions.

I am not sure if i am 100% right but i think it’s logical.

Your Bug will only accrue if two Devices use your Line together and DNS Requests are frequent, if one Web Page ask for 60 Domains to resolve… for example. With more Devices it will get more uncontrolled and unstable.

Edit: Sorry for this Post, i missunderstood the Error-Message. It is usual for that kind of issue, but you wrote that you allready have a Router Use… is there a way that you still have overlaping signals on some network Line?

This one Errormessage can be a artefact.

1 Like
33

Yes and no.

I am suggesting that you try DHCP (which you have now done). I myself use DHCP on everything (well except for DHCP servers and DNS servers).

If you need constant IP addresses then your DHCP server (typically your router) should support that via fixed mappings that you can set up, as @Gavaudan suggests.

If you are worried about a DHCP server outage (not that big a deal if the DHCP server is the router and you only have one router connected to the internet and most of your traffic is with the internet) then you can set the lease time to a high value.

So there isn’t much downside to using DHCP.

I am also suggesting that in this scenario you should be using DHCP. Let’s say that you guarantee never to move the dock outside of your home and let’s say that you guarantee that the dock will remain connected via ethernet to the same LAN with the same config (e.g. same ISP and same ISP config) permanently then OK you could validly choose not to use DHCP. Otherwise you should be using DHCP. (For example, if your ISP changes their DNS servers, the ethernet hub interface will break if you don’t use DHCP.)

For a portable device (Librem 5), you should generally be using DHCP - so that it is plug-and-play, although that doesn’t strictly apply here if you meet the conditions in the previous paragraph.

All that said, it should work even when not using DHCP. (As said above, my DNS server - local - does not use DHCP. Instead the NetworkManager config sets a static IP address and sets a static DNS server IP address i.e. itself in my case, and that does work - using systemd-resolved.)

You should have been examining /etc/resolv.conf in each scenario.

I’ll take that to mean: after enabling DHCP on your router and reconfiguring the hub ethernet interface on the Librem 5 to use DHCP.

Then you are going to have to persevere with troubleshooting and there’s a fair bit that I have suggested you look at that you haven’t reported back here.

Yes, I think there’s some software issue here but it is not clear whether it’s something not installed, or not starting, or not configured correctly.

I would guess that almost everyone is using their Librem 5 with DHCP - so your situation would be uncommon and perhaps not well-tested.

(I don’t have a dock with ethernet but I do have a USB ethernet dongle that when plugged in to my dock gives the dock an ethernet port and hence gives the Librem 5 an ethernet port - and the dongle can of course also be plugged directly into the Librem 5 instead of the dock. Even there I have just put the MAC address of the dongle into the router to give the dongle a constant IP address when the dongle is used at home, and let the Librem 5 therefore use DHCP for that interface.)

1 Like
34

My network doesn’t suffer from congestion. There is enough bandwidth available.
Like Irvinewade mentioned before, it’s most likely an error message following up on previous issues.

35

Indeed, didn’t think of that. Good point :+1:

Yep, it looks like the way to proceed.
I’m going to reread your messages and see it there is something I forgot to report back here.

Nope there isn’t.
DHCP can be a relief, especially in large networks with lot’s of dynamics going on.
However my LAN is very small and static.

For reasons I do not want to discuss I do not use DHCP at my place.
Please do not feel offended. It’s a matter of choice.
The fixed IP setup is offered as an option to use and therefore it should work, same for any other offered option (like DHCP).
Now we have discovered that it doesn’t work as it should we have two choices:

  1. Switch to DHCP and don’t use the not working option.
  2. Find out what’s going wrong and fix it.

Option 2 is the road I would like to follow at the moment.
It’s in my nature to find out what causes the issue and how to fix it (if possible).
Since I’m not too familiar with Linux, I see it as a good occasion to learn more about the OS.

36

Your router/modem should be able to keep logs of the DNS queries, even if the DNS server is located somewhere else, since all traffic goes through it.

If you just want a static IP and want to get this thing working, I’d highly recommend using DHCP but to lease static IPs to specific MAC addresses in your router. Personally I use that solution at home, I find it to be a mix of best of both worlds.

37

I’ve been testing several situations and I may have found what’s going wrong.
It looks like NetworkManager is ignoring the setting for DNS (manual/automatic) and is always using DHCP for receiving the IP of the DNS server(s).
Since there is no DHCP server in my LAN, it writes no DNS server IP in /etc/resolv.conf

Also, when switching to DHCP in the IPv4 dialog, the settings for IPv6 are changed as well.
I have IPv6 set to disable but after switching from a fixed IPv4 to DHCP, IPv6 is set to enabled.
Not a big deal, but that is something I didn’t expect to happen.

In the table below you can see how I’ve been testing.

Test # Fixed IP / DHCP Content resolv.conf Tool used Details Result: OK/NOK
1 Fixed No DNS entry ping ping OK
2 Fixed No DNS entry ping ping NOK
3 Fixed No DNS entry nslookup nslookup NOK
4 Fixed No DNS entry nslookup nslookup NOK
5 Fixed No DNS entry dig @<IP DNS server 1> +answer OK
6 Fixed No DNS entry dig @<IP DNS server 1> +noall +answer OK
7 Fixed No DNS entry dig @<IP DNS server 2> +noall +answer OK
8 Fixed Manual added DNS servers ping ping OK
9 Fixed Manual added DNS servers ping ping OK
10 Fixed Manual added DNS servers nslookup nslookup OK
11 Fixed Manual added DNS servers nslookup nslookup OK
12 Fixed Manual added DNS servers dig " +answer " NOK
DHCP server running. Changed settings on L5 and rebooted (power off and power on) after change (IPv4 is set to DHCP, DNS is set to automatic and Routes is set to automatic)
13 DHCP DNS entry available ping ping OK
14 DHCP DNS entry available ping ping OK
15 DHCP DNS entry available nslookup nslookup OK
16 DHCP DNS entry available nslookup nslookup OK
17 DHCP DNS entry available dig @<IP DNS server 1> +answer OK
18 DHCP DNS entry available dig @<IP DNS server 1> +noall +answer OK
19 DHCP DNS entry available dig " +answer " OK
DHCP server running. Changed settings on L5 and rebooted (power off and power on) after change (IPv4 is set to Fixed, DNS is set to manual and Routes is set to automatic)
20 Fixed DNS entry available ping ping OK
21 Fixed DNS entry available ping ping OK
22 Fixed DNS entry available nslookup nslookup OK
23 Fixed DNS entry available nslookup nslookup OK
24 Fixed DNS entry available dig @<IP DNS server 1> +answer OK
25 Fixed DNS entry available dig @<IP DNS server 1> +noall +answer OK
26 Fixed DNS entry available dig " +answer " OK
Changed settings at DHCP server (DNS entry modified) L5 not rebooted (IPv4 is set to Fixed, DNS is set to manual and Routes is set to automatic)
27 Fixed DNS entry available ping ping OK
28 Fixed DNS entry available ping ping OK
29 Fixed DNS entry available nslookup nslookup OK
30 Fixed DNS entry available nslookup nslookup OK
31 Fixed DNS entry available dig @<IP DNS server 1> +answer OK
32 Fixed DNS entry available dig @<IP DNS server 1> +noall +answer OK
33 Fixed DNS entry available dig " +answer " OK
L5 rebooted, DHCP server left as is (IPv4 is set to Fixed, DNS is set to manual and Routes is set to automatic)
34 Fixed Changed DNS entry available ping ping OK
35 Fixed Changed DNS entry available ping ping OK
36 Fixed Changed DNS entry available nslookup nslookup OK
37 Fixed Changed DNS entry available nslookup nslookup OK
38 Fixed Changed DNS entry available dig @<IP DNS server 1> +answer OK
39 Fixed Changed DNS entry available dig @<IP DNS server 1> +noall +answer OK
40 Fixed Changed DNS entry available dig " +answer " OK
DHCP server shut down, L5 not rebooted (IPv4 is set to Fixed, DNS is set to manual and Routes is set to automatic)
41 Fixed Changed DNS entry available ping ping OK
42 Fixed Changed DNS entry available ping ping OK
43 Fixed Changed DNS entry available nslookup nslookup OK
44 Fixed Changed DNS entry available nslookup nslookup OK
45 Fixed Changed DNS entry available dig @<IP DNS server 1> +answer OK
46 Fixed Changed DNS entry available dig @<IP DNS server 1> +noall +answer OK
47 Fixed Changed DNS entry available dig " +answer " OK
DHCP server state remained down, L5 rebooted (IPv4 is set to Fixed, DNS is set to manual and Routes is set to automatic)
48 Fixed No DNS entry ping ping OK
49 Fixed No DNS entry ping ping NOK
50 Fixed No DNS entry nslookup nslookup NOK
51 Fixed No DNS entry nslookup nslookup NOK
52 Fixed No DNS entry dig @<IP DNS server 1> +answer OK
53 Fixed No DNS entry dig @<IP DNS server 1> +noall +answer OK
54 Fixed No DNS entry dig " +answer " NOK