Summary: | net-misc/dhcpcd-5.2.* ignores the -r command line option | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Simone Scanzoni <nonno.cicala> |
Component: | [OLD] Unspecified | Assignee: | William Hubbs <williamh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, cbrannon, roy |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Fix request
tcpdump -s0 -w/tmp/dhcpcd-5.2.9.raw -ieth0 After dhcpcd -k eth0 |
Description
Simone Scanzoni
2010-12-21 17:46:16 UTC
Roy, I can confirm this behaviour in 5.2.9. Thanks, William Created attachment 257897 [details]
Fix request
Please test the attached patch
(In reply to comment #2) > Created an attachment (id=257897) [details] > Fix request > > Please test the attached patch > Tested with 5.2.8 and 5.2.9 : no change. Happy Holidays to everybody. Can you post a full tcpdump of the DHCP transaction please? tcpdump -s0 -w/tmp/dhcpcd.raw -ieth0 Created attachment 257997 [details]
tcpdump -s0 -w/tmp/dhcpcd-5.2.9.raw -ieth0
I used dhcpcd-5.2.9 with the above patch.
dhcpcd -r 23.10.120.51 -m 3 eth0
I got 23.10.120.50
The trace clearly shows that your IP is now requested correctly, however the DHCP server still sent you the "wrong" one. With dhcpcd still running, you can release the "wrong" one and try again. dhcpcd -k eth0 dhcpcd -r 23.10.120.51 -m 3 eth0 I reproduced the bug, and the patch works for me. Created attachment 258043 [details]
After dhcpcd -k eth0
This time I ran:
# dhcpcd -r 23.10.120.52 -m 3 eth0
and I got 23.10.120.50/24 .
Doing
# dhcpcd -k eth0
before
# dhcpcd -r 23.10.120.51 -m 3 eth0
worked once. After that I always got 23.10.120.51 even if I requested a different address after dhcpcd -k eth0.
(with version 4.0.15 dhcpcd -r "address" always gets the address requested)
I've been using version 5.2.9 (patched) for some days and the behavior seems to be that I get the requested address if I wait enough from the last time the DHCP server assigned an address to this PC. After I get an address, whatever it was, doing dhcpcd -k and a new request with a different address always gives me the first I got. (In reply to comment #9) > I've been using version 5.2.9 (patched) for some days and the behavior seems to > be that I get the requested address if I wait enough from the last time the > DHCP server assigned an address to this PC. After I get an address, whatever it > was, doing dhcpcd -k and a new request with a different address always gives me > the first I got. That is an issue with the DHCP server then. ISC DHCPd 3.0.3 gives me the address I request every time correctly unless I request an out of bounds IP or configure the DHCP server to give me a fixed IP. dhcpcd-5.2.10 has been released with this change Also, dhcpcd-5.2.10 is now in portage. Roy, thanks a lot. :-) (In reply to comment #10) > (In reply to comment #9) > > [...] > > That is an issue with the DHCP server then. > ISC DHCPd 3.0.3 gives me the address I request every time correctly unless I > request an out of bounds IP or configure the DHCP server to give me a fixed IP. > Ok, it's strange that it worked with dhcpcd-4.0.15 then. Thanks a lot. (In reply to comment #13) > Ok, it's strange that it worked with dhcpcd-4.0.15 then. > Thanks a lot. Old behaviour with request was to directly request the IP address. New behaviour is to request it as an option in the DISCOVER phase. With the new way, we can request the address each time we do a discover. With the old way, it was only the first time. So when carrier went down for whatever reason it didn't attempt to re-request the address. Still, I would describe what you are seeing as a DHCP server bug though. (In reply to comment #14) > (In reply to comment #13) > > Ok, it's strange that it worked with dhcpcd-4.0.15 then. > > Thanks a lot. > > Old behaviour with request was to directly request the IP address. > New behaviour is to request it as an option in the DISCOVER phase. > > With the new way, we can request the address each time we do a discover. > With the old way, it was only the first time. So when carrier went down for > whatever reason it didn't attempt to re-request the address. > > Still, I would describe what you are seeing as a DHCP server bug though. > I didn't doubt your words. I already thought it could be a bug in the server, because I know that in general a better behaviour may trigger bugs somewhere else. But it's the kind of thing that makes me say "D'Oh!". Really, thanks for the explanation. :) |