# [SOLVED] DHCPCD runs wihout error, but doesnt give me an IP

## ramin.honary

I am not a UNIX newbie, but I am new to Linux and Gentoo and so far I absolutely hate it.

I have a "New World" PowerBook G4 (about 3 years old), 15 inch, 1.5 GHz CPU, dual-boot Mac OS X, Gentoo on a separate partition.

I am using live-CD 2007.0 for PPC-32 bit machines, and installing from gentoo-source, NOT genkernel.

I read this this thread, I am pretty sure I have the same problem as that guy, but they never talk about whether or not the problem was resolved, and I'm about to put an axe through my comptuer.

All the symptoms match.

I get internet with the LiveCD no problem, and I have a reliable internet connection.

From the LiveCD environment, I copy the /etc/resolv.conf file to the install environment, /mnt/gentoo/etc

I chroot to the install environment and I have internet access.

THEN... I reboot without the LiveCD into my new linux, and DHCP doesn't work, no IP address, no internet.

Pinging a domain name results in a "unknown host" error

Pinging a router like 192.168.1.1 results in a "Network Unreachable" error -- this is the strangest part, what could make the IP address of a router unreachable?

Pinging localhost, or 127.0.0.1 results in a nice steady flow of successful pings (nothing wrong with the deamon)

Instructing dhcp to release eth0 and then renew the lease does nothing, obviously because the network is unreachable

Rebooting into the LiveCD again, copy /etc/resolv.conf to the install environment again, internet works OK.

Renew the dhcp lease from within the install environment -- FAIL. Start using dhcpcd from within the installed environment and it kills or masks off the correct eth0 setup created by the live CD because the dhcpcd thing installed does it's own wrong thing.

The kernel loaded, but DHCP doesn't work. It is a configuration problem.

I don't know how this is supposed to work, my friend suggested that when I compiled the kernel without specifying the correct driver for my ethernet card. I checked my menuconfig file, and it has the network driver and it says I already compiled support for my driver (Sun GEM on a PowerBook G4) into the kernel. For some reason that doesn't work.

From within the installed environment (not the LiveCD) "lspci" says this about my ethernet driver:

```
002:24:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev 80)
```

"dmesg | grep eth0" says:

```

eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:0d:xx:xx:xx:xx (my mac address)

eth0: Found Marvell 88E1101 PHY

eth0: Link is up at 1000 Mbps, full-dpulex.

eth0: Link is up at 1000 Mbps, full-duplex.

eth0: Pause is disabled

```

The liveCD doesn't have support for anything called "Marvell 88E1101", but it does have support for "Sun GEM" and it was enabled when I compiled my kernel.

My only other guess is there is some f**kin config file missing from /etc that should have a line of code written into it to make everything work normally. Which file or what esoteric line of code I must write to make this work? It seems that only satan knows what it would be.

I can't understand how the live CD can be made to handle any kind of network card without any problems on the first try, and yet it the kernel I compiled cannot. What's worse, is if there is a standard driver to use or a standard configuration thing to write, why woudn't it be mentioned in the installation handbook? Why wouldn't it be in the defaults or auto-detected by the "build pmac32_defconfig" on the gentoo-sources?

Any suggestions, anyone?Last edited by ramin.honary on Mon Jul 07, 2008 9:19 am; edited 1 time in total

----------

## ramin.honary

a bit more info:

I re-compiled the kernel with some different drivers and still no go.

When it boots up, I get this:

```

INIT: Entering runlevel: 3

* Starting eth0

*   dhcp

*     Running dhcpd ...

err, eth0: timed out

warn, eth0: using IPV4LL address 169.254.197.43

err, eth0: failed to lookup hostname via DNS: Temporary failure in name resolution

*     eth0 received address 169.254.197.43/16

* Mounting network filesystems ...

* Starting local ...

```

Then a login prompt.

----------

## ramin.honary

Another thing I noticed,

ifconfig reports that the eth0 interface is not only up and running, but is also receiving and transmitting packets from the network.

The driver is definitely not a problem. That can only leave the dhcpcd, which some how isn't properly configured, despite my tweaking tens of variables in network-related etc files.

what the hell? someone help!

----------

## tgurr

