Bug 741786 - dhclient-script wipes acquired address when aliases are defined
dhclient-script wipes acquired address when aliases are defined
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-09-27 17:31 EDT by Scott Shambarger
Modified: 2011-10-03 14:04 EDT (History)
1 user (show)

See Also:
Fixed In Version: dhcp-4.2.2-9.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-10-03 14:04:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch (2.93 KB, text/plain)
2011-09-27 17:31 EDT, Scott Shambarger
no flags Details

  None (edit)
Description Scott Shambarger 2011-09-27 17:31:38 EDT
Created attachment 525215 [details]

Description of problem:
Adding an alias entry to dhclient.conf leads to dhclient-script overwriting the a newly bound ip address with the alias address when address is configured with initscripts (untested with NetworkManager).

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

How reproducible:
Always with an alias configured in dhclient.conf
Add an entry for an alias to dhclient.conf on an interface configured for dhcp via initscripts.

Steps to Reproduce:
1. Configure an interface for dhcp in initscripts, eg: ifcfg-em1

  File: ifcfg-em1

  File: ifcfg-em1:0

2. Add an entry for alias for the interface in dhclient.conf, eg:

  File: dhclient.conf
  alias {
    interface "em1";
    option subnet-mask;
    option broadcast-address;

3. Bring the interface up: # ifup em1

Actual results:

  Only alias address is present on device after bind, eg:

  # ip addr show dev em1
    inet scope global em1

Expected results:

  Both alias and newly bound address should be on link, with alias correctly labeled.

  # ip addr show dev em1
    inet brd scope global em1
    inet brd scope global em1:0

Additional info:

It appears that the script is performing a flush on ${interface}:0, however iproute2 will flush the device, not the alias, removing the existing bound address.

When configured with initscripts, aliases such as "${interface}:0" are created with ifconfig which uses labels to distinguish the alias address from the primary address on the interface.  To flush just the labeled address, the correct syntax is:

  # ip addr flush dev ${interface} label ${interface}:0

There appears to be numerous errors in dhclient-script with respect to aliases, with the script using the "dev ${interface}:0" syntax rather than "dev ${interface} label ${interface}:0"

In addition, there appears to be a few places where dhclient-script sets the link down when it appears to actually just wish to purge the alias address.

Also, the alias address is set without using the "broadcast ${alias_broadcast_address}" clause.

I've attached a patch to dhclient-script with some proposed fixes, including:
  1. label the alias using the ${interface}:0 label
  2. add "broadcast ${alias_broadcast_address}" clause where appropriate
  3. correct syntax of "dev ${interface}:0" clauses where appropriate
  4. replace alias link down with flush on the alias label
Comment 1 Jiri Popelka 2011-09-29 08:39:07 EDT
I've applied your patch.
Thank you !
Comment 2 Fedora Update System 2011-09-30 11:23:23 EDT
dhcp-4.2.2-9.fc16 has been submitted as an update for Fedora 16.
Comment 3 Fedora Update System 2011-09-30 15:14:47 EDT
Package dhcp-4.2.2-9.fc16:
* should fix your issue,
* was pushed to the Fedora 16 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.2-9.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 4 Fedora Update System 2011-10-03 14:04:03 EDT
dhcp-4.2.2-9.fc16 has been pushed to the Fedora 16 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.