# dhcpcd update to 4.0.1-r1: creates empty resolv.conf

## drphibes

After the recent upgrade from dhcpcd 3.2.3 to 4.0.1-r1, I notice my /etc/resolv.conf file is created with no data.

I run a local dns using net-dns/djbdns (dnscache).  dhcpcd 3.2.3 created the proper nameserver entry, but 4.0.1-r1 does not.  

A downgrade to dhcpcd 3.2.3 fixes the issue.  Anyone know what's going on there?

----------

## UberLord

https://bugs.gentoo.org/show_bug.cgi?id=239098

----------

## andip

less than impressive maintanance of this package i must say. been in unstable for months, and it's still buggy when it hits portage.

----------

## UberLord

 *andip wrote:*   

> less than impressive maintanance of this package i must say. been in unstable for months, and it's still buggy when it hits portage.

 

So you were like helping out the community by extensively testing packages marked unstable or are you just an armchair critic happy to bad-mouth volunteer work?

You'll also notice that it's been fixed fairly promptly, dhcpcd-4.0.2 with the fix is now in portage.

----------

## Vrenn

4.0.2 just hit the portage, I tested it and ist fails like 4.0.1-r1:

```
eth0: dhcpcd 4.0.2 starting

eth0: broadcasting for a lease

eth0: offered 192.168.0.8 from 192.168.0.1

eth0: checking 192.168.0.8 is available on attached networks

eth0: timed out                                                                                    [ !! ]

 *     Trying fallback configuration

```

getting back to dhcpcd 3 again  :Sad: 

----------

## UberLord

 *Vrenn wrote:*   

