Red Hat Bugzilla – Full Text Bug Listing
|Summary:||dhclient probes useless interfaces|
|Product:||[Fedora] Fedora||Reporter:||Ulrich Drepper <drepper>|
|Component:||dhcp||Assignee:||Jason Vas Dias <jvdias>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||3.0.1-12||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-05-27 13:14:13 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Ulrich Drepper 2004-11-05 06:23:45 EST
Created attachment 106208 [details] Patch to verify flags for interfaces found via /proc
Comment 1 Ulrich Drepper 2004-11-05 06:23:45 EST
Description of problem: The dhclient code has a Linux-specific extension where it reads /proc/net/dev to search for interfaces which have no address yet. This code has a problem since it also returns the loopback device and addresses which cannot broadcast. Both these cases are explictly excluded in the generic code using the ioctl() call to discover interfaces. But also using the ioctl() is wrong. I have been told it is unreliable. The correct method, these days, is to use the netlink interface. And instead of writing this code again the discover_interfaces() should simply use the getifaddrs() code from glibc. Fixing the problem without using Version-Release number of selected component (if applicable): dhclient-3.0.1-11 How reproducible: always Steps to Reproduce: 1.run dhclient on system with loopback and/or sit interfaces 2. 3. Actual results: Listening on LPF/sit0/ Sending on LPF/sit0/ Listening on LPF/lo/ Sending on LPF/lo/ Listening on LPF/eth0/00:07:e9:9b:a0:a9 Sending on LPF/eth0/00:07:e9:9b:a0:a9 Expected results: Listening on LPF/eth0/00:07:e9:9b:a0:a9 Sending on LPF/eth0/00:07:e9:9b:a0:a9 Additional info: I'm attaching a minimal patch which simply verifies the flags of the interfaces doscivered by reading /proc. Still, in the long run it is better to use getifaddrs.
Comment 2 Jason Vas Dias 2004-11-05 11:44:54 EST
I don't see that this causes an actual problem - though dhclient does "listen" on all interfaces, it sends only on broadcast capable interfaces with hardware addresses and accepts replies only from interfaces on which it has sent. Also dhclient is only invoked with an actual interface argument, in which case it listens only on that interface. However, as the suggested patch is copied from the same function a few lines up where the interfaces returned from the SIOCGIFCONF are filtered, I can see no harm to including it - though state is DISCOVER_UNCONFIGURED, and tmp is NULL, so the clause: ... && !tmp) || (!(ifr.ifr_flags & IFF_UP) && state != DISCOVER_UNCONFIGURED)) has no effect. I agree the whole function could benefit from a major cleanup using RTNETLINK or the "getifaddrs" glibc call - which is, by the way, totally undocumented and lacking a getifaddrs(3) man-page. I'll include the modified patch in the next release and send it upstream, and investigate using NETLINK/getifaddrs to clean up the function.
Comment 3 Jason Vas Dias 2004-11-16 09:48:29 EST
*** Bug 139468 has been marked as a duplicate of this bug. ***
Comment 4 Amit Bhutani 2004-11-16 11:06:29 EST
Any chance that this patch will make it for dhclient in RHEL 4 ?
Comment 5 Jason Vas Dias 2004-11-16 12:15:22 EST
I think it is too late in the RHEL-4 development and testing cycle to get a change to dhcp in, as the bug is non-critical - it only results in a few stray log messages, and causes no real problems. Moreover, it is the way dhcp has always behaved. It would also be desirable to redesign the function to use the getifaddrs function as suggested above, that would be a major change requiring more time for testing than is avaiable for RHEL-4. The fix for this bug and for bug #139468 will go into FC-4 and a later RHEL-4 update release.
Comment 6 Jason Vas Dias 2004-11-16 15:35:22 EST
This is now fixed in dhcp-3.0.1-12 (FC4) & dhcp-3.0.1-12_EL (RHEL-4).
Comment 7 Amit Bhutani 2004-11-23 16:27:54 EST
Verified fixed in dhcp-3.0.1-12_EL. Thanks! I will let the submitter close this issue.
Comment 11 Ulrich Drepper 2006-05-27 13:14:13 EDT
Again, I think using ioctl() instead of getifaddrs() is wrong. You'll sooner or later run into problems. But that can be the topic of another bug.