This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 138181 - dhclient probes useless interfaces
dhclient probes useless interfaces
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
: 139468 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-05 06:23 EST by Ulrich Drepper
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 3.0.1-12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-27 13:14:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to verify flags for interfaces found via /proc (748 bytes, patch)
2004-11-05 06:23 EST, Ulrich Drepper
no flags Details | Diff

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.