> 4.0.2 just hit the portage, I tested it and ist fails like 4.0.1-r1:
> 
> ```
> eth0: dhcpcd 4.0.2 starting
> 
> ...

 

What's wrong with that?

Try disabling ARP or increasing the timeout, or both.

```
dhcpcd_eth0="-A -t 60"
```

----------

## Vrenn

Thanks, that worked, dhcpcd4 needes a longer time I believe.

----------

## staffan

 *Vrenn wrote:*   

> Thanks, that worked, dhcpcd4 needes a longer time I believe.

 

Strangely enough, it didn't work here. I downgraded to 3.2.3 but I still have an empty resolv.conf. Did version 4 get mad at being uninstalled and added a write protect to the file?   :Smile: 

Seriously, though, becuase this used to "just work" <tm> I haven't studied networking very hard. I had hoped that a downgrade and reboot would solve it but, alas, it didn't. I'm probably missing something obvious but there seems to be no clear way to make the system rewrite resolv.conf. According to the man page, dhcpcd should do this automatically but in my case, it doesn't.

I'm on a windows box right now and I know even less about networking on windows so if there is a way to get the address of the nameserver from windows, I can try to add it manually but I haven't been able to find anything here either.

Thanks in advance.

Edit:

Never mind... I did a:

```
/etc/init.d/net.eth0 stop
```

followed by:

```
dhcpcd eth0
```

I found a post suggesting something like this. Granted, I have no idea why it works but it did.  :Smile: 

----------

## drphibes

I think what happens is that baselayout creates the /etc/resolv.conf file from your /etc/conf.d/net 

settings and dhcpcd has to be told not to alter it by using dhcp_eth0="nodns" which baselayout 

translates into flags:

```
dhcpcd -R eth0 ...
```

For dhcpcd4 to understand what -R means (usage flags changed for v4), you need to emerge dhcpcd 

with USE=compat.  If you don't use compat or don't use dhcp_eth0="nodns", dhcpcd4 runs

```
/lib/dhcpcd/dhcpcd-hooks/20-resolv.conf
```

to try and build /etc/resolv.conf from its config file (something you probably want to avoid with Gentoo).

----------

## pdr

I got the error with 4.01-r<whatever> and unmaked 4.02-whatever, and both timed out seeing if my good received IP was in use on the network. Had to revert to 3.2.3.

----------

## epsilon72

I'm having major problems with 4.0.* as well.  3.2.3 works fine for me.  This is with my wireless connection.

I'll try adding those options mentioned above tomorrow to see if it works.

EDIT: nope, didn't work.

Always gets stuck on one of the steps, usually "waiting for carrier".  A lot like what pdr above is saying, except a lot of the time it won't even get to the step that he mentioned. (good to know I'm not the only one...)

3.2.3 has absolutely no problems with the exact same configuration.

What has been changed in 4.0.* to cause these problems?

----------

## UberLord

 *pdr wrote:*   

> I got the error with 4.01-r<whatever> and unmaked 4.02-whatever, and both timed out seeing if my good received IP was in use on the network. Had to revert to 3.2.3.

 

So increase the default timeout of 30 seconds. Are you running on wireless, or just a slow DHCP server?

----------

## UberLord

 *epsilon72 wrote:*   

> Always gets stuck on one of the steps, usually "waiting for carrier".  A lot like what pdr above is saying, except a lot of the time it won't even get to the step that he mentioned. (good to know I'm not the only one...)
> 
> 3.2.3 has absolutely no problems with the exact same configuration.
> 
> What has been changed in 4.0.* to cause these problems?

 

dhcpcd-4 got link carrier detection. If it's stalling on this, you need to file a bug so the kernel people can try and fix it.

In the meantime, you can use the -K option so that dhcpcd doesn't use link carrier detection.

----------

## epsilon72

 *UberLord wrote:*   

>  *epsilon72 wrote:*   Always gets stuck on one of the steps, usually "waiting for carrier".  A lot like what pdr above is saying, except a lot of the time it won't even get to the step that he mentioned. (good to know I'm not the only one...)
> 
> 3.2.3 has absolutely no problems with the exact same configuration.
> 
> What has been changed in 4.0.* to cause these problems? 
> ...

 

I'll try that, thanks.  If I needed to, how does one acquire more verbose error output from dhcpcd?

----------

## UberLord

One adds the -d option to acquire more verbose debugging.

Of course, reading the dhcpcd man page could have told you this  :Wink: 

----------

## SirGrant

I'm not exactly sure what is happening.   I lost internet but I fixed it.  Here is what I did.  I booted into my windows partition (which I rarely use) and did ipconfig /all and got the address of the DNS servers.  Then I edited /etc/resolv.conf and just added the line "nameserver xxx.xxx.xxx.xxx" in there.  rebooted and bam it worked.  

Yeah it was kinda bad that it nuked your resolv.conf file though.  It totally knocked out my internet on my gentoo install (no DNS=no internet).  I just feel bad for people who upgraded without another partition so they can't get online at all.  Hopefully they have an ubuntu liveCD or something so they can get help.

----------

## UberLord

@SirGrant - seems like you should either let dhcpcd configure the nameservers or you should write down your hardcoded ones on a piece of paper to refer to. OR better yet, backup your configuration.

----------

## gerard27

Just checked:

I got 4.0.2 installed.

Must have gotten there when I did emerge -uD world.

At boot I noticed a lot of messages about what dhcpd was doing.

However I never lost the contents of resolv.conf. or connection.

I am running mostly x86 stable.

Gerard.

----------

## SirGrant

 *UberLord wrote:*   

> @SirGrant - seems like you should either let dhcpcd configure the nameservers or you should write down your hardcoded ones on a piece of paper to refer to. OR better yet, backup your configuration.

 

Yeah truth is I've been meaning to do this  :Razz: .  I was just going to write a script to automatically do it for me but I haven't gotten around to it unfortunately.  Too much stuff w/ work school and everything else.  I'll try to get around to this ASAP.  Thanks.

----------

## epsilon72

 *UberLord wrote:*   

> One adds the -d option to acquire more verbose debugging.
> 
> Of course, reading the dhcpcd man page could have told you this 

 

Sorry   :Wink:   I did read it, but rather quickly, and was looking for a 'v' for verbose instead...

----------

## aussiemale

Not sure if this is related since I am no dhcpcd expert, but this worked for me.  I commented out

# dhcp_eth0="nodns nontp nonis"

in /etc/conf.d/net and it seemed to fix the problem.

----------

## pdr

For me 4.02 works by adding:

```
dhcpcd_eth0="-K"
```

to /etc/conf.d/net

----------

