DNS resolving issue with fixed IP setting (USB network)

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?

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.

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:

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.

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.

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:

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

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:

@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.

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.

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

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

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.

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.

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.

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

It (static, non-DHCP config) works for me though on another Linux computer.

I suggest you look in /etc/NetworkManager/system-connections and see how many files there are, what names they have, and whether you can work out which file relates to which interface. (If you have ever used the WiFi then there will be one file named for each SSID that you have associated with. There will be one file named for each carrier that you have connected to via the cellular modem.)

You are interested in the [ipv4] section.

Hi Irvinewade,

There are four files in that folder.
Three of them are for my cellular connection and one is for my wired connection.
The filename of the wired connection is (surprise) Wired connection 1.nmconnection
These are the details:

[ipv4]
address1=192.168.0.50/24,192.168.0.254
dns=185.93.175.43;185.232.98.76;
dns-search=
ignore-auto-dns=true
method=manual

These values are the same as displayed from the settings GUI.

In one of my previous post I’ve confirmed that my Pinephone, as well as a Linux PC and a Windows PC all are working fine with fixed IP settings.

Maybe there is someone willing to test this setup on his or her L5?

Is this what your other devices have in their files? Are they using those same DNS servers?

Yep, same settings.
Those are the IP’s of my ISP.
I’m not sure if they will respond to network request from everybody.

I’ve tested the same with DNS 1.1.1.1
Not OK.

As I mentioned in a previous post: The DNS setting (automatic/manual) is not working.
It always use and expect DHCP to give the DNS IP (see my testing).