Bug #32935 for dhcp-public: Dhclient interface issue [client]

Hi, After testing some releases, it appears the V3.1.3 is the last version that works. Since V4 (even if ipv6 is disblaed), dhclient is unable to initialise nics that have unititialized and down (flag 0x1002) if not specified on command line. This bug only affect the discover_interfaces(DISCOVER_UNCONFIGURED) which is almost never used on modern distros as the dhclient is often calld by systemd or udev rules with the specific nic to configure on the command line. -- Olivier LAHAYE CEA DRT/LIST/DCSI/DIR ________________________________________ De : DHCP Bugs via RT [dhcp-bugs@isc.org] Date d'envoi : mercredi 20 mars 2013 10:09 À : LAHAYE Olivier Objet : [ISC-Bugs #32935] AutoReply: Bug found and tracked down in dhclient 4.2.4 and 4.2.5 at least (not present in 2.0pl5) Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Bug found and tracked down in dhclient 4.2.4 and 4.2.5 at least (not present in 2.0pl5)", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [ISC-Bugs #32935]. Please include the string: [ISC-Bugs #32935] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, dhcp-bugs@isc.org ------------------------------------------------------------------------- Dear all, I've just found and identified a bug in dhclient while trying to create my own initrd for the systemimager project. When starting dhclient without argument, dhclient ignores the eth0 network card and fails with error "No broadcast interfaces found - exiting". It's because eth0 at this moment has flag 0x1002. It is down but it is a BROADCAST interface. If I strart "dhclient eth0", it correctly get an IP address for eth0. If I reset the eth0 iface to its previous state (down + IP=0.0.0.0), and If I assign a non null IP address (a random non null address), dhclient without specifying the interface on the command line will succeed. So this is clearly a bug when calling discover_interfaces(DISCOVER_UNCONFIGURED), as it works when are in the discover_interfaces(DISCOVER_RUNNING) case. The problem is in file dhcp-4.2.4-P2/common/discover.c:576 (same for 4.2.5) If the ioctl trying to get the IP address of the network card fails (needed to check if there is already a lease maybe?), then it is skipped (continue statement). The code does not check flags to see that the interface is down (thus uncondfigured). Another problem is that at this point, we do not have the flags. I've tested to move the flags retreival code before the get address section, and replace the continue with a return. This partially work. The interface is not ignored anymore, unfortunately, later on, line 1003, when testing info.addr.ss_family, the value is uninitialized, and the interface is not configured..... I'm unfortunately not enough skilled to fix this, so if one can fix this, that would be cool. Best regards, -- Olivier LAHAYE CEA DRT/LIST/DCSI/DIR

---

Hello Olivier: You'll be happy to hear that we addressed this issue in our upcoming releases 4.3.6, 4.1-ESV-R15 (due out in July); and 4.4.0 whose release date is TBD. This was reported by others as well and was fixed under a different ticket number. We like to thank our contributors by citing them in the release notes. If you would like to be recognized in this way please reply with how you care to be identified. My apologies for the wait on this. As a small non-profit we have finite resources and we have to work on what we can as we can. Thank you for your interest and taking the time to report the issue. We welcome any future submissions you care to make. Sincerely, Thomas Markwalder ISC Software Engineering

---