dhclient DHCPv6 does not work with interface alias

Bug #1693819 reported by Dan Streetman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
isc-dhcp (Debian)
New
Unknown
isc-dhcp (Ubuntu)
Won't Fix
Low
Unassigned
Trusty
Won't Fix
Low
Unassigned
Xenial
Won't Fix
Low
Unassigned
Yakkety
Won't Fix
Low
Unassigned
Zesty
Won't Fix
Low
Unassigned
Artful
Won't Fix
Low
Unassigned

Bug Description

[Impact]

The isc-dhcp-client dhclient program does not work with interface alias names, e.g. eth0:1. It fails immediately.

[Test Case]

On trusty through artful, find an interface that is connected to a network that has a DHCPv6 server on it. First verify it can get a DHCPv6 address, e.g.:

$ sudo dhclient -6 -v ens7

that should successfully set up a DHCPv6 address on the interface. Then release the interface:

$ sudo dhclient -6 -v -r ens7

Now, try again but use the interface alias, e.g.:

$ sudo dhclient -6 -v ens7:1

It should succeed, but it will fail with:

no link-local IPv6 address for ens7:1

[Regression Potential]

Changing how isc-dhcp handles (enumerates/lists/compares) interface names may lead to isc-dhcp using the wrong interface or failing to find the correct interface to use. However, if the only change is to strip the alias part from the interface during comparison, the possibility of error should be small, since all interface aliases point back to the same physical interface.

[Other Info]

This bug exists in the upstream isc-dhcp; the ISC has no public bug tracker, and only accepts bug reports via private email, which has been sent.

Revision history for this message
Dan Streetman (ddstreet) wrote :

This problem is because isc-dhcp strips the interface alias when it enumerates the system interfaces, i.e. in common/discover.c function next_iface():

                /* interface aliases look like "eth0:1" or "wlan1:3" */
                s = strchr(info->name, ':');
                if (s != NULL) {
                        *s = '\0';
                }

