Project

General

Profile

Actions

Bug #6880

closed

Multiple DHCP6 WAN connections leads to multiple dhcp6c clients

Added by Roy Hooper about 8 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
DHCP (IPv6)
Target version:
Start date:
10/28/2016
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.3.2
Affected Architecture:
All

Description

When configuring multiple interfaces as DHCP6, such as PPPoE DSL and Cable, multiple dhcp6c processes get started, one per interface. This leads to problems, as only the first started dhcp6c will work properly, as dhcp6c binds to *::546

This leads to the second started dhcp6c answers being picked up by the first started, which starts to emit the error message "unexpected interface (%d)" when the wrong dhcp6c receives a reply.

The fix is to run only one dhcp6c and have a combined config file. For example, I might have /var/etc/dhcp6c_wan.conf and /var/etc/dhcp6c_opt3.conf, which should be merged.
Two processes will be started:
/usr/local/sbin/dhcp6c -D -c dhcp6c_wan.conf -p /var/run/dhcp6c_em0.pid -f em0
/usr/local/sbin/dhcp6c -D -c dhcp6c_opt3.conf -p /var/run/dhcp6c_pppoe0.pid -f pppoe0

A working combined config looks like this

interface pppoe0 {
    send ia-na 0;   # request stateful address
    send ia-pd 0;   # request prefix delegation
    request domain-name-servers;
    request domain-name;
    script "/var/etc/dhcp6c_opt3_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
id-assoc pd 0 {
    prefix ::/56 infinity;
    prefix-interface em3_vlan6 {
        sla-id 1;
        sla-len 8;
    };
    prefix-interface em3_vlan5 {
        sla-id 2;
        sla-len 8;
    };
};

interface em0 {
    send ia-na 1;   # request stateful address
    send ia-pd 1;   # request prefix delegation
    request domain-name-servers;
    request domain-name;
    script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 1 { };
id-assoc pd 1 {
    prefix-interface em3 {
        sla-id 0;
        sla-len 0;
    };
};

And the process would be launched like
/usr/local/sbin/dhcp6c -dD -c dhcp6c.conf -p /var/run/dhcp6c.pid -f em0 pppoe0


Related issues

Related to Bug #12823: Multiple DHCP6 WAN connections PPPoE interface 'defached' statusNew

Actions
Related to Bug #13253: ``dhcp6c`` is not restarted when applying settings when multiple WANs are configured for DHCP6ResolvedJim Pingle

Actions
Has duplicate Bug #13353: DHCPv6 (still) doesn't work properly with multiple interfacesDuplicate

Actions
Actions #1

Updated by Jim Thompson about 8 years ago

  • Assignee set to Jim Pingle
Actions #2

Updated by Jim Pingle about 8 years ago

  • Status changed from New to Confirmed
  • Assignee deleted (Jim Pingle)
  • Target version set to Future

Confirmed. The daemon is binding to all interfaces, which prevents the second one from operating properly.

Changing the dhcp6c process to use a single config and instance will require significant work to implement for little gain. At this time, a single LAN cannot utilize prefixes from both WANs until other features such as #4881 are implemented. Therefore, at the moment having a second DHCPv6 WAN is of little use.

Actions #3

Updated by Jim Thompson about 8 years ago

