# name resolving broken with new baselayout

## mahdi1234

hi,

i know there are quite many post on this topic, but i didn't find any which would help me -

basically my problem is that after update to new baselayout name resolving doesn't work (resolv.conf) not created at all. Lo and eth0 works fine and using directly IP address I'm connected to the net.

```

$ cat /etc/conf.d/net

config_eth0=("dhcp")

dhcpcd_eth0="-HD"

dhcpcd_eth0="-N"

dhcpcd_eth0="-t 5"

```

```

$ equery l dhcp baselayout

[ Searching for package 'baselayout' in all categories among: ]

 * installed packages

[I--] [  ] sys-apps/baselayout-1.12.5 (0)

```

Using dhcpd, even tried update to latest ~ version, but didn't help.

```

$ equery l dhcp

[ Searching for package 'dhcp' in all categories among: ]

 * installed packages

[I--] [ ~] net-misc/dhcpcd-2.0.8-r3 (0)

[I--] [  ] net-misc/udhcp-0.9.9_pre20041216-r3 (0)

```

As I have backup of my old etc folder - when old resolv.conf is copied to /etc name resolving works fine - this is old resolv.conf

```

$ cat /etc/resolv.conf

nameserver 80.83.47.11

nameserver 80.83.47.157

nameserver 80.83.47.10

search abo.net2000.ch

```

How do I make this work out-of-box with new baselayout?

thx,

mahdi

----------

## wynn

You could try this as your /etc/conf.d/net

```
config_eth0=( "dhcp" )

dhcpcd_eth0="-HD -N -t 5"

dns_servers_eth0="80.83.47.11 80.83.47.157 80.83.47.10"

dns_search_eth0="abo.net2000.ch"
```

All gathered from /etc/conf.d/net.example â but you have to be a little familiar with the file   :Very Happy: 

----------

## mahdi1234

Thanks for the tip, unfortunately it didn't solve the problem.

On a generic topic - shouldn't dhcp handle this automatically (at least did previously)?, my machine is laptop, so how this would work if I connect to unknown network (no clue about name servers?).

thx,

mahdi

----------

## wynn

 *Quote:*   

> Thanks for the tip, unfortunately it didn't solve the problem. 

 

Sorry, I thought you wanted the exact resolv.conf preserved.

 *Quote:*   

> shouldn't dhcp handle this automatically (at least did previously)

 Yes, and if you have an empty /etc/conf.d/net it should do everything â however, if you find that dhcpcd is not setting the domainname and hostname and you want to prevent your ntp.conf being overwritten, you will need (as you had before)

```
dhcpcd_eth0="-HD -N
```

If it still doesn't set it up properly, add "-d" to the dhcpcd arguments and it will tell you what it is doing.

You had the timeout set to 5 seconds which may have been too short for the DHCP server to service the request. From the look of it, you are not on a private network and there might be a lot going on.

----------

## mahdi1234

here's the -d output

```

# /etc/init.d/net.eth0 restart

 * Caching service dependencies ...                                       [ ok ]

 * Stopping dnsmasq ...                                                   [ ok ]

 * Unmounting network filesystems ...                                     [ ok ]

 * samba -> stop: smbd ...                                                [ ok ]

 * samba -> stop: nmbd ...                                                [ ok ]

 * Stopping eth0

 *   Bringing down eth0

 *     Stopping dhcpcd on eth0 ...                                        [ ok ]

 *     Shutting down eth0 ...                                             [ ok ]

 * Starting eth0

 *   Bringing up eth0

 *     dhcp

 *       Running dhcpcd ...

Info, MAC address = 00:11:2f:25:46:4a

Debug, broadcasting DHCP_REQUEST for 192.168.0.2

Debug, broadcastAddr option is missing in DHCP server response. Assuming 192.168.0.255

Debug, dhcpIPaddrLeaseTime=4294967295 in DHCP server response.

Debug, dhcpT1value is missing in DHCP server response. Assuming 2147483647 sec

Debug, dhcpT2value is missing in DHCP server response. Assuming 3758096383 sec

Debug, DHCP_ACK received from  (192.168.0.1)

Debug, broadcasting ARPOP_REQUEST for 192.168.0.2

Info, verified 192.168.0.2 address is not in use

Info, your IP address = 192.168.0.2

Debug, sending DNS information to resolvconf

Debug, resolvconf completed

Debug, orig hostname = mahdi

Info, orig domainname = (none)

Debug, your domainname = abo.net2000.ch

Debug, about to exec "/etc/dhcpc/dhcpcd.exe /var/lib/dhcpc/dhcpcd-eth0.i  [ ok ]

 *       eth0 received address 192.168.0.2/24

 * Starting dnsmasq ...                                                   [ ok ]

 * Mounting network filesystems ...                                       [ ok ]

 * samba -> start: smbd ...                                               [ ok ]

 * samba -> start: nmbd ...                                               [ ok ]

```

