Bug 21375

Summary: [PATCH] dhclient runs away on interface removal
Product: Base System Reporter: lyndon <lyndon>
Component: binAssignee: Martin Blapp <mbr>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.1-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description lyndon 2000-09-18 22:00:01 UTC 
Once the NIC is up and dhclient has configured the NIC, removing
the card causes dhclient to go into a spin loop on the select() in
the dispatch() routine. The call to got_one() gets an error from
the read() on the socket, but doesn't do anything special with the
error. got_one() returns and the whole thing repeats, grabbing most
of the CPU in the process (and generating gobs of syslog cruft).

Fix: Fixing this correctly would require dhclient be able to handle
dynamic interfaces correctly. Short of doing that rewrite, the
following patch adds a test for the read() returning ENXIO, and shuts
down the application in that event. This is definately a bit if a hack.
It's based on the premise that the failing dhclient was launched from
pccardd (via pccard_ether) and that pccardd will start another dhclient
the next time the NIC is inserted. I think this is safe -- I can't think
of another normal dhclient scenario where one of the interfaces
would just disappear.

An alternative fix would be to invalidate the interface on dhclient's
internal interface list (removing it from the FD set), and terminate if
the interface count goes to zero.

Patch against /usr/src/contrib/isc-dhcp/common/dispatch.c:
Comment 1 Johan Karlsson freebsd_committer freebsd_triage 2000-09-19 19:09:40 UTC 
Responsible Changed
From-To: freebsd-bugs->obrien

Over to dhcp maintainer.
Comment 2 David E. O'Brien freebsd_committer freebsd_triage 2000-11-04 20:25:14 UTC 
State Changed
From-To: open->analyzed

I don't want the FreeBSD dhclient to become its own mutant. 
I'll only apply a change such as this one if you can get the ISC to make 
the same [exact] change to the version 3 client.  If this change is already 
in the version 3 software, pointing out the exact CVS revisions where the 
change entered would greatly increase my agreement to make the change 
and greatly speed my analysis of the change.
Comment 3 Lyndon Nerenberg 2000-11-08 17:43:07 UTC 
Does this mean ISC version 3 will be imported once it's released? If
that's the case then you can close the PR and I'll submit this directly
to ISC.
Comment 4 David E. O'Brien freebsd_committer freebsd_triage 2000-12-23 19:20:22 UTC 
Responsible Changed
From-To: obrien->freebsd-bugs

I am not the single dhclient maintainer now.
Comment 5 Bruce A. Mah freebsd_committer freebsd_triage 2001-04-16 19:24:57 UTC 
State Changed
From-To: analyzed->closed

Closed by submitter's request.
Comment 6 Martin Blapp freebsd_committer freebsd_triage 2003-02-10 09:38:50 UTC 
State Changed
From-To: closed->open

Fix is still not committed to the ISC repo. I'll deal 
with this mess.
Comment 7 Martin Blapp freebsd_committer freebsd_triage 2003-02-10 09:50:20 UTC 
Responsible Changed
From-To: freebsd-bugs->mbr

Take this PR
Comment 8 Martin Blapp freebsd_committer freebsd_triage 2003-04-27 00:52:02 UTC 
State Changed
From-To: open->analyzed

Fixed some time ago in dhclient. The patch committed is 
not the same, but almost: 

bpf.c: line 427 

#ifdef __FreeBSD__ 
if (errno == ENXIO) { 
#else 
if (errno == EIO) { 
#endif 
dhcp_interface_remove 
((omapi_object_t *)interface, 
(omapi_object_t *)0); 

Can you test if it still fails with recent BSD's. Unfortunatly 
all pccards and cardbus cards fail here to work on my laptop.
Comment 9 Martin Blapp freebsd_committer freebsd_triage 2003-07-28 19:56:23 UTC 
State Changed
From-To: analyzed->closed

Submitter timeout.