  • Assignee set to Renato Botelho
Actions #4

Updated by → luckman212 almost 8 years ago

I have a dual WAN 2.3.2-p1 system with only one of the WANs configured for DHCP6 (not PPPoE, just Ethernet) and I am hitting this issue too. Not sure if it's quite the same bug, but the end result of winding up with multiple instances of dhcp6c running (and losing v6 connectivity as a result) is the same.

Actions #5

Updated by Martin Wasley almost 8 years ago

Its not, it's a problem that appears from time to time and is quite intermittent. In 2.4b changes have been made which hopefully nai!s this issue of multiple fhcp6c clients.

Actions #6

Updated by → luckman212 almost 8 years ago

Ok great, I will definitely try 2.4b then. If you happen to know which commits are relevant to that fix I'd love to look at them.

Actions #7

Updated by Martin Wasley almost 8 years ago

If you update to the latest snapshot then you can try patch ID: cdb6c8ac8e65f98a2ac0fa469c963c055a5c522d

There are a couple of subsequent minor commits to that, but they are cosmetic and/or minor function call changes that do not affect the overall operation.

Try it and post back your results please.

Actions #8

Updated by → luckman212 almost 8 years ago

Thanks. I first checked out master and didn't find that commit... then drank some coffee & realized it's a PR still under review by Renato. Looks like it is ready to be merged. Will test shortly.

Actions #9

Updated by Renato Botelho almost 8 years ago

Luke Hamburg wrote:

Thanks. I first checked out master and didn't find that commit... then drank some coffee & realized it's a PR still under review by Renato. Looks like it is ready to be merged. Will test shortly.

PR has been merged, but there were a couple of minor problems there, fixed in 31677494e659768a12d134641bbd4453d2c0a03c

Actions #10

Updated by Daniel Helgenberger over 6 years ago

Luke Hamburg wrote:

Thanks. I first checked out master and didn't find that commit... then drank some coffee & realized it's a PR still under review by Renato. Looks like it is ready to be merged. Will test shortly.

The comments about this commit are a little bit confusing. This is issue is still not fixed, right? (Issue is open and I am facing the same issue). I'd like to open a pull request for this one if it is not already in the works.

Actions #11

Updated by Tony Martino over 6 years ago

Daniel Helgenberger wrote:

Luke Hamburg wrote:

Thanks. I first checked out master and didn't find that commit... then drank some coffee & realized it's a PR still under review by Renato. Looks like it is ready to be merged. Will test shortly.

The comments about this commit are a little bit confusing. This is issue is still not fixed, right? (Issue is open and I am facing the same issue). I'd like to open a pull request for this one if it is not already in the works.

This is not fixed. I just posted about it in the community forum (https://forum.netgate.com/topic/133538/with-multiple-ipv6-wan-connections-dhcp6c-broken) and then found this report.

Renato, do you have an update on this? Any way I can help get this fixed?

Actions #12

Updated by Zachary Hill over 6 years ago

In a similar vein, but a bit different: it's also important to be able to have multiple id-assoc pd n stanzas for even a single interface. I'm aware it's a bit unorthodox, but it's supported by the daemon, and it's necessary in my network as I have AT&T UVerse residential ISP with an NVG589 router/gateway that doesn't properly support me requesting my whole /60 (or anything larger than /64) in one go, I have to separately send multiple /64 PD requests.

A working config for me looks like this: (generated by a functional setup on my EdgeRouter X, though I've been unsuccessful in adapting it on pfSense, something about being unable to apply the address to the desired interface)

interface eth0 {
        send ia-na 0;
        request domain-name-servers, domain-name;
        send rapid-commit;
        send ia-pd 0;
        send ia-pd 1;
        script "/opt/vyatta/sbin/ubnt-dhcp6c-script";
};

id-assoc na 0 {};

id-assoc pd 0 {
        prefix ::/64 infinity;
        prefix-interface eth1 {
                sla-id 0;
                sla-len 0;
        };
};

id-assoc pd 1 {
        prefix ::/64 infinity;
        prefix-interface eth2 {
                sla-id 0;
                sla-len 0;
        };
};

I'm not sure the currently planned fix will also cover my use-case (which I assume isn't unique) but I just wanted to add a bit of info to the conversation. I can open up another issue if this would be considered separate or unrelated.

Actions #13

Updated by Moritz Hartwig about 6 years ago

I have the same issue.
Is there still some work on this bug?
Thanks!

Actions #14

Updated by Holger Glemser over 5 years ago

What's the status here? I'm waiting for the fix, too.

Jim Pingle wrote:

Changing the dhcp6c process to use a single config and instance will require significant work to implement for little gain. At this time, a single LAN cannot utilize prefixes from both WANs until other features such as #4881 are implemented. Therefore, at the moment having a second DHCPv6 WAN is of little use.

I cannot agree with the "of little use" part. I have multiple (V)LANs and want to distribute them between my two WANs, i.e. have some configured to track WAN1 and some to track WAN2 which is easily configurable in the UI in the "Track IPv6 Interface" section of the interface configuration. However, this bug causes this not to work.

Actions #15

Updated by Car F over 4 years ago

I have the same problem with 2.4.5-p1. Still no fix?

Actions #16

Updated by Kris Phillips about 4 years ago

Confirmation that issue is still present in 2.4.5p1.

Log messages:
dhcp6c 4633 Sending Solicit
dhcp6c 38399 unexpected interface (1)

Actions #17

Updated by Randy Cross about 4 years ago

I'm running into the same issue

Actions #18

Updated by Caleb Carges about 4 years ago

Just ran into this and #4881 now that our backup ISP also has native v6. Looks like I'll have to work around it by hand for now when in a pinch, by setting that interface to DHCPv6 and configuring NPt specifically when the backup is needed.

Actions #19

Updated by Tobias Meyer about 4 years ago

We too see this issue. Two upstream DHCP6 lines. The confusing thing is, this works somehow, but with intermittent problems. The order in which the pppoe connection and the cable line are started seem to make a difference.

Actions #20

Updated by Tobias H almost 4 years ago

Yes, still there :(

Actions #21

Updated by Car F almost 4 years ago

This issue still isn't fixed with 2.5.0.

Actions #22

Updated by Car F over 3 years ago

Issue is getting worse with 2.5.1-RC. This is unacceptable!

Actions #23

Updated by Flole Systems over 3 years ago

I am using this dirty fix (plus a manually generated config file specified for both interfaces in the Webinterfaces), my interfaces are hardcoded in the patch (eth10 and eth11):

--- /etc/inc/interfaces.inc
+++ /etc/inc/interfaces.inc
@@ -3904,8 +3904,8 @@
 function find_dhcp6c_process($interface) {
        global $g;

-       if ($interface && isvalidpid("{$g['varrun_path']}/dhcp6c_{$interface}.pid")) {
-               $pid = trim(file_get_contents("{$g['varrun_path']}/dhcp6c_{$interface}.pid"), " \n");
+       if ($interface && isvalidpid("{$g['varrun_path']}/dhcp6c.pid")) {
+               $pid = trim(file_get_contents("{$g['varrun_path']}/dhcp6c.pid"), " \n");
        } else {
                return(false);
        }
@@ -3966,8 +3966,8 @@
                $i++;
        }
        /* Clear the RTSOLD script created lock & tidy up */
-       unlink_if_exists("/tmp/dhcp6c_{$interface}_lock");
-       unlink_if_exists("{$g['varrun_path']}/dhcp6c_{$interface}.pid"); // just in case!
+       unlink_if_exists("/tmp/dhcp6c_lock");
+       unlink_if_exists("{$g['varrun_path']}/dhcp6c.pid"); // just in case!
 }
 function reset_dhcp6client_process($interface) {

@@ -3993,15 +3993,15 @@
         * lock deleted.
         */

-       if (!file_exists("/tmp/dhcp6c_{$interface}_lock")) {
+       if (!file_exists("/tmp/dhcp6c_lock")) {
                kill_dhcp6client_process($interface, true);
                /* Lock it to avoid multiple runs */
-               touch("/tmp/dhcp6c_{$interface}_lock");
+               touch("/tmp/dhcp6c_lock");
                mwexec("/usr/local/sbin/dhcp6c {$debugOption} " .
                    "{$noreleaseOption} " .
                    "-c {$g['varetc_path']}/dhcp6c_{$interface_name}.conf " .
-                   "-p {$g['varrun_path']}/dhcp6c_{$interface}.pid " .
-                   $interface);
+                   "-p {$g['varrun_path']}/dhcp6c.pid " .
+                   "eth10 eth11");
                log_error(sprintf(gettext(
                    "Starting dhcp6 client for interface wan %s in DHCP6 without RA mode"),
                    $interface));
@@ -5021,7 +5021,6 @@
        $dhcp6cscriptwithoutra .= "echo \$dreason > /tmp/{$wanif}_reason\n";
        $dhcp6cscriptwithoutra .= "case \$REASON in\n";
        $dhcp6cscriptwithoutra .= "REQUEST)\n";
-       $dhcp6cscriptwithoutra .= "/bin/sleep 2\n";
        $dhcp6cscriptwithoutra .= "/usr/sbin/rtsold -1 -p {$g['varrun_path']}/rtsold_{$wanif}.pid -M {$g['varetc_path']}/rtsold_{$wanif}_script.sh -O {$g['varetc_path']}/rtsold_{$wanif}_script.sh {$wanif}\n";
        if ($debugOption == '-D') {
                $dhcp6cscriptwithoutra .= "/usr/bin/logger -t dhcp6c \"dhcp6c REQUEST on {$wanif} - running rtsold\"\n";
@@ -5188,7 +5187,7 @@
                 *
                 * Taking the interface down or releasing will kill the client.
                 */
-               if (!file_exists("/tmp/dhcp6c_{$wanif}_lock"))
+               if (!file_exists("/tmp/dhcp6c_lock"))
                {
                        /*
                         * If the interface is being brought up, wait for the

This may not work for everyone but for me it work's and that's whats important to me.

Actions #25

Updated by Flole Systems about 3 years ago

Has the fix been merged yet? What's the current status? Can we set the target version appropriately as there is now a PR pending so it should be merged soon-ish?

Actions #26

Updated by Jim Pingle almost 3 years ago

  • Target version changed from Future to CE-Next
  • Plus Target Version set to 22.05
Actions #27

Updated by Jim Pingle almost 3 years ago

  • Status changed from Confirmed to Pull Request Review
Actions #28

Updated by Renato Botelho almost 3 years ago

  • Assignee changed from Renato Botelho to Viktor Gurov
Actions #29

Updated by Viktor Gurov almost 3 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #30

Updated by Viktor Gurov almost 3 years ago

  • Related to Bug #12823: Multiple DHCP6 WAN connections PPPoE interface 'defached' status added
Actions #31

Updated by Jim Pingle almost 3 years ago

  • Target version changed from CE-Next to 2.7.0
Actions #32

Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to Resolved

This looks excellent on the latest snapshot.

On 22.01 each interface has a separate configuration and only one of the interfaces obtains an address.

On 22.05 there is a single combined configuration file, both interfaces get an address, both have online/working gateways, I can ping upstream on both from the firewall itself and from delegated prefixes from both WANs.

Renato mentioned there may still be a lingering issue if both WANs are PPPoE but that can be handled in a separate Redmine issue for a future release. The multiple DHCP6 case appears to be working perfectly now.

Actions #33

Updated by Jim Pingle over 2 years ago

  • Related to Bug #13253: ``dhcp6c`` is not restarted when applying settings when multiple WANs are configured for DHCP6 added
Actions #34

Updated by Jim Pingle over 2 years ago

  • Has duplicate Bug #13353: DHCPv6 (still) doesn't work properly with multiple interfaces added
Actions

Also available in: Atom PDF