Is there a way how to debug on this more "Debug, resolvconf completed" - it for sure doesn't create resolv.conf file.

I've also stopped in one of the tries dnsmasq - it has no effect.

PS - I set timeout to 10 sec, but there's only my machine behind router (home router) at the moment, so there's not really traffic.

----------

## wynn

First, to go back a post, my original reply should have had "-R" added to the dhcpcd arguments to stop it overwriting resolv.conf.

The domain abo.net2000.ch looked "work" rather than "home" which was why I assumed a work environment.

According to the code for dhcpcd-2.0.8-r3, if it says "sending DNS information to resolvconf", it will open the file (complaining "dhcpConfig: popen: <error message>" if it can't) and will then write

```
# Generated by dhcpcd for interface eth0

search <search path from DHCP server>

search <domainname from DHCP server>

nameserver w.x.y.z
```

(where the nameserver line is repeated for each nameserver IP address sent by the DHCP server) and then write "resolvconf completed"

I can't see how you can have an empty resolv.conf.

dhcpcd will also save the existing resolv.conf that it finds when it starts running and restore this when it exits. It remains running as long as eth0 is up.

Could you check the DHCP server settings of your router and see what it has for DNS servers? Sometimes it will get these from your ISP connection and sometimes it will act as a DNS server itself.

Otherwise the only workaround is to set 192.168.0.2 as a static address with resolv.conf set up as in the first example.

----------

## mahdi1234

thanks for the help wynn - so far I have identified two workarounds -

a,

 *wynn wrote:*   

> First, to go back a post, my original reply should have had "-R" added to the dhcpcd arguments to stop it overwriting resolv.conf.
> 
> 

 

this works perfectly if you have existing resolv.conf and don't want it to be deleted by dhcpcd. my preferred solution right now.

b,

found that correct lookup table is created - however at wrong location

```

cat /var/run/resolvconf//interfaces/eth0

# Generated by dhcpcd for interface eth0

search abo.net2000.ch

nameserver 80.83.47.11

nameserver 80.83.47.157

nameserver 80.83.47.10

```

so to make it work one need to make symlink (and re-create it with each reboot)

```

ln -s /var/run/resolvconf/interfaces/eth0 /etc/resolv.conf

```

Now one last remaining mystery - at least for me ;) - is there a way how to tell dhcpcd to write its config to etc instead to var? Couldn't find setting like that in man page.

----------

## wynn

As far as I know, dhcpcd will save the existing resolv.conf to /var/run/resolvconf/ but should leave the resolv.conf it has created as /etc/resolv.conf. There is a bit of code which works when /etc/resolv.conf is a symlink but, normally, it is a "regular" file.

Perhaps you can check what's happening by saving the resolv.conf you want to use â you could just rename it to saved-resolv.conf â creating a resolv.conf with a special comment ("#Original resolv.conf" perhaps), running dhcpcd and then looking at /etc/resolv.conf and the saved version in /var/run/resolvconf.

You are running a masked version of dhcpcd, 2.0.5-r1 is the stable version, so there may be bugs in it. One good point though is that there is more debugging output.

If you want to see even more of what's happening, you can add (temporarily) "-DDEBUG" to CFLAGS in /etc/make.conf and emerge dhcpcd again. When it is run, it will show the DHCP response it gets from the router.

[Edit] Note: For anybody who comes after and wants to try adding "-DDEBUG" to CFLAGS.

First, don't change CFLAGS: add "debug" to the USE flags for dhcpcd

```
echo 'net-misc/dhcpcd debug'>>/etc/portage/package.use
```

Second, if you've done this, don't add "-d" to the dhcpcd arguments in /etc/conf.d/net, it will halt the boot after dhcpcd runs. dhcpcd, with --enable-debug and the "-d" flag, no longer runs as a daemon and therefore everything waits until it is finished. It only finishes when the NIC is taken down. If you want to run it with the "-d" argument, run it after logging in.

----------

## mahdi1234

here's the output from debug version dhcpcd

