Bug 138181

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.

 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. 
 

*** Bug 139468 has been marked as a duplicate of this bug. ***

Any chance that this patch will make it for dhclient in RHEL 4 ?

 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. 

 This is now fixed in dhcp-3.0.1-12 (FC4) &  dhcp-3.0.1-12_EL (RHEL-4).

Verified fixed in dhcp-3.0.1-12_EL. Thanks!

I will let the submitter close this issue.

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.