Cannot get dhcpcd to give me an IP address,tried two different dhcp servers, and it works fine using other OS or other dhcp client software. Tried reverting to older dhcpcd versions, 2.0.7/2.0.6/2.0.5 don't work either, but 2.0.0 works just fine. (I could not find ebuilds for 2.0.1 to 2.0.4) Not sure whether or not this is related to bug 137800. See libpcap dumps attached below for the working (2.0.0) and non-working (2.0.5+) cases.
Created attachment 92343 [details] Capture of correctly functioning dhcpcd v2.0.0
Created attachment 92344 [details] Capture of incorrectly function dhcpcd v2.0.5 Ran dhcpcd with "-t 5" option to reduce the time it waits before giving up.
Oh yes, FWIW I'm running kernel 2.6.17 (gentoo-sources) on AMD 64 bit machine (X2 4400+)
Well, I don't mean what are those captures, it's completely unreadable. Reopen with emerge --info.
Like I mentioned in the first post, the attachments are libpcap (ethereal) captures to show the network traffic for the working and non-working cases. I marked them as binary attachments, somehow they've been changed to text/plain, I'm marking them binary again
(In reply to comment #5) > Like I mentioned in the first post, the attachments are libpcap (ethereal) > captures to show the network traffic for the working and non-working cases. I have no idea how to use ethereal or stuff like that, so this may take some time to analyze and fix. Does dhcpcd-2.0.8 work when you use the -a option?
Not, -a does not seem to change anything. Now that I was able to use -v, I get the following: # dhcpcd -v 8 -t 5 eth1 Info, MAC address = 00:15:f2:05:9d:7d Debug, broadcasting DHCP_DISCOVER Debug, broadcastAddr option is missing in DHCP server response. Assuming 192.168.0.255 Debug, dhcpIPaddrLeaseTime=604800 in DHCP server response. Debug, DHCP_OFFER received from (192.168.0.1) Debug, broadcasting DHCP_REQUEST for 192.168.0.150 Debug, dhcpIPaddrLeaseTime=604800 in DHCP server response. Debug, DHCP_ACK received from (192.168.0.1) Debug, broadcasting ARPOP_REQUEST for 192.168.0.150 Info, verified 192.168.0.150 address is not in use Info, your IP address = 192.168.0.150 Error, timed out waiting for a valid DHCP server response All the lines except the last (Error...) appear immediately, and then after the timeout period the last one occurs. I think I know partly why this happens. The ethereal trace from 2.0.0 did the DHCP, and then when it got the answer it was happy. The traces from 2.0.5 onwards also get the DHCP answer, but then they try to do a DNS lookup, which is actually what times out... Furthermore, the reason the DNS lookup times out is that the DNS packet has an incorrect UDP checksum. I'm having a look at that code now in udpipgen.c, will hopefully be able to make a patch later (I need to leave on a few errands for a few hours now)
Right, as far as I can tell, the problem isn't necessarily dhcpcd itself. At some point (dhcpconfig.c:516 in 2.0.8-r1 src) it calls gethostbyaddr, which generates the (seemingly incorrect) DNS query. If I put my hostname in /etc/hosts, then it works fine (doesn't generate a DNS query, and immediately sets my IP from the DHCP response). Also, if I set the timeout longer (with not /etc/hosts entry), it also works (but takes 30s before it times out waiting for gethostbyaddr to complete). I'm not entirely sure why 2.0.0 does not end up generating a DNS query however. Something must have changed between 2.0.0 and 2.0.5 somewhere which triggers this. I'm going to look into it a little bit further to see if I can find out why.
OK, I'm not sure whether this is correct or not, but changing the code as follows seems to at least prevent gethostbyaddr being called, which makes everything seem to work correctly for me. -- dhcpconfig.c.orig 2006-07-22 12:16:37.000000000 +0200 +++ dhcpconfig.c 2006-07-22 12:57:33.000000000 +0200 @@ -511,7 +511,7 @@ else logger(LOG_ERR,"dhcpConfig: fopen %s: %s", ntp_file, strerror(errno)); } - if ( ! DhcpOptions.len[hostName] ) + if ( SetHostName && ! DhcpOptions.len[hostName] ) { hp=gethostbyaddr((char *)&DhcpIface.ciaddr, sizeof(DhcpIface.ciaddr),AF_INET); n This is similar to what 2.0.0 used to do, i.e. gethostbyaddr was only called if SetHostName was 1 (if -H was passed on command line). Whether or not this fix is the correct way to do it, I'm not sure.
Well spotted. I changed the default behaviour to set the hostname if we didn't have one and looks like I removed one too many checks! Fixed in dhcpcd-2.0.8-r2