# [SOLVED] nomultilb & openresolv: resolv.conf not updated

## CleanTestr

This is now Solved on x86 and multilib, which is 'good enough for me'

  (using ppp -dhcp, without dhcp and openresolv)

I'm having some difficulty migrating a 'working' x86 pppd config (without openresolv) to amd64.

[Edit]

I 'like to run' dhcpcd so eth0 and wlan0 (under netplug) can get their info (when available), but I'd rather that ppp0

get its info from the ISP without dhcp.

I'm using:

net-dns/openresolv-3.3.4

net-dialup/ppp-2.4.5-r3  USE="ipv6 pam -activefilter -atm -dhcp -eap-tls -gtk -radius"

net-misc/dhcpcd-5.6.4  USE="zeroconf"

This combo will 'always' work under x86/desktop for any number of connect attempts per booted session.

Working around an issue in amd64, I've arrived at 

```
ln -s /etc/ppp/resolv.conf /etc/resolv.conf

```

to 'use the same config for x86 as for amd64'.. but it seems kludge-y

[/Edit]

It initially seemed to me that somehow the dhcpcd -- which I'm running, so that it may field eth0 and wlan0 

requests -- (dhcpcd, which, according to what I read on the ppp man page, installs itself as a plug-in to ppp), 

was getting an empty list of DNS nodes from the system, almost as though it were getting a -1 back

from glibc.

I traced the code back to statements in glib-2.17 about converting to Linux NetLink (architecture),

where the actuall API entry-point called by dhcpcd appears to be marked __hidden(..) __asm__ static int getifaddrs(..)

in the code, and the non-NetLink API 'function' is stubbed-out, with merely a set __errno( ENOSYS ); return -1; in its body.

That part of the discussion is here : https://forums.gentoo.org/viewtopic-t-962070.html

- - - * * * <snip> a whole bunch of emerge --info and such * * * - - - 

The rest of this group of messages is about why does openresolv behave differently the first

time, than any subsequent invocation?

----------

## lost+found

Hi, maybe this is worth a try:

```
# emerge net-dns/openresolv
```

and/or

/etc/sysctl.conf:

```
net.ipv4.ip_dynaddr = 1
```

```
# echo 1 > /proc/sys/net/ipv4/ip_dynaddr
```

--

Cheers!

----------

## CleanTestr

It seems that 'various packages' may write to resolv.conf (notoriously: resolvconf 

and network_manager; and now also your mention of openresolv).

But it seems to me that this 'new behavior' in dhcpcd.  Or am I missing something?

..from the man page (dhcpcd):

 *Quote:*   

> ..dhcpcd then runs the configuration script which writes DNS information to resolvconf( 8 ), 
> 
> if available, otherwise directly to /etc/resolv.conf.
> 
> 

 

..but, it seems to not be doing so.

Further on in the man page I find:

 *Quote:*   

>  -F, --fqdn fqdn
> 
>              Requests that the DHCP server updates DNS using FQDN..
> 
>              ..dhcpcd itself never does any DNS updates.
> ...

 

I take this to mean, that some program such as pppd must transact the DNS server, rather 

than dhcpcd itself; not, that dhcpcd doesn't write DNS information to resolv.conf.

----------

## Sven Vermeulen

dhcpcd does write into resolv.conf, it doesn't do DNS updates. Those are two different things.

resolv.conf tells the system where the DNS servers are that the system should consult if a hostname needs to be resolved to an IP address (or vice-versa).

DNS updates themselves tell that an IP address a.b.c.d is for host "foobar" (and much, much more). What the manpage says is that dhcpcd (DHCP client) does not do DNS updates (i.e. changing the database where all that data is stored).

----------

## CleanTestr

I've now observed this to happen also in

keyworded: ~amd64 dhcpcd-5.6.8

It may possibly have something to do with dhcp preserving state across

subsequent invocations, and not re-acquiring DNS information.

I tend to killall ppp to take the link down; after that command, I tend to see

this problem more often.

I haven't tried lost+found's suggestions, as yet.

----------

## CleanTestr

This does indeed have something to do with dhcpcd preserving state:

When I first invoke pppd call <something>, I get 3 processes running:

  - pppd

  - pppob (the pts virtual terminal)

  - dhcpcd -q

If I then killall pppd pppob dhcpcd, then a subsequent pppd call <something>, 

produces 2 processes running:

  - pppd

  - pppob (the pts virtual terminal)

and everything Works!

But if I don't kill dhcpcd (which I wasn't doing, since the Dawn of Time), 

I observe the above failure.

to lost+found:

```
/proc/sys/net/ipv4/ip_dynaddr = 0
```

in /etc/sysctl.conf:

```
#net.ipv4.ip_dynaddr = 0
```

----------

## CleanTestr

Furthermore, if I, in the middle of a pppd session, then dhcpcd -q &, 

dhcpcd starts running, and trashes resolv.conf. Yee-Haw!   :Smile: 

----------

## UberLord

You've not read what others have said and I'm the dhcpcd and openresolv author so please listen.

The default behavior of dhcpcd is to re-write resolv.conf each time a network event happens, such as obtaining or renewing a DHCP lease.

The default behavior of pppd is to re-write resolv.conf each time a network event happens, such as obtaining a PPP address.

This is not new behavior and has been a long standing default of nearly every nix based system since inception.

You indicate you've worked around this by editing /etc/dhcpcd.conf.tail, but your debug output shows otherwise. I suggest it may have been over-written in an update maybe?

I also suggest you emerge openresolv, a working resolvconf implementation specifically designed to solve the above problem in a standard way.

----------

## CleanTestr

Ok.  I'll try using openresolv.

If I:

```
boot

pppd call isp

```

then cat /etc/resolv.conf:

```
# Generated by resolvconf

search my_domain

nameserver ...

nameserver ...

```

and resolvconf -l:

```
# resolv.conf from lo

# Generated by net-scripts for interface lo

domain my_domain

# resolv.conf from ppp0

# Generated by ppp for ppp0

nameserver ...

nameserver ...

```

* Good! *, I *like* ...

If I now

```
killall pppd

```

and wait a bit, then

```
pppd call isp

cat /etc/resolv.conf

```

shows

```
# Generated by resolvconf

search my_domain

```

and resolvconf -l:

```
# resolv.conf from lo

# Generated by net-scripts for interface lo

domain my_domain

```

So, no dice  :Sad: 

----------