Which version of dhcpcd are you using? If you're using a 4.x version try with the current stable 3.2.3 instead. You may also want to try another dhcp client to see if it makes any difference (sometimes it does indeed).

----------

## ramin.honary

I just now updated to version 3.2.3 and it still doesn't work.

It works off of the live-cd, then I chroot, env-update and everything, then emerge the newest version. It downloaded and installed without incident. Then I rebooted and the same old crap happens. I am using another computer right now to post stuff to the internet, so I can give you some debug info pretty soon.

dhcpcd -d eth0

I'll try to get that posted soon here.

----------

## ramin.honary

Yeah, running dhcpcd with debugging doesn't really tell me much.

Perhaps someone here who knows what they are talking about could decipher this for me?

```

info, eth0: dhcpcd 3.2.3 starting

info, eth0: hardware address = 00:xx:xx:xx:xx:xx

info, eth0: DUID = 00:01:00:01:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

info, eth0: broadcasting for a lease

debug, eth0: sending DHCP_DISCOVER with xid 0x75a8dc64

debug, eth0: waiting for 20 seconds

debug, eth0: sending DHCP_DISCOVER with xid 0x75a8dc64

debug, eth0: sending DHCP_DISCOVER with xid 0x75a8dc64

debug, eth0: sending DHCP_DISCOVER with xid 0x75a8dc64

debug, eth0: sending DHCP_DISCOVER with xid 0x75a8dc64

debug, eth0: sending DHCP_DISCOVER with xid 0x75a8dc64

debug, eth0: sending DHCP_DISCOVER with xid 0x75a8dc64

info, eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'

debug, eth0: sending ARP probe #1

debug, eth0: sending ARP probe #2

debug, eth0: sending ARP probe #3

debug, eth0: sending ARP claim #1

debug, eth0: sending ARP claim #2

info, eth0: adding IP address 169.254.138.101/16

debug, eth0: no dns information to write

debug, eth0: Looking up hostname via DNS

debug, eth0: forking to background

info, eth0: exiting

err, eth0: Failed to lookup hostname via DNS: Temporary failure in name resolution

debug, eth0: forking to background

info, eth0: exiting

# And this is what ifconfig reports

# As you can see, it is sending and receiving packets

eth0      Link encap:Ethernet  HWaddr 00:xx:xx:xx:xx:xx  

          inet addr:169.254.138.101  Bcast:169.254.255.255  Mask:255.255.0.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:392 errors:0 dropped:0 overruns:0 frame:0

          TX packets:326 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:92471 (90.3 Kb)  TX bytes:72492 (70.7 Kb)

          Interrupt:41 Base address:0xac00 

```

I should also note that everytime I run "ifconfig", those numbers on "RX packets" and "TX packets" are increasing.

So the network device is active and functioning. I just can't figure out how to make dhcpcd talk to it.

----------

## Ph0eniX

What happens if you manually configure IP settings?

Example:

```

ifconfig inet 192.168.1.181 netmask 255.255.255.0 up

route add default gw 192.168.1.1

```

This assumes that your router is on the 192.168.1.0/24 subnet and its IP is 192.168.1.1 - you may need to modify the settings accordingly.

You should be able to ping the router by IP address at that point.  If this works then you know it's not a driver problem.

----------

## ramin.honary

Interesting...

When I have just freshly started-up the eth0 interface, it seems to work OK, and like I said, it is receiving and transmitting packets. However, when I do a ping to my router (which is at 192.168.3.1), I get a "network is unreachable" error. Then when I manually configure the gateway like you suggested:

```

ifconfig eth0 inet 192.168.3.1 netmask 255.255.255.0 up

```

Now ping is miraculously able to connect to the router, sending back as many packets as I tell it to! Of course, I still don't have a valid IP address, so I can't connect to the internet.

I think it is pretty clear ifconfig is functioning properly. But it may not be configured properly. My guess would be that there is some environment ifconfig variable or /etc config file that dhcpcd wants to read so it can obtain information about eth0, but dhcpcd can't find that ifconfig information so it doesn't connect to eth0. Could someone explain to me what is going on in the background? What does environment information does dhcpcd collect before broadcasting a request.

