Bug 800561 - dhclient fails to bind to interface when releasing lease.
dhclient fails to bind to interface when releasing lease.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-06 12:56 EST by Ben Greear
Modified: 2015-02-23 18:25 EST (History)
2 users (show)

See Also:
Fixed In Version: dhcp-4.3.1-12.fc21
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-23 18:25:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to allow dhclient to bind to interface when releasing lease. (1.41 KB, patch)
2012-03-06 12:57 EST, Ben Greear
no flags Details | Diff

  None (edit)
Description Ben Greear 2012-03-06 12:56:20 EST
Description of problem:

The packet instead goes out whatever the default routing table
assumes is correct.  The patch below fixes this problem.


Version-Release number of selected component (if applicable):

Fedora 14, and I believe later ones as well.

How reproducible:

Always.

The patch to fix this is below:

diff --git a/dhcp-4.2.0/client/dhclient.c b/dhcp-4.2.0/client/dhclient.c
index 21e4a2d..436bfc6 100644
--- a/dhcp-4.2.0/client/dhclient.c
+++ b/dhcp-4.2.0/client/dhclient.c
@@ -2578,16 +2578,16 @@ void send_release (cpp)
 	      inet_ntoa (destination.sin_addr),
 	      ntohs (destination.sin_port));
 
-	if (fallback_interface)
-		result = send_packet (fallback_interface,
-				      (struct packet *)0,
+	/* Send out a packet. */
+	if (client -> interface)
+		result = send_packet (client -> interface, (struct packet *)0,
 				      &client -> packet,
 				      client -> packet_length,
 				      from, &destination,
 				      (struct hardware *)0);
 	else
-		/* Send out a packet. */
-		result = send_packet (client -> interface, (struct packet *)0,
+		result = send_packet (fallback_interface,
+				      (struct packet *)0,
 				      &client -> packet,
 				      client -> packet_length,
 				      from, &destination,
-- 
1.7.3.4
Comment 1 Ben Greear 2012-03-06 12:57:20 EST
Created attachment 568023 [details]
Patch to allow dhclient to bind to interface when releasing lease.
Comment 2 Ondrej Vasik 2012-03-07 02:48:17 EST
F14 is EOL, please change product version to some newer Fedora, if you experience the issue there.
Comment 3 Ben Greear 2012-03-07 19:26:31 EST
F14 is the last version with a functional gnome, but I digress.

I tested on F16 today, and the problem happens there as well,
so changing this bug to be against F16.
Comment 4 Jiri Popelka 2012-03-08 03:24:04 EST
Thanks for the patch,
however I'm not sure I understand how this could be reproduced (probably something like 'dhclient -r' ?) and what's the consequence of this 'packet goes out whatever the default routing table assumes is correct' problem.
Comment 5 Ben Greear 2012-03-08 11:17:49 EST
Suppose you have two interfaces on the same machine on the same subnet
(perhaps both running dhcp to the same DHCP server).

You can set up routing rules so that traffic from the IP associated with
one interface actually uses that interface, and you can do things like SO_BINDTODEVICE.

DHCP actually properly binds to the interface when acquiring the lease,
and you can use a custom callback script to set up routing rules based
on the IP it acquires, etc.

But, when you release the lease, the current code does NOT bind to the
interface properly and so the release packet for one interface may go out of
another interface that matches standard routing rules.  That other interface
may not be connected to the DHCP server and so the release fails to happen.

Since release is optional, this is not too bad of a failure, but for
my case, I want it to work properly and actually do the release when
I ask it too.

The attached patch just makes it properly bind before sending the
release packet.  I've tested this and it works fine as far as I can
tell.

And yes, it is the '-r' option.  Here's my command line, though it need
not be so complicated:

./local/sbin/dhclient -r -lf my-lease-file -cf my-conf-file -pf my-pid-file -sf lf_dhclient_script_foo.bash eth1
Comment 6 Fedora Update System 2012-03-21 15:01:08 EDT
dhcp-4.2.3-22.P2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dhcp-4.2.3-22.P2.fc17
Comment 7 Fedora Update System 2012-03-22 20:43:48 EDT
Package dhcp-4.2.3-22.P2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dhcp-4.2.3-22.P2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4532/dhcp-4.2.3-22.P2.fc17
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2012-03-23 14:18:32 EDT
dhcp-4.2.3-23.P2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dhcp-4.2.3-23.P2.fc17
Comment 9 Fedora Update System 2012-04-11 22:35:06 EDT
dhcp-4.2.3-24.P2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Jiri Popelka 2013-06-28 16:46:46 EDT
The patch seems to cause bug #979510.
Comment 11 Jiri Popelka 2013-07-02 08:28:48 EDT
I removed that patch for now (dhcp-4.2.5-15)

(In reply to Ben Greear from bug #979510, comment #1)
> I actually ended up re-writing the patch that causes this bug, but never
> tried to push it upstream.  (I find it a total pain to try to write patches
> for upstream
> since I never found an active upstream tree under source control).

There's no publicly available repository.

> For what it's worth, we've been testing the re-write for 7 months or so
> and it appears to work fine.  I'm sure we don't hit all possible corner
> cases, however.
> 
> Any chance you could try this version and see if it works for you?
> 
> https://github.com/greearb/dhcp-ct

What commits do you think I need to apply ?
Comment 12 Ben Greear 2013-07-02 10:54:37 EDT
I was hoping the reporter of the bug could try our tree to see if it works
in their scenario.

We do all of our testing with all of those commits applied.  Some of the features
are performance improvements for using DHCP on systems with lots of interfaces, so they will not directly apply to this bug, but at least in my opinion they
are worth considering for general use.

I think it would be great if someone could create an upstream git repository
that has all of the patches in RPM applied to it.  We could then re-base our
tree on that one and feed you nice clean git patches easily.

If that is not possible, then I think you can just remove that old patch
I posted (as you have already done) and we will just use our own dhcp tree
for our needs.  Our tree will stay on github, and we will probably rebase
it on something newer than Fedora 14 some day in case others want to use
it.
Comment 14 Fedora Update System 2015-02-03 07:18:54 EST
dhcp-4.3.1-12.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/dhcp-4.3.1-12.fc21
Comment 15 Fedora Update System 2015-02-04 03:00:34 EST
Package dhcp-4.3.1-12.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dhcp-4.3.1-12.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-1651/dhcp-4.3.1-12.fc21
then log in and leave karma (feedback).
Comment 16 Fedora Update System 2015-02-23 18:25:04 EST
dhcp-4.3.1-12.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

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