Bugzilla Bug 173399

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 an attachment (id=115477) [details]
Wireshark dump

Created an attachment (id=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 an attachment (id=115987) [details]
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