However when later searching the previously-enumerated list for the matching interface for the cmdline interface parameter name, it does not strip the interface alias from the cmdline interface name, i.e. in common/discover.c function discover_interfaces():

        /* Cycle through the list of interfaces looking for IP addresses. */
        while (next_iface(&info, &err, &ifaces)) {

                /* See if we've seen an interface that matches this one. */
                for (tmp = interfaces; tmp; tmp = tmp->next) {
                        if (!strcmp(tmp->name, info.name))
                                break;
                }

The 'info' interface will always have its info.name set to the actual interface name, without any alias extension, while the 'tmp' interface (from the cmdline) will have its tmp->name set to the interface including alias extension; the strcmp then never matches, so isc-dhcp is not able to correctly match the requested interface with the actual system interface.

Dan Streetman (ddstreet)
Changed in isc-dhcp (Ubuntu):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Low
Dan Streetman (ddstreet)
Changed in isc-dhcp (Ubuntu Zesty):
assignee: nobody → Dan Streetman (ddstreet)
Changed in isc-dhcp (Ubuntu Yakkety):
assignee: nobody → Dan Streetman (ddstreet)
Changed in isc-dhcp (Ubuntu Xenial):
assignee: nobody → Dan Streetman (ddstreet)
Changed in isc-dhcp (Ubuntu Trusty):
assignee: nobody → Dan Streetman (ddstreet)
Changed in isc-dhcp (Ubuntu Zesty):
importance: Undecided → Low
Changed in isc-dhcp (Ubuntu Yakkety):
importance: Undecided → Low
Changed in isc-dhcp (Ubuntu Xenial):
importance: Undecided → Low
Changed in isc-dhcp (Ubuntu Trusty):
importance: Undecided → Low
Revision history for this message
Dan Streetman (ddstreet) wrote :

This is specifically important for any configuration that wants to have both a IPv4 address and DHCPv6 IPv6 address on a single interface, and uses ifupdown for interface management, and wants independent control of the 4 and 6 address. Meaning, to be able to add or remove an interface's IPv6 DHCPv6 address, while leaving the interface up and still configured with its IPv4 address. The ifupdown program does not have any mechanism for controlling IPv4 and IPv6 addresses on a single interface separately, so interface aliases are the most convenient way to keep using ifupdown and be able to control the addresses separately. An example ifupdown configuration might be:

auto eth0
iface eth0 inet manual
  pre-down ifdown eth0:1
  pre-down ifdown eth0:2

auto eth0:1
iface eth0:1 inet dhcp

auto eth0:2
iface eth0:2 inet6 dhcp

That configuration will start dhcp for both IPv4 and IPv6 addresses on eth0 at boot, and will allow running 'sudo ifdown eth0:1' to remove the IPv4 address only, while leaving the IPv6 address, or 'sudo ifdown eth0:2' to remove the IPv6 address only, while leaving the IPv4 address. Or, 'sudo ifdown eth0' will remove both addresses and take down the physical interface. Since this configuration uses an interface alias for DHCPv6, the current isc-dhcp-client fails, and requires the patch from the attached debdiffs to work.

Revision history for this message
Dan Streetman (ddstreet) wrote :
Revision history for this message
Dan Streetman (ddstreet) wrote :

This has been assigned upstream ISC bug: ISC-Bugs #45294

ISC's bug tracking is not public, so there is no way to track any upstream progress in fixing this.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "lp1693819-trusty.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Changed in isc-dhcp (Debian):
status: Unknown → New
Eric Desrochers (slashd)
Changed in isc-dhcp (Ubuntu Artful):
status: New → In Progress
Changed in isc-dhcp (Ubuntu Zesty):
status: New → Confirmed
Changed in isc-dhcp (Ubuntu Yakkety):
status: New → Confirmed
Changed in isc-dhcp (Ubuntu Xenial):
status: New → Confirmed
Changed in isc-dhcp (Ubuntu Trusty):
status: New → Confirmed
Revision history for this message
Dan Streetman (ddstreet) wrote :

The attached debdiffs introduce a regression, please hold off applying until I can investigate and update the patches.

Revision history for this message
Dan Streetman (ddstreet) wrote :
Revision history for this message
Dan Streetman (ddstreet) wrote :
Revision history for this message
Dan Streetman (ddstreet) wrote :
Revision history for this message
Dan Streetman (ddstreet) wrote :
Revision history for this message
Dan Streetman (ddstreet) wrote :
Revision history for this message
Dan Streetman (ddstreet) wrote :

Attached patches that rework the patch, instead of changing common/discover.c to strip the interface alias during name comparison, the new patch strips the interface alias in client/dhclient.c before copying the argv parameter, so dhclient does not use the alias at all. I tested in t/x/y/z/a and dhclient still worked with normal (non-aliased) interface names, as well as working for dhcpv4 and dhcpv6 for aliased interface names, both requesting and releasing.

Revision history for this message
Dan Streetman (ddstreet) wrote :

PPA updated with the current patches.
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1693819

tags: added: rls-aa-notfixing
Revision history for this message
Dan Streetman (ddstreet) wrote :

I should note:

1. The isc-dhcp code is common between dhcpd and dhclient
2. The current system interfaces are enumerated in common/discover.c, and that code - in next_iface() - strips the interface alias from all enumerated interfaces, so when dhcpd or dhclient is comparing a parameter against an existing interface, none of the existing enumerated interface names will have aliases
3. The interface parameters are parsed separately for dhcpd and dhclient; my patch changes *only* the parsing for dhclient, in client/dhclient.c, so that any command line interface names have their alias stripped
4. Other places that parse interface name parameters are dhcpd (in server/dhcpd.c), interface hotplug (maybe? in server/mdb.c, not sure about this file), and the dhcp relay (in relay/dhcrelay.c); my patch does *not* change any of these places, so interface name parameters to dhcpd, the dhcp relay, or in mdb.c, will still have interface aliases, and will not match any of the internally-enumerated (in common/discover.c) interface names. However, my patch narrowly fixes this specific bug, of 'dhclient -6 eth0:1' not working.

tags: added: patch-needswork
removed: patch
Dan Streetman (ddstreet)
Changed in isc-dhcp (Ubuntu):
assignee: Dan Streetman (ddstreet) → nobody
Changed in isc-dhcp (Ubuntu Zesty):
assignee: Dan Streetman (ddstreet) → nobody
Changed in isc-dhcp (Ubuntu Artful):
status: In Progress → Confirmed
assignee: Dan Streetman (ddstreet) → nobody
Changed in isc-dhcp (Ubuntu Yakkety):
assignee: Dan Streetman (ddstreet) → nobody
Changed in isc-dhcp (Ubuntu Xenial):
assignee: Dan Streetman (ddstreet) → nobody
Changed in isc-dhcp (Ubuntu Trusty):
assignee: Dan Streetman (ddstreet) → nobody
Changed in isc-dhcp (Ubuntu):
status: In Progress → Confirmed
status: Confirmed → Won't Fix
Changed in isc-dhcp (Ubuntu Trusty):
status: Confirmed → Won't Fix
Changed in isc-dhcp (Ubuntu Xenial):
status: Confirmed → Won't Fix
Changed in isc-dhcp (Ubuntu Yakkety):
status: Confirmed → Won't Fix
Changed in isc-dhcp (Ubuntu Zesty):
status: Confirmed → Won't Fix
Changed in isc-dhcp (Ubuntu Artful):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.