Best way to avoid stale resolv.conf with netctl?

cfr · 2017-11-06 01:05:42

What is the best way to avoid stale /etc/resolv.conf when using netctl, configured to automatically switch between multiple wireless networks, as well as wired? This is a laptop, so I frequently put the laptop to sleep on one WIFI network and wake it on another. Generally, this works. However, the contents of /etc/resolv.conf is not updated. This can cause mysterious issues. For example, I couldn't resolve names earlier because both name servers listed in resolv.conf underwent existence failures, despite the fact that my current DHCP lease specified an existent name server which would have worked just fine. But, even when this is not the case, I assume that it would be better if the information in /etc/resolv.conf was correct for the current network.

I know that I could specify DHCPReleaseOnStop=yes to let the current lease go when the active profile is stopped. However, I know that destroying DHCP leases is not recommended as a routine, so this doesn't seem like an optimal solution.

There was some somewhat related discussion in another thread which I tracked down and have managed to lose. However, the advice there seemed to be not to use netctl and to rely solely on dhcpd. I don't think that would work well in my case, given that I'm roaming WIFI networks, some of which have quite complex. In any case, I've found dhcpd not to agree with eduroam, so I'm not actually using it at all, but instead specifying dhclient.

It is not that I can't solve the problem when this happens. It is rather that I'd prefer to handle the situation automatically. What I did in this case was deleted the DHCP lease file and restarted 4 or so netctl systemd units. This got me a fresh resolv.conf, with information for my current network.

I think it might also work to enable the netctl-sleep. service. As I understand it, this would stop all profiles on sleep and restart them on waking. I'm not sure whether this would clear the resolv.conf or not. This feels (I don't know) somewhat less heavy handed than using DHCPReleaseOnStop, but still seems something of a sledge hammer to crack a nut, albeit a more moderately-sized instance of the sledge hammer kind.

Currently, I have only netctl-auto@wlan0.service and netctl-ifplugd@eth0.service explicitly enabled. netctl.service and so on are then brought in implicitly. But I'm not currently enabling netctl-sleep.service. Should this be enabled on a laptop?

Sample netctl profiles:

# profile 1
Description='MySSID'
Interface=wlan0
Connection=wireless
Security=wpa
IP=dhcp
ESSID='MySSID'
Key=\"....

# profile 2
Description='Uni'
Interface=wlan0
Connection=wireless
Security=wpa-configsection
IP=dhcp
WPAConfigSection=(
    'ssid="eduroam"'
    'scan_ssid=1'
    'proto=WPA WPA2'
    'key_mgmt=WPA-EAP'
    'eap=PEAP'
    'group=CCMP'
    'pairwise=CCMP'
    'anonymous_identity="anonymous@uni.edu"'
    'identity="me@uni.edu"'
    'password=...'
    'phase2="auth=MSCHAPV2"'
)

interfaces/eth0 and interfaces/wlan0 both contain

DHCPClient='dhclient'

as eduroam seems to like dhclient better than dhcpd. resolvconf.conf contains

# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details

resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
#name_servers=127.0.0.1

nsswitch.conf:

# Begin /etc/nsswitch.conf

passwd: compat mymachines systemd
group: compat mymachines systemd
shadow: compat

publickey: files

hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname mdns4
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

# End /etc/nsswitch.conf

Is there a good solution to this problem? Or are all the options less than ideal in one way or another? My impression is: it's all swings and roundabouts whichever way you go. But I'm not sure I've fully understood everything I've read.

lo1 · 2017-11-06 01:36:50

I guess you'd need a scripted hook that triggers a DHCP lease (and thus updates the resolve.conf) only if the SSID or the gateway are different than the ones before stopping the profile.
I'm not into writing scripts yet but this seems very simple to do.
This could save you from unnecessarily destroying DHCP leases if staying in the same network, while forcing it in only when you'd need it anyway.

cfr · 2017-11-06 04:40:52

lo1 wrote:

I guess you'd need a scripted hook that triggers a DHCP lease (and thus updates the resolve.conf) only if the SSID or the gateway are different than the ones before stopping the profile.
I'm not into writing scripts yet but this seems very simple to do.
This could save you from unnecessarily destroying DHCP leases if staying in the same network, while forcing it in only when you'd need it anyway.

It would be nicer if it could be done without releasing the DHCP lease i.e. updating resolv.conf without destroying the leases. In these cases, resolv.conf needs updating, but the lease file is usually fine. (It includes the correct information for resolv.conf - it just doesn't get into resolv.conf.)

Also, any such trigger would have to run later. The point when the profile is stopped is presumably prior to the point when the information for the new SSID becomes available. I don't know quite how the stopping/starting works, but the update needs to happen, if necessary, after waking the laptop. If it happens before sleeping, the machine will still be on the original network.

Have I understood correctly?

nesk · 2017-11-06 08:41:23

cfr wrote:

instead specifying dhclient.

Looking at man dhclient.conf, it seems you can configure it to require stuff from DHCP when accepting a (new) lease:

The require statement
        [ also ] require [ [ option-space . ] option ] [, ... ];
       The require statement lists options that must be sent in order for an offer to be accepted.  Offers that do not contain all the listed options will be ignored.  There is no default require list.
            require name-servers;

Does that help?
Disclaimer: I never used eduroam or netctl.

Last edited by nesk (2017-11-06 08:41:45)

lo1 · 2017-11-06 09:19:32

@nesk's solution is probably the best way to go.

cfr wrote:

The point when the profile is stopped is presumably prior to the point when the information for the new SSID becomes available. I don't know quite how the stopping/starting works, but the update needs to happen, if necessary, after waking the laptop. If it happens before sleeping, the machine will still be on the original network.

That was indeed what i was thinking about, i didn't explain myself very well. You're right, it needs to happen at waking time, then your hook must run your custom script to check if anything has changed. The thing is, if a dhcp lease already happened and the ip address provided is fine, then forcing another dhcp lease just to force update the dns server is a dumb waste of resources.
Especially because nesk's one seems a less dumb solution
In my opinion, this behaviour is either a bug or poor coding choices of netctl dhclient or whatever it's causing this (remember the other post when that guy wasn't able to get an ip address if waking up the laptop while roaming?).
After we'll figure out what works best here, I'd like to file a bug report (or get involved into fixing the code).

