Bug#765356: clobbers resolv.conf
Control: severity -1 important Hi, intrigeri wrote (01 Nov 2014 12:29:34 GMT) : > Daniel Pocock wrote (14 Oct 2014 12:27:52 GMT) : >> I've rated this serious because it makes the network unusable when it >> happens and it requires a user with root privileges to rectify it. > IMO, given the unusual settings in which the problem happens, severity > should rather be important: > a bug which has a major effect on the usability of a package, > without rendering it completely unusable to everyone. > I'll let the maintainers judge, though. Two weeks later, I'm going ahead and downgrading severity. > Indeed, NetworkManager has no way to guess that it should not touch > resolv.conf in this specific case. Your OpenSWAN VPN isn't managed by > NM, is it? > Could you please try checking "Use this connection only for resources > on its network" in the NM settings of your Wi-Fi connection, and see > if it fixes things for you? Also, I think the right way to integrate NM with other tools that want to manage resolv.conf too is to use resolvconf, which NM supposedly supports nowadays. May you please test if this works for you? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765356: clobbers resolv.conf
Control: tag -1 + moreinfo Hi Daniel, Daniel Pocock wrote (14 Oct 2014 12:27:52 GMT) : > I've rated this serious because it makes the network unusable when it > happens and it requires a user with root privileges to rectify it. IMO, given the unusual settings in which the problem happens, severity should rather be important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. I'll let the maintainers judge, though. > NetworkManager successfully connects to a WLAN > Some time after that, I start an OpenSWAN VPN, for example, with "ipsec > start" > The VPN connects and the OpenSWAN log/console output shows something like: > installing DNS server A.B.C.D to /etc/resolv.conf > and then almost immediately afterwards, I see some NetworkManager > entries in daemon.log: > NetworkManager[5219]: Policy set 'SSID-FOOBAR' (wlan0) as default > for IPv4 routing and DNS. > NetworkManager[5219]: Policy set 'SSID-FOOBAR' (wlan0) as default > for IPv6 routing and DNS. > and the OpenSWAN entries from resolv.conf are gone again. > If the VPN is being used for all routing (0.0.0.0/0) then the WLAN DNS > servers may not be accessible any more and so there are no useful DNS > servers in resolv.conf and all DNS requests time out. > Manually adding the VPN DNS back into resolv.conf everything works Indeed, NetworkManager has no way to guess that it should not touch resolv.conf in this specific case. Your OpenSWAN VPN isn't managed by NM, is it? Could you please try checking "Use this connection only for resources on its network" in the NM settings of your Wi-Fi connection, and see if it fixes things for you? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765356: clobbers resolv.conf
Package: network-manager Version: 0.9.4.0-10 Severity: serious I've rated this serious because it makes the network unusable when it happens and it requires a user with root privileges to rectify it. NetworkManager successfully connects to a WLAN Some time after that, I start an OpenSWAN VPN, for example, with "ipsec start" The VPN connects and the OpenSWAN log/console output shows something like: installing DNS server A.B.C.D to /etc/resolv.conf and then almost immediately afterwards, I see some NetworkManager entries in daemon.log: NetworkManager[5219]: Policy set 'SSID-FOOBAR' (wlan0) as default for IPv4 routing and DNS. NetworkManager[5219]: Policy set 'SSID-FOOBAR' (wlan0) as default for IPv6 routing and DNS. and the OpenSWAN entries from resolv.conf are gone again. If the VPN is being used for all routing (0.0.0.0/0) then the WLAN DNS servers may not be accessible any more and so there are no useful DNS servers in resolv.conf and all DNS requests time out. Manually adding the VPN DNS back into resolv.conf everything works -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
