NIC - dhcpcd trouble on startup
 

Hey folks....

I'm having a little trouble with one of my network cards. I don't think it matters, but its
in my webserver.

One the rare occasion I restart the system (when I make changes to /etc/inetd.conf)
One boot up I get some errors from dhcpcd:

At the current time only the bottom 2 lines are viewable (there is I think 5 lines to the error)

the 2 that I can see are:
dhcpcd[332]: dhcpT2value is missing in DHCP server response. Assumin 52 sec.
dhcpcd[332]: DHCP_ACK received from (IP address of my router)

and this scrolls by about every 5 - 10 seconds .

So I log in and I type:
kill pid 332
dhcpcd

and everything works fine. (doublecheck it with ifconfig, etc. everthing works - all is OK)

Now to my question:
If I can kill the pid of dhcpcd and start it again without changing settings, why doesn't it work on startup?

This is something that I can live with, but I'd rather not.
thanks in advance -tw

Re: NIC - dhcpcd trouble on startup
 

these (and most likely the one's above them) aren't really errors...

the dhcp client is simply telling you that the dhcp server gave it less info than it would have wanted, but that it's alright cuz it's gonna use some defaults, or it's gonna make it's own calculation if it can...

for example, another common dhcp client message could look like this:

dhcpd[332]: broadcastAddr option is missing in DHCP server response. Assuming 192.168.1.255

this dhcp client might have gotten assigned 192.168.1.2 (netmask 255.255.255.0), and since the dhcp server didn't transmit the broadcast address (192.168.1.255), it calculated it on it's own...

Hmm, I'm courious as to why it wouldn't repeat the messages after he killed it and restarted.

I was guesing that the startup script wanted the DHCP client to start with an option that the server was not configured to give. Thus when he killed and restarted without the option it worked ok.

one tends to start it manually by simply doing a "dhcpcd eth0", for example... but the messages are printed when you start dhcpcd with the "-d" option, as slackware does by default (take a look at the way dhcpcd is run from /etc/rc.d/rc.inet1 and you'll see)...

kill your dhcpcd and start it again with the "-d" option:

killall dhcpcd

dhcpcd -d eth0

you'll see that the messages get logged into /var/log/debug

if you don't use the "-d" option they won't get logged...

win32sux,

Not only did it resolve the issue, but I appreciate your explination. That was just as helpful
as the resolution.

thanks again - tw

This doesnt really have to do with the problem above, but have you guys noticed that the dhcpcd package that Slackware 9.1/10 comes with uses the wrong file name for the script that will be executed everytime the IP Address changes (really nice for updating Dynamic DNS). If you notice, slackware names it /etc/dhcpc/dhcpcd-eth0.exe when in fact if you look at the man page it really should be /etc/dhcpc/dhcpcd.exe. I came upon this when I was trying to get my Dynamic DNS to auto-update and noticed that it wasnt doing it. You can fix this one of two ways, either rename/symlink dhcpcd-eth0.exe to dhcpcd.exe or edit /etc/rc.d/rc.inet1 and use the -c flag and point it to /etc/dhcpc/dhcpcd-eth0.exe. If anybody here knows how to find out who maintains the dhcpcd slack package, id like to contact them so that this issue can be resolved. Thanks

This came in handy for me. I have two NICs, a wireless and wired. Slackware named one of them /etc/dhcpcd/dhcpcd-eth0.exe and the other ~/dhcpcd-eth1.exe. That way I can use either or both without problems.

I see the benefits of making the files with NIC-specific names, but my point is what good does that do if the dhcpcd server never looks at those files?? The dhcpcd startup command that Slackware 9.1/10 uses by default in your rc.inet1 file does NOT use the -c option to tell it what executable file to use, and so dhcpcd uses its default which is 'dhcpcd.exe'.