Last edited by lo1 (2017-11-06 09:22:24)

rsmarples · 2017-11-06 16:15:38

cfr wrote:

What is the best way to avoid stale /etc/resolv.conf when using netctl, configured to automatically switch between multiple wireless networks, as well as wired? This is a laptop, so I frequently put the laptop to sleep on one WIFI network and wake it on another. Generally, this works. However, the contents of /etc/resolv.conf is not updated.

resolvconf(8) is designed to help with this.
dhcpcd(8) has good support for it out of the box.
I have no idea if netctl does or doesn't, or if other tools you mention support it or not on Arch.

resovlconf takes resolv.conf information from different interfaces and presents a single view in /etc/resolv.conf
So you can safely expire a DHCP lease that's no longer used.

There was some somewhat related discussion in another thread which I tracked down and have managed to lose. However, the advice there seemed to be not to use netctl and to rely solely on dhcpd. I don't think that would work well in my case, given that I'm roaming WIFI networks, some of which have quite complex. In any case, I've found dhcpd not to agree with eduroam, so I'm not actually using it at all, but instead specifying dhclient.

Assuming you meant dhcpcd the DHCP client and not ISC dhcpd the DHCP server I can help with that.
I'd like to as I maintain dhcpcd and I like to have zero bugs

When roaming networks, the kernel should say "interface down" when disassociated and "interface up" when reassociated.
dhcpcd will spot this and you can configure completely different profiles per SSID connected to. It will do this automatically.
How is this failing for you?

When sleeping and resuming, the kernel *should* bring the interface down and up again. If it doesn't do this, dhcpcd won't do anything until the current lease renews (or expires) thus leaving stale data.
If it's not doing that, you can force a renew by issuing

dhcpcd -n

cfr · 2017-11-06 17:16:55

nesk wrote:

cfr wrote:
instead specifying dhclient.
Looking at man dhclient.conf, it seems you can configure it to require stuff from DHCP when accepting a (new) lease:
The require statement
        [ also ] require [ [ option-space . ] option ] [, ... ];
       The require statement lists options that must be sent in order for an offer to be accepted.  Offers that do not contain all the listed options will be ignored.  There is no default require list.
            require name-servers;
Does that help?
Disclaimer: I never used eduroam or netctl.

I don't think this is the problem. I can see the correct information in the dhcp leases file. As I understand it, this means that dhclient is gathering all the required information from the networks. For example, I might have three or four leases, each with the appropriate domans, name servers and so on. The issue is that the contents of resolv.conf does not reflect the currently active lease, even though the lease provides all the information needed to update it.

I've also discovered that the contents of resolv.conf is *sometimes* updated when I've changed networks. But the updating seems to be unreliable or to only happen with particular switches (I need to test some more to determine which of these possibilities).

rsmarples wrote:

resovlconf takes resolv.conf information from different interfaces and presents a single view in /etc/resolv.conf

But the interface is the same almost always. That is, I'm almost always changing from one case where I'm using wlan0 to another case where I'm using wlan0. From what I'd read, resolvconf is designed to be sensitive to the need for different values for different interfaces, but not when different values are needed for the same interface. (I very occasionally use eth0, but this is extremely rare.)

To be honest, I can't remember now what problem switching to dhclient fixed. I think that I have fewer problems with corrupt leases, but I would not want to say for sure this was the problem. As best I remember, with dhcpcd, I could almost never connect out-of-the-box after switching from one network to another with the same SSID, although it worked fine if I switched to a different SSID. With dhclient, this sometimes happens, but much less often. That is, generally, it works fine. Occasionally, I have to delete the lease file. Also, the errors in the journal pinpoint the problem with dhclient, so it was possible to work out what was wrong and do something about it. With dhcpcd, I never got to the bottom of the problem. I'm just guessing that it was probably the same issue I now see occasionally with dhclient. This issue was especially inconvenient because neither restarting the network manager nor rebooting the machine resolved the problem. (This is another reason I suspect I was then seeing the corrupt lease issue.)

Arch Linux

#1 2017-11-06 01:05:42

Best way to avoid stale resolv.conf with netctl?

#2 2017-11-06 01:36:50

Re: Best way to avoid stale resolv.conf with netctl?

#3 2017-11-06 04:40:52

Re: Best way to avoid stale resolv.conf with netctl?

#4 2017-11-06 08:41:23

Re: Best way to avoid stale resolv.conf with netctl?

#5 2017-11-06 09:19:32

Re: Best way to avoid stale resolv.conf with netctl?

#6 2017-11-06 16:15:38

Re: Best way to avoid stale resolv.conf with netctl?

#7 2017-11-06 17:16:55

Re: Best way to avoid stale resolv.conf with netctl?

Board footer