# [SOLVED] amd64: dhcpcd not merging /ppp/peers/resolv.conf

## CleanTestr

I'm trying to use an 'identical' configuration set-up betwixt x86 and amd64.

[Ongoing Edit..]

USE="-dhcp" emerge ppp allows a config common between x86 and hardened multi-lib x86_64.

2013-08: no-mulitlib and hardened no-multilib still no such luck

[tidE]

using ppp-2.4.5-r3 and dhcpcd-2.5.4

I should explain in advance, that I 'tend' to build my system from a stage3, with additional

software to make a stage4 without Xorg, then tar-ball it; then add Xorg, and tar-ball that.

These x86 and amd64 were 'made' that way (as stage4) so it is 'unlikely' that they have

configuration differences (other than customization to my domain, window-manager, and

x86- vs amd64-specific make.conf, and so on).

with usepeerdns, 

  in x86, the /etc/ppp/peers/resolv.conf is properly merged into the /etc/resolv.conf.

  in amd64, it is not merged properly (the dns information is missing; .head and .tail are merged).

both ebuilds are installing identically-sized configuration files (but of course the amd64 binaries are

slightly larger).

I've tried installing resolvconf, but it doesn't change the behavior.

----------

## UberLord

With resolvconf you can see all the received information like so

```
resolvconf -l
```

So if either DHCP or PPP DNS is missing then that is at fault at start looking there.

----------

## CleanTestr

output of (on hardened/no-multilib):

```
shutdown -r now

pppd call isp

resolvconf -l

```

```
# resolv.conf from lo

# Generated by net-scripts for interface lo

domain my_domain

```

contents of /etc/ppp/resolv.conf:

  nameserver ...

  nameserver ...

I'll boot back to x86 and modify this with the x86 results...

output of (on x86-desktop):

```
shutdown -r now

pppd call isp

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 ...

```

contents of /etc/ppp/resolv.conf:

  nameserver ...

  nameserver ...

* * *

I'm looking at a file called /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf...

... wondering what provides 'list_interfaces'...

If I execute (on amd64):

```
shutdown -r now

pppd call isp

resolvconf -a ppp0 /etc/ppp/resolv.conf

resolvconf -l

```

I get:

```
# resolv.conf from lo

# Generated by net-scripts for interface lo

domain my_domain

# resolv.conf from ppp0

nameserver ...

nameserver ...

```

...which is *almost* the same, but not quite.  :Sad: 

----------

## CleanTestr

on amd64:

From dhcpcd's install, in /lib/dhcpcd/dhcpcd-run-hooks, I see:

```
state_dir=/var/run/dhcpcd
```

and from /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf, I see:

```
resolv_conf_dir="$state_dir/resolv.conf"
```

Now, after boot, pppd, in /var/run/dhcpcd/, I find:

```
ntp.conf
```

(which is a directory, which is empty), only.

Which is the same in x86.

Now, /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf contains the line:

```
local cf="$state_dir/resolv.conf.$ifname"

..

# Build a list of interfaces

interfaces=$(list_interfaces "$resolv_conf_dir")

# Build the resolv.conf

if [ -n "$interfaces" ]; then

..

fi

..

# Assemble resolv.conf using our head and tail files

..

printf %s "$domain$search$servers" >> "$cf"

```

All 3 of these ($domain $search $servers) are key-pair lookups in $interfaces, which is

'built' by list_interfaces, which is in /lib/dhcpcd/dhcpcd-run-hooks.  Basically

it iterates on interface_order, which seems to be supplied by dhcp.c.

In dhcpcd.h:

```
extern struct interface *ifaces;
```

,

which is filled in by net.c : discover_interfaces, which calls 

/usr/include/ifaddrs.h : extern int getifaddrs (struct ifaddrs **__ifap) __THROW;

very properly 'filling in' the '&struct ifaddrs' passed to it, or returning -1 on error (my guess).

In glibc-2.17/inet/ifaddrs.c

```
/* Create a linked list of `struct ifaddrs' structures, one for each

   network interface on the host machine.  If successful, store the

   list in *IFAP and return 0.  On errors, return -1 and set `errno'.  */

int 

getifaddrs (struct ifaddrs **ifap)

{

  __set_errno (ENOSYS);

  return -1;

}

libc_hidden_def (getifaddrs)

stub_warning (getifaddrs)

```

My *BaaD*, for using ~amd64 glibc, to get Mixxx running on Gentoo/hardened/no-multilib     :Wink: 

Soo...

does this mean that dhcpcd *ought* be using the complementary (assumed to exist)

'method that pppd uses' to write /etc/ppp/resolv.conf in order to write /etc/resolv.conf ??

From ppp-2.4.5/pppd/sys-linux.c:

```
Line 1915:  if (ioctl(sock_fd, SIOCGIFCONF, &ifc) < 0) {
```

Following right along...:

 a 'libc_hidden_def' is a:

```
#  define __hidden_ver1(local, internal, name) \

extern __typeof (name) __EI_##name __asm__(__hidden_asmname (#internal)); \

extern __typeof (name) __EI_##name \

   __attribute__((alias (__hidden_asmname (#local))))
```

... so I'm looking for a getifaddrs_internal(..)...

In glibc-2.17/sysdeps/unix/sysv/linux/ifaddrs.c

```
static int

getifaddrs_internal (struct ifaddrs **ifap)

{

  struct netlink_handle nh = { 0, 0, 0, NULL, NULL };

```

And in the glibc-2.17/NEWS: '..have been converted to use the Linux NetLink Api..'

----------

## UberLord

Neither of your two configs have any resolv information obtained via dhcpcd so why are you bringing that into this?

To me it look like pppd is not calling resolvconf to add it's information on one system as you're doing it by hand on the other.

----------

## CleanTestr

@UberLord: Because of this:

cat /etc/resolv.conf

```
# Generated by dhcpcd

# /etc/resolv.conf.head can replace this line

# /etc/resolv.conf.tail can replace this line

```

* * *

What I tried next, is to USE="-dhcp" emerge ppp on both x86 and amd64,

without resolvconf or dhcpcd.

(rename /sbin/resolvconf /sbin/_resolvconf, so the script won't find it)

_resolvconf -l now lists

```
# resolv.conf from lo

# Generated by net-scripts for interface lo

domain my_domain

```

and /etc/resolv.conf contains:

```
nameserver ...

nameserver ...

```

which is what cursory inspection of /etc/ppp/ip-up.d/40-dns.sh would suggest.

For now, I'm going to go with this approach, since it works for me  :Smile: 

The question remains, why is the behavior of pppd different between x86 and amd64 when USE="dhcp"?

----------

