After upgrading dhcpcd from 2.0.5-r1 to 3.0.16, I can't get an IP address from my "3COM OfficeConnect Wireless Cable/DSL Gateway". I have tried both wireless and cabled connections. Downgrading dhcpcd "solves" the problem. Using 2.0.5: # dhcpcd -N -R -d eth0 Info, MAC address = 00:14:22:fa:96:93 Debug, broadcasting DHCP_DISCOVER Debug, dhcpIPaddrLeaseTime=43200 in DHCP server response. Debug, dhcpT1value is missing in DHCP server response. Assuming 21600 sec Debug, dhcpT2value is missing in DHCP server response. Assuming 37800 sec Debug, DHCP_OFFER received from ÿ (192.168.1.1) Debug, broadcasting DHCP_REQUEST for 192.168.1.248 Debug, dhcpIPaddrLeaseTime=43200 in DHCP server response. Debug, dhcpT1value is missing in DHCP server response. Assuming 21600 sec Debug, dhcpT2value is missing in DHCP server response. Assuming 37800 sec Debug, DHCP_ACK received from ÿ (192.168.1.1) Debug, broadcasting ARPOP_REQUEST for 192.168.1.248 Info, verified 192.168.1.248 address is not in use Info, your IP address = 192.168.1.248 Debug, orig hostname = kru3 Using 3.0.16: # dhcpcd -N -R -d eth0 Info, eth0: dhcpcd 3.0.16 starting Info, eth0: hardware address = 00:14:22:fa:96:93 Info, eth0: broadcasting for a lease Debug, eth0: sending DHCP_DISCOVER with xid 1256379199 Debug, eth0: waiting on select for 20 seconds Debug, eth0: sending DHCP_DISCOVER with xid 1256379199 Debug, eth0: sending DHCP_DISCOVER with xid 1256379199 Debug, eth0: sending DHCP_DISCOVER with xid 1256379199 Debug, eth0: sending DHCP_DISCOVER with xid 1256379199 Debug, eth0: sending DHCP_DISCOVER with xid 1256379199 Debug, eth0: sending DHCP_DISCOVER with xid 1256379199 Error, eth0: timed out Info, eth0: exiting # dhcpcd -N -R -d -l 43200 eth0 Info, eth0: dhcpcd 3.0.16 starting Info, eth0: hardware address = 00:14:22:fa:96:93 Info, eth0: broadcasting for a lease Debug, eth0: sending DHCP_DISCOVER with xid 602271590 Debug, eth0: waiting on select for 20 seconds Debug, eth0: sending DHCP_DISCOVER with xid 602271590 Debug, eth0: sending DHCP_DISCOVER with xid 602271590 Debug, eth0: sending DHCP_DISCOVER with xid 602271590 Debug, eth0: sending DHCP_DISCOVER with xid 602271590 Debug, eth0: sending DHCP_DISCOVER with xid 602271590 Debug, eth0: sending DHCP_DISCOVER with xid 602271590 Error, eth0: timed out Info, eth0: exiting Thanks. -- Kim Reproducible: Always Steps to Reproduce:
Could you attach raw tcpdumps or wireshark traces for dhcpcd-2.0.5 and dhcpcd-3.0.16? If you would rather not attach them here, please email them to me. Thanks
Created attachment 115477 [details] Wireshark dump
Created attachment 115478 [details] Wireshark dump, shows failure
Well, both look fine. Could you try requesting an infinite least time? dhcpcd -N -R -d -l -1 eth0
Same result: # dhcpcd -N -R -d -l -1 eth0 Info, eth0: dhcpcd 3.0.16 starting Info, eth0: hardware address = 00:14:22:fa:96:93 Info, eth0: broadcasting for a lease Debug, eth0: sending DHCP_DISCOVER with xid 916755478 Debug, eth0: waiting on select for 20 seconds Debug, eth0: sending DHCP_DISCOVER with xid 916755478 Debug, eth0: sending DHCP_DISCOVER with xid 916755478 Debug, eth0: sending DHCP_DISCOVER with xid 916755478 Debug, eth0: sending DHCP_DISCOVER with xid 916755478 Debug, eth0: sending DHCP_DISCOVER with xid 916755478 Debug, eth0: sending DHCP_DISCOVER with xid 916755478 Error, eth0: timed out Info, eth0: exiting
I experimented with different parameters and finally got it to work. It seems that my cable router expects "large requests": FAILS: dhcpcd -N -R -d -i "12345678901234567890123456789012345" eth0 WORKS: dhcpcd -N -R -d -i "123456789012345678901234567890123456" eth0 FAILS: dhcpcd -N -R -d -h "12345678901234567890123456" eth0 WORKS: dhcpcd -N -R -d -h "123456789012345678901234567" eth0 FAILS: dhcpcd -N -R -d -u "1234567890123456789" eth0 WORKS: dhcpcd -N -R -d -u "12345678901234567890" eth0 FAILS: dhcpcd -N -R -d -I "1234567890123456789012345678" eth0 WORKS: dhcpcd -N -R -d -I "12345678901234567890123456789" eth0 FAILS: dhcpcd -N -R -d -I x -h x -u "" -i 1234567890123456789012345678901234567890 eth0 WORKS: dhcpcd -N -R -d -I x -h x -u "" -i 12345678901234567890123456789012345678901 eth0 FAILS: dhcpcd -N -R -d -I x -h x -u "" -l -1 -i 1234567890123456789012345678901234 eth0 WORKS: dhcpcd -N -R -d -I x -h x -u "" -l -1 -i 12345678901234567890123456789012345 eth0 FAILS: dhcpcd -N -R -d -I 12345678901 -h 12345678901 -u 1234567890 -i 1234567890 eth0 WORKS: dhcpcd -N -R -d -I 12345678901 -h 12345678901 -u 12345678901 -i 1234567890 eth0 WORKS: dhcpcd -N -R -d -I 123456789012345678901234567890123456789012345678 -h 12345678901234567890123456789012345678901234567890 -u 12345678901234567890123456789012345678901234567890 -i 123456789012345678901234567890123456789012345678 eth0 So just by specifying a long vendor ID, I got it to work: # dhcpcd -N -R -d -i 123456789012345678901234567890123456 eth0 Info, eth0: dhcpcd 3.0.16 starting Info, eth0: hardware address = 00:14:22:fa:96:93 Info, eth0: broadcasting for a lease Debug, eth0: sending DHCP_DISCOVER with xid 1771614337 Debug, eth0: waiting on select for 20 seconds Debug, eth0: got a packet with xid 1771614337 Debug, eth0: no facility to parse DHCP code 52 Info, eth0: offered 192.168.1.248 from 192.168.1.1 `ÿ' Debug, eth0: sending DHCP_REQUEST with xid 1771614337 Debug, eth0: waiting on select for 19 seconds Debug, eth0: got a packet with xid 1771614337 Debug, eth0: no facility to parse DHCP code 52 Error, eth0: given MTU 64 is too low, minium is 576 Info, eth0: leased 192.168.1.248 for 43200 seconds Info, eth0: no renewal time supplied, assuming 21600 seconds Info, eth0: no rebind time supplied, assuming 37800 seconds Debug, eth0: setting MTU to 576 Info, eth0: adding IP address 192.168.1.248/24 Info, eth0: adding default route via 192.168.1.1 metric 0 Debug, eth0: no dns information to write Debug, eth0: writing /var/lib/dhcpcd/dhcpcd-eth0.info Debug, eth0: forking to background I suspect that the cable router is to blame. Thanks anyway. Let me know if you need help trying something out on such a router. -- Kim
Ah, and another faulty MTU sender too! dhcpcd-3.0.17 will handle this a little better by simply ignoring values <576 instead of setting 576. It will also have an option just to ignore it. Do you want to open an upstream bug or ticket and reference it here or should we just close this?
(In reply to comment #7) If the router is to blame, then this bug should be closed. My problem has been solved (worked-around), so I'm happy. It does, however, appear that the way dhcpcd-2.0.5 worked is more robust against faulty servers...
(In reply to comment #8) > (In reply to comment #7) > > If the router is to blame, then this bug should be closed. > My problem has been solved (worked-around), so I'm happy. > > It does, however, appear that the way dhcpcd-2.0.5 worked is more robust > against faulty servers... Well, so far just this one. dhcpcd-3.x works against 3 servers that 1.x and 2.x didn't, so it's a silly argument anyway. Ah well. I'm pretty sure it is a server issue as there is no minimum DHCP packet size as such.
I am having the exact same problem, dhcpcd-3.0.16 does not work, a dhcp request just times out, and when I revert back to dhcpcd-2.0.5 everything works fine.
(In reply to comment #10) > I am having the exact same problem, dhcpcd-3.0.16 does not work, a dhcp request > just times out, and when I revert back to dhcpcd-2.0.5 everything works fine. And if you create a long packet as above it works? What router/AP are you using?
I am using a Conceptronic C100BRS4 router, and yes, it does seem to be solving the problem.
BTW: My notebook is a Dell Inspiron 6400 with Broadcom 440 100Mbps LAN card and an Intel IPW3945 wireless card (both showing the same symptoms) in case you need to know.
OK I'll re-open this
BTW: I dont know if its going to be fixed, but if its not going to be fixed, I would like to suggest to add some sort of compatibility flag, which you can define in your /etc/conf.d/net For example adding the option dhcpcompat which will send a long request then.
I think an even simpler solution would be to change the default vendor ID. For me, dhcpcd-2.0.5 uses the vendor ID string "Linux 2.6.19-gentoo-r5 i686". dhcpcd-3.0.16 uses the string "dhcpcd 3.0.16". While it was a coincidence, that version 2.0.5 worked for me, the long string was a blessing. If it hadn't worked, I would probably never had figured out how to get version 3.0.16 to work. So if dhcpcd was changed to default to a long vendor ID string, some failing situations would be avoided while I don't think new failing situations would arise. I think that would be a better solution than a new configuration parameter which does the same as "-i <long string>"
Created attachment 115987 [details, diff] Define a minimum packet length This patch adds a define for a minimum packet length. The default packet my PC sends is 276 bytes, but the BOOTP spec has a minimum size of 300 bytes. Of course, the this restriction is gone in DHCP spec, but I think this is the real error. If the patch fails, try a larger number like say 500 and then decrease until we find the magic number
(In reply to comment #17) I can confirm that the patch solves the problem for me.
Fixed in -r1, thanks