Another possibility is dhcpcd itself is not configured to communicate using eth0, regardless of what ifconfig has done. I checked the man files, but Gentoo is kind of screwy in that none of the config files mentioned in the dhcpcd man file exist in /etc, so I have no clue how gentoo is supposed to configure this deamon. Or maybe that is the problem, that there are no config files for dhcpcd?

How is dhcpcd configured by gentoo?

----------

## ramin.honary

Also, I don't really want to try another dhcp deamon like dhconfig or whatever. I think if I have a problem like this, I should be able to solve it, and hopefully others in the community can benefit from the conversation we are having in this thread.

----------

## ramin.honary

I just found this bug report, which seems to be the same problem I have, and has no resolution yet.

I don't know if I have the exact same problem because these people talk as though they had it working before, then it stop working after they did an emerge world. It may yet be a configuration problem; perhaps the emerge process updates some files in /etc that screws up dhcpcd.

Or, this could indeed be a problem with the dhcpcd program itself and not with Gentoo. However, if gentoo is going to be useful for fans of dhcpcd, we should try and find out what's wrong -- the dhcpcd program, or the the way gentoo configures itself to use dhcpcd.

----------

## depontius

Couple of thoughts...

My first thought was that you should check /etc/resolv.conf to see if it looks valid.  Next would be to ping the nameservers specified that, by IP.

Then I saw the listings later and saw you getting the IP "169.254..." and have another thought, and I've run into this type of problem occasionally, too.  The "169.254..." addresses are APIPA, or zeroconf.  It's kind of a "networking of last resort" type of setup.  It means that they couldn't get a response from a dhcp server within some timeout, so they grabbed one of the APIPA addresses and verified that nobody else had it, and assigned it to your adapter.  In practical terms, I don't know why it has happened, whether some sort of timeout is too short before if fails over into APIPA, or your dhcp server slow, or exactly what.  As I said, I've had it happen to me very infrequently.  Taking the network adapter down and restarting generally fixed it.  I believe there's also somewhere in /etc/conf.d/net that you can specify "!apipa" and APIPA will never kick in, at all.

Incidentally, I'm running dhcp 3.x.

----------

## ramin.honary

OK, I got it working, but I am not sure what it was that fixed the problem. For the sake of posterity, I'll explain what I did.

First, I realized that although I had re-compiled the kernel, I made the foolish mistake of copying the old kernel to the boot partition. This was because I was in /usr/src/linux, but the /linux is a link to the current kernel source, which was the old kernel. I re-compiled then went to the old directory and re-copied the old kernel.

Now here is where it gets weird, the network started working perfectly on reboot. Then I configured my /etc/conf.d/net file according to the gentoo installers handbook and on the next reboot, the network failed to load. So I am wondering if the install handbook lead me astray.

Finally, I copied the "net-setup" script and related files from the live-cd to my /usr/sbin folder, rebooted into the now-crippled environment, ran net-config, and it works OK now!

So whether it was the re-compile of the kernel, or the use of net-install, or both, which fixed it I am not sure. But a few questions remain:Why would ifconfig load a working eth0, then dhcpcd refuse to communicate with it? What did I do wrong with my configuration. I followed the instructions in the handbook to a T. I still have the offending config file, I can post it here if someone can look at it for me.

Why did the internet stop working after I manually configured the /etc/conf.d/net file? Could it be that my network provider doesn't like hand-configured dns_domain_lo names? Could it be one of the options dhcp_eth0 options (nodns nontp nonis) caused it to take issue with my ISP?I don't think this thread should be declared "resolved" until these questions are more clearly answered.

Finally, from what package could I emerge the net-config script? I couldn't find it in portage, so I had to copy it directly from the live-cd. Does anyone know what emerge command I should use?

----------

## genblood

I've been reading all the postings about the dhcpcd timeout issues ...

I spent like 3 hours trying different combos with the kernel and

different data in the /etc/conf.d/net file ...

I decided to boot up without the eth0 connected and I was going to

use a usb wireless ... as always I forget where I put it ... so I just

plugged in the Ethernet cable and type ifconfig ... an to my surprise

it saw the IP ...   :Shocked: 

mlmckeown-21 ~ # ifconfig

