dhcpcd-discuss

> My guess (still debugging) is that the order of events is that on
> connection the ppp device is brought up in a "down" state, dhcpcd starts
> running, but very soon after the interface is brought "up" and ppp
> starts running it's option scripts?  So we have a race?


Hmm, turning up the dhcpcd log level and adding a big of debug in 40-dns.sh, 
I see:

..some pppd negotiation...
Mar  9 22:32:43 localhost daemon.debug pppd[24124]: rcvd [IPCP ConfAck id=0x4 <addr 10.140.80.87> <ms-dns1 10.203.129.70> <ms-dns2 10.203.129.68>]
Mar  9 22:32:43 localhost daemon.warn pppd[24124]: Could not determine remote IP address: defaulting to 10.64.64.65
Mar  9 22:32:43 localhost user.debug dhcpcd[22228]: ppp1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason STATIC
Mar  9 22:32:43 localhost daemon.notice pppd[24124]: local  IP address 10.140.80.87
Mar  9 22:32:43 localhost daemon.notice pppd[24124]: remote IP address 10.64.64.65
Mar  9 22:32:43 localhost daemon.notice pppd[24124]: primary   DNS address 10.203.129.70
Mar  9 22:32:43 localhost daemon.notice pppd[24124]: secondary DNS address 10.203.129.68
Mar  9 22:32:43 localhost daemon.debug pppd[24124]: Script /etc/ppp/ip-up started (pid 24172)
Mar 09 22:32:43 40-dns.sh ran resolvconf using 10.203.129.70 and 10.203.129.68
Mar  9 22:32:43 localhost user.debug dhcpcd[22228]: ppp1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason EXPIRE
Mar  9 22:32:43 localhost user.debug dhcpcd[22228]: ppp1: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason STATIC
Mar  9 22:32:44 localhost daemon.debug pppd[24124]: Script /etc/ppp/ip-up finished (pid 24172), status = 0x0

Need to peer a little more deeply, but I'm assuming it's the "reason EXPIRE" which zaps the resolvconf?

Perhaps I'm being a bit of a twit though... Disabling dhcpcd on this interface also solves the issue since bringing up the interface and managing IP allocation seems adequately handled by pppd...?

Is there something I am missing by not allowing dhcpcd to manage my ppp interfaces?

Thanks

Ed W