Comment 20 for bug 1671606
Revision history for this message
| Mercury (warp-spam-launchpad) wrote | #20 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Ryan,
The problem is not that a recent change in resolvconf caused a regression.
The problem with resolvconf is that the upgrade to network-manager exposed an existing bug in resolvconf.
This happens because the new version of network-manager now tells resolvconf that it must only use a specific interface when talking to the name server, and resolvconf was not properly tracking how interfaces were added and removed from the system.
This is most obvious for VPN connections which use an interface for VPN traffic, as that interface will be destroyed and recreated on every VPN connection, triggering the bug in resolvconf. (Setting up the new DNS for the new VPN interface is insufficient to make it happy.)
This can also be triggered on systems that remove and readd interfaces for things like suspend or hibernate.
Redhat documented the bug fairly well when they found it, their bug report on the matter is https:/
The actual patch that needs to be applied is git commit 2675f2061525bc9
There is a separate (but very related) issue, in that some existing VPNs that involve ipsec have one interface for sending traffic and to hold an IP, but the response traffic appears on the interface of the primary internet connection. This is completely broken in the middle of an LTS by this change, and fixing the bug in resolvconf won't help. I'm still trying to sort out the right answer for some of my VPN use cases there.