```

# /etc/init.d/net.eth0 start

 * Starting eth0

 *   Bringing up eth0

 *     dhcp

 *       Running dhcpcd ...

Info, MAC address = 00:11:2f:25:46:4a

Debug, broadcasting DHCP_REQUEST for 192.168.0.2

parseDhcpMsgRecv: 8 options received:

i=1   len=4   option = 255.255.255.0

i=3   len=4   option = 192.168.0.1

i=6   len=12  option = 80.83.47.11

i=6   len=12  option = 80.83.47.157

i=6   len=12  option = 80.83.47.10

i=15  len=14  option = "abo.net2000.ch"

i=26  len=2   option = "Ô"

i=51  len=4   option = -1

i=53  len=1   option = 5

i=54  len=4   option = 192.168.0.1

          DhcpMsgRecv->yiaddr  = 192.168.0.2

          DhcpMsgRecv->siaddr  = 0.0.0.0

          DhcpMsgRecv->giaddr  = 0.0.0.0

          DhcpMsgRecv->sname   = ""

          ServerHardwareAddr   = 00.09.5B.D8.B3.AA

Debug, broadcastAddr option is missing in DHCP server response. Assuming 192.168.0.255

Debug, dhcpIPaddrLeaseTime=4294967295 in DHCP server response.

Debug, dhcpT1value is missing in DHCP server response. Assuming 2147483647 sec

Debug, dhcpT2value is missing in DHCP server response. Assuming 3758096383 sec

Debug, DHCP_ACK received from  (192.168.0.1)

Debug, broadcasting ARPOP_REQUEST for 192.168.0.2

Info, verified 192.168.0.2 address is not in use

Info, your IP address = 192.168.0.2

Debug, sending DNS information to resolvconf

Debug, resolvconf completed

Debug, orig hostname = mahdi

Info, orig domainname = abo.net2000.ch

Debug, your domainname = abo.net2000.ch

Debug, about to exec "/etc/dhcpc/dhcpcd.exe /var/lib/dhcpc/dhcpcd-eth0.info up"

```

It finds router and dns servers perfectly, however it creates file in wrong directory - it's again created under /var/run/resolvconf//interfaces/eth0. I will give a try to udhcp if it works any better (tried stable version of dhcpcd and it was same).

----------

## wynn

Before dhcpcd runs, have you got an /etc/resolv.conf? Is it a symbolic link to another file â or to nothing? Does it have permissions which might make it impossible for dhcpcd to overwrite it? /etc isn't readonly, is it?

There must be something stopping it writing to /etc: run here, it creates /etc/resolv.conf and saved the existing one in /etc/resolv.conf-eth0.sv. There is no /var/run/resolvconf created at all.

----------

## mahdi1234

 *Quote:*   

> Before dhcpcd runs, have you got an /etc/resolv.conf? Is it a symbolic link to another file â or to nothing? 
> 
> 

 

I have old resolv.conf which I copy to /etc - it's file on its own no symlink. Though I have tried run dhcpcd on boot without having old resolv.conf and behavior didn't vary.

 *Quote:*   

> Does it have permissions which might make it impossible for dhcpcd to overwrite it? /etc isn't readonly, is it?
> 
> 

 

I don't think this is any problem as either stopping or starting dhcpcd without -R option it renames original /etc/resolv.conf to /etc/resolv.conf-eth0.sv. Once stopped it's back to resolv.conf.

 *Quote:*   

> There must be something stopping it writing to /etc: run here, it creates /etc/resolv.conf and saved the existing one in /etc/resolv.conf-eth0.sv. There is no /var/run/resolvconf created at all.
> 
> 

 

The only file it generates is -

```
cat /var/run/resolvconf/interfaces/eth0

# Generated by dhcpcd for interface eth0

search abo.net2000.ch

nameserver 80.83.47.11

nameserver 80.83.47.157

nameserver 80.83.47.10

```

which is correct but at wrong location.

----------

## wynn

Nope, can't understand it. No further suggestions, I'm afraid   :Sad: 

----------

## depontius

Have you installed "net-dns/resolvconf-gentoo"? There are provisions for it in newer baselayout and dhcpcd releases. It's supposed to assist in generating /etc/resolv.conf in more complex network situations. In particular, I'm hoping to use it in conjunction with dnsmasq to handle DNS with a VPN connection on a machine that's also on a home LAN.

Of course at the moment, I don't even have base funcationality out of resolvconf-gentoo, for some reason. I have an extra script that simply does what resolvonf is supposed to do once eth0 comes up. One of these days...

----------

## mahdi1234

 *Quote:*   

> Have you installed "net-dns/resolvconf-gentoo"? 

 

yes, I have it ...

```
# equery l resolvconf

[ Searching for package 'resolvconf' in all categories among: ]

 * installed packages

[I--] [  ] net-dns/resolvconf-gentoo-1.0 (0)

```

 *Quote:*   

> There are provisions for it in newer baselayout and dhcpcd releases. It's supposed to assist in generating /etc/resolv.conf in more complex network situations. In particular, I'm hoping to use it in conjunction with dnsmasq to handle DNS with a VPN connection on a machine that's also on a home LAN.
> 
> 

 

I'm doing exactly same for making only desired traffic go via tun device and it *works* perfectly. So it's for sure doable ;) ... however still not progressed with the resolv.conf basic problem. Hopefully baselayout 1.13 would fix it once released ;).

----------

## depontius

Prodded by your post, I just put some more time into it.

It still doesn't work correctly.

On the other hand, I now have dnsmasq added into the fray, and have it hooked in correctly, just without resolvconf doing everything right. At the moment, I have another script that forces things to become correct, so it's working well enough. Next I need to add OpenVPN (for home) and my employer-supplied VPN (for work) into the mix, and see if I can get dnsmasq handling that.

----------

