Summary: | net-dialup/ppp: race between ppp and dhcpcd setting resolver | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | niv <nivw2008> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | alonbl, base-system, darkside, dek.devel, gentoo, net-dialup |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | patch 40-dns.sh in ppp to solve issue |
Description
niv
2011-01-28 11:49:31 UTC
when running xl2tpd -D I see: xl2tpd[17870]: start_pppd: I'm running: xl2tpd[17870]: "/usr/sbin/pppd" xl2tpd[17870]: "passive" xl2tpd[17870]: "nodetach" xl2tpd[17870]: ":" xl2tpd[17870]: "debug" xl2tpd[17870]: "file" xl2tpd[17870]: "/etc/ppp/options.l2tpd.client" so I looked in /etc/ppp/ip-up.d/40-dns.sh and see: if [ -x /sbin/resolvconf ]; then { echo "# Generated by ppp for $1" [ -n "$DNS1" ] && echo "nameserver $DNS1" [ -n "$DNS2" ] && echo "nameserver $DNS2" } | /sbin/resolvconf -a "$1" echo "40-dns.sh ran resolvconf using $DNS1 and $DNS2" >>/var/log/messag so the question now is , under what circumstance wont DNS1 and 2 be set Created attachment 262059 [details, diff]
patch 40-dns.sh in ppp to solve issue
seems that we need to wait 2 seconds before adding ppp0 to openresolv.
I came up with a general solution that loops until the device is added, or timeout (/20 sec) is reached
I think the problem is actually a race between dhcpcd and ppp? I see the same problem but debugging closer I see that 40-dns.sh *is* correctly updating openresolv, however, a few ticks later, dhcpcd deletes the new resolv.conf configuration.... The chain appears to be /lib/dhcpcd/dhcpcd-run-hooks calls /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf, which in turn runs this code: elif $if_down; then remove_resolv_conf I haven't debugged enough to see why it's calling the if_down option though. Perhaps what happens is that the ppp interface is initially created "down" and then brought up later? In any case the issue is that 40-dns.sh is getting run while dhcpcd is still sorting itself out and settling My process list looks something like: RUSER PID PPID PGID COMMAND root 1817 1 1817 /sbin/dhcpcd -q root 20241 1 20241 /usr/sbin/pppd /dev/ttyUSB2 unit 1 linkname ppp1 defaultmetric 4013 maxfail 0 persist file /etc/ppp/options.ppp1 root 20290 1817 1817 /bin/sh /lib/dhcpcd/dhcpcd-run-hooks root 20291 20241 20291 /bin/sh /etc/ppp/ip-up ppp1 /dev/ttyUSB2 921600 4.3.2.1 1.2.3.4 root 20293 20291 20291 /bin/sh /sbin/resolvconf -a ppp1 root 20294 20290 1817 /bin/sh /sbin/resolvconf -d ppp1 -f I'm not sure what is the best solution here. We obviously need to somehow delay the openresolv stuff until dhcpcd has settled? There is presumably some way to monitor the what dhcpcd is doing other than checking for processess? Any ideas? Hmm, solutions seem to be: - Don't run dhcpcd on ppp interfaces - Tell dhcpcd not to run the resolv hook on that interface What seems to happen at least in my case is that pppd is setting an initial IP, then later changing the remote ip. This appears to cause dhcpcd to run twice to bring the interface up and in the middle it does a "down", which erases the resolv stuff you just added in the ppp scripts I have gone for not running dhcpcd on my ppp interfaces at all since I can't see what they are bringing? (In reply to comment #4) > Hmm, solutions seem to be: > > - Don't run dhcpcd on ppp interfaces > - Tell dhcpcd not to run the resolv hook on that interface > > What seems to happen at least in my case is that pppd is setting an initial IP, > then later changing the remote ip. This appears to cause dhcpcd to run twice > to bring the interface up and in the middle it does a "down", which erases the > resolv stuff you just added in the ppp scripts > > I have gone for not running dhcpcd on my ppp interfaces at all since I can't > see what they are bringing? here is how I came across this issue, my setup is this: 1. my pc eth0 is connected to a modem and gets an IP in the internet via my ISP. 2. I then issue a ppp connection to a l2tp server and get a new IP address to the internet. so I can access the internet using two different IP address and gateways. 3. so I can access the ppp dns service or the eth0 dns service. this is why I use openresolv to allow both in the right priority. 4. I use dhcp to establish the IP address on both devices. 5. In case ppp is alive I want it to be the default gateway. otherwise eth0 supplies the default gateway. this is why I use dhcpcd on both. to manage it dynamically and in case ppp drops ,I can still access the pc. Please also see bug #359069 which resolves a problem after a demand dial interface drops I mailed Roy about this on the dhcpcd mailing list and added some extra info there. Basically PPP is being a bit silly and if you debug it, it seems to first add a temp IP, then drop it, then bring up the real IP. This triggers dhcpcd to run three times and the middle run (ip changed) causes it to blank out the resolv.conf info (erasing what you setup in the ppp resolv.conf) I think the best solution is to let PPP handle resolve.conf and disable dhcpcd from trying to handle it *for that interface*. So I think you end up with something like: /etc/dhcpcd.conf: interface ppp0 nohook resolv Arguably this bug can stay open for someone else to look at, but I don't think it can be resolved with a simple code change because it's a fairly large disagreement between how PPP is assigning IP addresses and dhcpcd is reacting on a change of IP address. The workaround above is sufficient, but clearly not clean This should at least get you working? Note: I am unconvinced there are many benefits in running dhcpcd at all on PPP interfaces (on linux)? See Roys answer on his mailing list also? Metrics can be set for the PPP interface using "defaultmetric xxx" Is that dup of bug#400845? Hello net-dialup, I think this is more related to you guys, as it is not specific to openresolv. *** Bug 384883 has been marked as a duplicate of this bug. *** *** Bug 490334 has been marked as a duplicate of this bug. *** |