sys-apps/openrc-0.9.8.1 net-dialup/ppp-2.4.5-r1 net-dns/openresolv-3.4.1 From what I see the ppp ip-up script is working OK, the resolvconf is called with correct settings. But then the net.ppp0 is calling resolv conf again with empty configuration overriding the ppp settings. Result is empty resolv.conf settings. I do see the following in messages, not sure it should be there, after pppd is up: Jan 26 02:21:30 localhost /etc/init.d/net.ppp0[19894]: status: inactive
As far as I know openrc should not call resolvconf in this configuration --- Jan 26 02:34:44 localhost /etc/init.d/net.ppp0[23000]: status: inactive Jan 26 02:34:44 localhost nobody: RESOLV 23004 -a ppp0 Jan 26 02:34:44 localhost nobody: root 23004 23001 0 02:34 ? 00:00:00 /bin/sh /lib64/rc/sh/runscript.sh /etc/init.d/net.ppp0 start Jan 26 02:34:44 localhost nobody: root 23130 23004 0 02:34 ? 00:00:00 /bin/sh /sbin/resolvconf -a ppp0 ---
/etc/conf.d/net --- dns_options="edns0" # large payload rc_need_ppp0="firewall bluetooth" config_ppp0="ppp" link_ppp0="/dev/rfcomm0" username_ppp0='' password_ppp0='' phone_number_ppp0="*99#" pppd_ppp0="noauth defaultroute usepeerdns lock mru 296 mtu 296" ---
The "oldnet" is the *BEST* networking support and configuration among *ALL* Linux distributions! Not sure what the old term means... I know Roy wanted to remove this, but that move was insane.
"newnet" is going away. I only support oldnet. I don't use openresolv however, so you're going to need to dig deeper.
(In reply to comment #4) > "newnet" is going away. I only support oldnet. Good to hear! > I don't use openresolv however, Maybe I miss something... How do you manage DNS change of dhcpcd, ppp, vpn without openresolv? Is there another solution to coordinate between these, keeping system sane? > so you're going to need to dig deeper. Will do.
Hello, Had some time to figure this out, this is not ppp specific issue. The problem is that global DNS options, these without interface suffix are processed for all interfaces, hence if exist override any external configuration put by ppp, dhcp, openvpn etc. Assuming the following /etc/conf.d/resolv.conf --- dns_options="edns0" config_eth0="dhcp" --- Two dns configurations are generated for the same interface, one by openrc and one by dhcpd. openrc (/lib/rc/net/system.sh::_system_dns): --- edns0 --- dhcpd (/lib64/dhcpcd/dhcpcd-hooks/20-resolv.conf): --- nameserver 10.200.0.245 --- Now we have a race between the two, last wins. I am not sure what is a proper fix... maybe merge and not replace. Temporary workaround should be to specify options for the lo interface, this will be added as constant. Setting at global that cause the above behavior. - dns_servers - dns_domain - dns_search - dns_sortlist - dns_options Why didn't we see this until now? I guess because dhcp usually sets dns configuration after openrc sets, so people always got the dhcp configuration. I found this when ppp was used, as the sequence is different, but it applies to all cases. Alon
(In reply to Alon Bar-Lev from comment #6) > Why didn't we see this until now? I ran into this the other day, too, but across different interfaces while using plain old /etc/resolv.conf. I'm quite sure that this didn't happen before (ie, setting dns_domain="something.lan" did not automatically mean starting an iface always overwrote /etc/resolv.conf). I expect this 'race' may be related somehow to the fact that 'net' is no longer provided by 'net.lo' and the global options are provided when 'net' is first started or available...
*** Bug 406139 has been marked as a duplicate of this bug. ***
While reading this I think it could be also an issue with vpnc connections I faced in the past (and cannot say whether they are still present). Here is my observation. Provided I had running connection with whatever DNS values I obtained via DHCP, if I lost a physicial eth link (just pull out the etehrnet cable for more then 5 seconds or so) then my resolv.conf used to be emptied, or at least overwritten by some old backup values from setup before I connected via vpnc. Basically, although vpnc worked after the cable was re-plugged in, the DNS was screwed.
(In reply to Martin Mokrejš from comment #9) > Here is my observation. Provided I had running connection with whatever DNS > values I obtained via DHCP, if I lost a physicial eth link (just pull out > the etehrnet cable for more then 5 seconds or so) then my resolv.conf used > to be emptied, or at least overwritten by some old backup values from setup > before I connected via vpnc. Basically, although vpnc worked after the cable > was re-plugged in, the DNS was screwed. do you have openresolv installed?
(In reply to Alon Bar-Lev from comment #10) > (In reply to Martin Mokrejš from comment #9) > > Here is my observation. Provided I had running connection with whatever DNS > > values I obtained via DHCP, if I lost a physicial eth link (just pull out > > the etehrnet cable for more then 5 seconds or so) then my resolv.conf used > > to be emptied, or at least overwritten by some old backup values from setup > > before I connected via vpnc. Basically, although vpnc worked after the cable > > was re-plugged in, the DNS was screwed. > > do you have openresolv installed? Yes, at the moment version 3.5.6. Ideally I would have to lookup some "emerge --info" output in Gentoo bugzilla from about 2012. I failed to search for the "emerge --info" in Comments. :( While browsing through vpnc bugs I was involved in, let me at least point you to a bug that vpnc did not restore resolv.conf upon its exit (bug #406141), so a different issue. When thinking of teh possible scenarios, maybe of interest is #424529. I think it is easier to tryu to test some setups, I know I have been trying ifplugs and netplugd but as I had no good insight into the net/openrc configuration tool and config file variables, I could not distill much out the of behavior. So, just a clue how to "repeat" at least similar issues.
(In reply to Martin Mokrejš from comment #11) > While browsing through vpnc bugs I was involved in, let me at least point > you to a bug that vpnc did not restore resolv.conf upon its exit (bug > #406141), so a different issue. When thinking of teh possible scenarios, > maybe of interest is #424529. I think it is easier to tryu to test some > setups, I know I have been trying ifplugs and netplugd but as I had no good > insight into the net/openrc configuration tool and config file variables, I > could not distill much out the of behavior. So, just a clue how to "repeat" > at least similar issues. I think this specific bug is with ppp handling.
