ipconfig hangs on DHCP
Task Info (Flyspray) | |
---|---|
Opened By | Fedor Dostoyevskiy (bachtiar) |
Task ID | 36666 |
Type | Bug Report |
Project | Arch Linux |
Category | Arch Projects |
Version | None |
OS | All |
Opened | 2013-08-25 12:32:23 UTC |
Status | Assigned |
Assignee | Gerardo Exequiel Pozzi (djgera) |
Assignee | Christian Hesse (eworm) |
Details
ipconfig from mkinitcpio-nfs-utils hangs when obtaining IP address from DHCP on machine with two network cards.
As a result, one can not use machines with multiple network cards for diskless systems. Ouch.
Steps to reproduce:
- put ipconfig on machine with two network cards
- disconnect cable from eth0 and connect it to eth1 (or whatever the second interface is named)
- start your favourite DHCP server somewhere on the network
- ipconfig all
Technical elaboration: "ipconfig all" (or for backward compatibility "ipconfig ip=dhcp") is supposed to bring up the first interface on which it receives a DHCP reply. However, due to misconfigured state machine in process_receive_event(main.c), it hangs in DHCPOFFER state and never finishes. The bug is triggered by connecting cable to eth1, because function do_pkt_recv iterates over interfaces in order they were found (eth0 first, eth1 second) and when it receives reply from DHCP server, it wrongfully assumes it's for eth0. Because the DHCP request was sent on eth1, the reply has different transaction ID from what eth0 would expect, so ipconfig drops the packet and gets stuck in DHCPOFFER state, from which it never recovers. Even adding timeout ("-t") does not help.
For proper operation, the state machine should assume that the replies coming from network can arrive in any order. So in fact the state machine should be driven by received packets and reaching to them instead of iterating through interface list.
In the other scenario (cable connected to eth0), ipconfig is similarily confused, but sometimes recovers after 10 minutes or so, typically when some Windows machine on the network broadcasts some UDP traffic, causing it to stop waiting and timeout.
The workaround is to use "ipconfig ethX" if you know which X will be connected (which I can not in advance).