Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#53572 - [netctl] Stale nameservers in resolv.conf

Attached to Project: Arch Linux
Opened by Yuval Adam (yuvadm) - Wednesday, 05 April 2017, 13:35 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 30 November 2018, 05:10 GMT
Task Type General Gripe
Category Arch Projects
Status Closed
Assigned To Jouke Witteveen (jouke)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

When using netctl (v1.12) in some cases, there can remain stale nameservers from previous connections in /etc/resolv.conf.

The following scenario is reproducible for me on a specific corporate network:

# netctl start ethdhcp

$ cat /etc/resolv.conf
domain corp.example.com
nameserver 1.2.3.4
nameserver 5.6.7.8

# netctl stop-all

# netctl start home

$ cat /etc/resolv.conf
domain corp.example.com
nameserver 1.2.3.4
nameserver 5.6.7.8
nameserver 192.168.1.1

In this case, ethdhcp is a copy of the plain example ethernet-dhcp profile, and home is a WPA2 wireless connection.

As you can see, stale nameservers remain in resolv.conf even after disconnecting. This creates unreasonable delays in DNS resolution as two stale IPs have to wait to timeout before reaching the current nameserver.

This bug was discussed at https://bbs.archlinux.org/viewtopic.php?id=224018 and a dhcpcd developer even chimed in, but from all I can understand this is a netctl bug and not an upstream one.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Friday, 30 November 2018, 05:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  The bug mentioned in the comments is somewhat unrelated to the initial report and fixed in bf0a3da1
Comment by Jouke Witteveen (jouke) - Saturday, 08 April 2017, 21:05 GMT
Am I correct in assuming the problem goes away when you add

DHCPReleaseOnStop=yes

to your profile?
Comment by Yuval Adam (yuvadm) - Wednesday, 12 April 2017, 07:41 GMT
Yes, adding that to the profile resolves the problem. Is this expected behavior? I don't see this problem in other networks.
Comment by Jouke Witteveen (jouke) - Saturday, 16 September 2017, 10:06 GMT
netctl merely acts as an interface to dhcpcd in these cases, so I guess this is expected behavior. I do not rule out that not all use cases are covered. If there is something you want to do that is currently not possible with the options netctl provides, let me know!
Comment by KF (kecef) - Sunday, 26 November 2017, 22:54 GMT
  • Field changed: Percent Complete (100% → 0%)
Jouke Witteveen has written [QUOTE]If there is something you want to do that is currently not possible with the options netctl provides, let me know![\QUOTE]
I have the same problem but for diffrent connection type - ppp. It's not IP connection, so DHCPReleaseOnStop=yes does nothing. That option only works on IP connections, but there are more types of connections that get DNS name servers upon connecting, and netctl stop-all doesn't clear /etc/resolv.conf neither delete all files under /run/resolvconf/interfaces
Comment by Jouke Witteveen (jouke) - Monday, 27 November 2017, 08:03 GMT
I assume this is not an issue when you have "UsePeerDNS=false" in your profile configuration? If so, then we should find out whether `netctl` or `pppd` should clean up /etc/resolv.conf when the profile is brought down.
Comment by Jouke Witteveen (jouke) - Monday, 27 November 2017, 08:27 GMT
Scanning through the source of pppd, the bug would be that pppd does not run its ip-down script when it is terminated. Can you verify this?
Comment by KF (kecef) - Monday, 27 November 2017, 13:47 GMT
After using "UsePeerDNS=false" I can't browse internet, because after stopping connections with "netctl stop-all" all content of /etc/resolv.conf is cleared and "UsePeerDNS=false" option doesn't provide new DNS addresses for resolvconf. So /etc/resolv.conf just as /run/resolvconf/interfaces directory remain empty.

I've got this, when disconnecting:
systemd[1]: Stopping Networking for netctl profile ppp-orange...
pppd[5186]: Terminating on signal 15
network[5332]: Stopping network profile 'ppp-orange'...
network[5332]: Stopped network profile 'ppp-orange'
pppd[5186]: Connect time 4.1 minutes.
pppd[5186]: Sent 304 bytes, received 0 bytes.
pppd[5186]: Terminating on signal 15
pppd[5186]: Child process /etc/ppp/ip-down (pid 5338) terminated with signal 15
pppd[5186]: Connection terminated.
pppd[5186]: Exit.
systemd[1]: Stopped Networking for netctl profile ppp-orange.
^
Comment by Jouke Witteveen (jouke) - Monday, 27 November 2017, 13:55 GMT
So the ip-down script is killed. This is indeed a bug. Is it also killed when you manually kill the pppd program, or is it killed by systemd? In the latter case, we should simply wait for the ip-down script to finish after killing pppd.
Comment by KF (kecef) - Monday, 27 November 2017, 14:44 GMT
From journal log it looks like it is the latter. Below is the log after killing pppd manually.

pppd[6224]: Terminating on signal 15
pppd[6224]: Connect time 4.4 minutes.
pppd[6224]: Sent 80 bytes, received 0 bytes.
pppd[6224]: Connection terminated.
pppd[6224]: Exit.
Comment by Jouke Witteveen (jouke) - Monday, 27 November 2017, 14:47 GMT
Is the problem fixed by adding the following after line 70 of /usr/lib/netctl/connections/pppoe?

timeout_wait 1 '[[ ! -f $pidfile ]]'
Comment by KF (kecef) - Monday, 27 November 2017, 15:22 GMT
Yes, that was it. Now everything works as expected. I quickly looked for other shutdown scripts and the same should apply to /usr/lib/netctl/connections/mobile_ppp. I also compared that two files and there are more differences with the exception of modem chat commands in the latter file.

Good work, thank You.
Comment by Jouke Witteveen (jouke) - Monday, 27 November 2017, 15:24 GMT
Yup, I had that file patched locally as well. Thanks for looking and for your quick testing!

Loading...