eth0      Link encap:Ethernet  HWaddr 00:17:31:2A:4C:0C

          inet addr:192.168.1.112  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:413 errors:0 dropped:0 overruns:0 frame:0

          TX packets:318 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:32492 (31.7 Kb)  TX bytes:39813 (38.8 Kb)

          Interrupt:23

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:15 errors:0 dropped:0 overruns:0 frame:0

          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:270 (270.0 b)  TX bytes:270 (270.0 b)

I don't know what I did ... so I rebooted a few times to see if

it would still get a ip ... and it's working now ... strange ...   :Confused: 

----------

## nixnut

Moved from Installing Gentoo to Networking & Security.

Networking problem, so moved here.

----------

## ramin.honary

Like I said, I'd rather not mark this "SOLVED" yet until I figure out exactly what went wrong with the configuration.

Does anyone know how DHCP clients communicate with eth0? Is there some kind of standard API like <sys/inet.h> or <sys/unistd.h> through which dhcpcd accesses eth0 through the kernel? Or does it actually look for the /dev/eth0 file (or whatever file it was told to use in it's configuration) and send data using fwrite()?

----------

## UberLord

 *ramin.honary wrote:*   

> Like I said, I'd rather not mark this "SOLVED" yet until I figure out exactly what went wrong with the configuration.
> 
> Does anyone know how DHCP clients communicate with eth0? Is there some kind of standard API like <sys/inet.h> or <sys/unistd.h> through which dhcpcd accesses eth0 through the kernel? Or does it actually look for the /dev/eth0 file (or whatever file it was told to use in it's configuration) and send data using fwrite()?

 

dhcpcd queries the kernel about eth0.

It uses common functions between Linux and *BSD where possible.

On Linux it relies on PACKET_FILTER being present in the kernel. Some Linux versions have a buggy BPF filter which stops some versions of dhcpcd from working. dhcpcd-4.0.0-beta7 and upwards have a BPF filter which seems to work on all buggy BPF linux versions.

To communicate with eth0 on Linux, it opens an AF_INET socket to the interface, send data using sendto(2) and reads it back via read(2).

On *BSD it opens a BPF instance, sends the data using writev(2) and reads it back via read(2).

As other posters have said, if it fails to obtain a DHCP lease, it drops back to an IPv4LL, APIPA or zeroconf address, and as such never fails. Newer versions, especially dhcpcd-4, have vastly improved IPv4LL support, with the aim of becoming Bonjour certified by Apple.

I know this because I write and maintain dhcpcd  :Smile: 

----------

## ramin.honary

Wow, thank you so much for the info!   :Very Happy: 

This gives me reason to believe that re-compiling the kernel was really what fixed the problem. Even if eth0 is communicating with the network, it may be that when I compiled dhcpcd, it didn't link to the right library (or some such problem). That being the case, it would always fail to open an AF_INET socket, possibly due to a failure of "dlopen()".

OR... if it isn't a library problem, then perhaps there is a way to configure how the kernel opens AF_INET sockets? Is there a configuration file for that as well, or would that be something set at compile-time?

Either way, this would fail regardless of the setup in the /etc/conf.d/net file and hence fall back on the IPv4LL. (How annoying it is to see an IP of 169.254.xx.xx when you know DHCP should be getting you a real IP number from your local network.)

So I guess the last question is, if dhcpcd fails because it didn't link right at compile time, and "dlopen()" failed, would this error be reported in a log file, and if so which log file?

The lesson learned (and this may be a hasty conclusion): unless you're sure, compile ethernet drivers as modules rather than building them into the kernel so you don't have to recompile the entire kernel if you get the wrong driver the first time around. Then, if dhcpcd isn't working right and ifconfig is reporting that eth0 is working fine, then you may need to re-compile your ethernet drivers, or configure the kernel such that it can allow user-space applications to open AF_INET sockets.

I still am not sure if there is a more efficient way to solve the problem than simply re-compiling the kernel, but I'll go ahead and mark this topic solved for now.

Thanks to everyone who helped me out!

----------

## UberLord

You always have AF_INET sockets, dhcpcd does not use dlopen.

On Linux it only links to the librt library, which in turn needs libpthread. No extra libraries are needed on *BSD.

dhcpcd (and all DHCP clients) are heavily dependant on a correct kernel and drivers for the interface.

----------

