IPv6 prefix delegation not working with 24.7.1-.3

[imk82]

As I see it it's asking multiple times, also interrupted due to SIGHUP reconnect, getting multiple answers but eventually refusing to give out another prefix and that's where it stops as expected.

Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.

Maybe really some hidden magic which is bound to the interface name "wan"? Thats the only config change I've done as far as I can see.

Seeing that PPPoE is involved I'd like to ask you to try the following:

Ok, will check tomorrow if this is applicable.

A simple "opnsense-patch 6b28dae2" should be enough?

How likely is this to break stuff or being irreversible?

Best regards
Robert

[franco]

> Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.

Most of this revolves around timing issues: PPP being a bit less reliable due to extra software in between (mpd5), dhcp6c code changes causing IPv4 and IPv6 sequence mismatches, additional use of Netmap (suricata and zenarmor) or modem interaction on the plugged WAN link.

6b28dae2 tries to address some of these issues by moving IPv6 setup to PPP linkup time, not generic IPv4 renewal time (which is called much more often).

6b28dae2 should be safe enough, you can run the patch command again and it will be removed. the patch is also cached so it's easy to recover from no connectivity due to patches. But this patch has been extensively tested so I don't think it would be worse than before.


Cheers,
Franco

[imk82]

> Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.

Most of this revolves around timing issues: PPP being a bit less reliable due to extra software in between (mpd5), dhcp6c code changes causing IPv4 and IPv6 sequence mismatches, additional use of Netmap (suricata and zenarmor) or modem interaction on the plugged WAN link.

6b28dae2 tries to address some of these issues by moving IPv6 setup to PPP linkup time, not generic IPv4 renewal time (which is called much more often).

6b28dae2 should be safe enough, you can run the patch command again and it will be removed. the patch is also cached so it's easy to recover from no connectivity due to patches. But this patch has been extensively tested so I don't think it would be worse than before.


Cheers,
Franco

Hi Franco,

unfortunatley a "opnsense-patch 6b28dae2" did not fix the problem. See attached dhcp6c log.

Not sure if it is worth mentioning, but my "wan" interface is getting a IPv6 address, just the PD part is broken.

Best regards
Robert

[imk82]

Hi Franco,

really stupid question and asked if at another point this thread already, but all I try to do should work with a which is not the original wan (mine is a custom created new interface, not ootb wan), right?

Just asking because I scrolled a little bit through the changed files in your commit and e.g. here:
https://github.com/opnsense/core/blob/6b28dae26cbadb9d25708685f590ee9af0506678/src/etc/inc/interfaces.inc#L2238

is a hard coded reference to "wan" and later this is used via "$wancfg".

But really didn't looked trough the whole code flow but stumbled over it and the question came up again for me.

Best regards
Robert

[franco]

Hi Robert,

This is only the default value, but in all honestly it's a historic artefact and not even used anymore. The interface name is always passed.

I think we figured out the mix of commits that caused dhcp6c to regress the way it did in 24.7.2:

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg

This will be in 24.7.4. Worth a test, but needs a reboot to activate.


Cheers,
Franco

[imk82]

Hi Franco,

This is only the default value, but in all honestly it's a historic artefact and not even used anymore. The interface name is always passed.

This is purely a interpreted languange without compiling or poat processing build steps to check method calls against the existing signatures, right? So no chance to just remove the default without risk of breaking stuff.

I think we figured out the mix of commits that caused dhcp6c to regress the way it did in 24.7.2:

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg

This will be in 24.7.4. Worth a test, but needs a reboot to activate.

Can I apply this with opnsense-patch somehow and is this different from the previous opnsense-patch 6b28dae2 82ea39b04c?

Or makes it just sense to wait for 24.7.4?

Thanks again and best regards
Robert

[doktornotor]

Can I apply this with opnsense-patch somehow

Nah. You can apply it with the command already posted:

Code Select Expand

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg

[franco]

> This is purely a interpreted languange without compiling or poat processing build steps to check method calls against the existing signatures, right? So no chance to just remove the default without risk of breaking stuff.

The default argument could and will be removed, but better done in batch while working on nothing related, which is currently not possible.


Cheers,
Franco

[imk82]

Can I apply this with opnsense-patch somehow

Nah. You can apply it with the command already posted:

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg

Hi all,

how can I revert this to the production version? Is a

Code Select Expand

opnsense-revert dhcp6c

enough to do so?

Sorry, havn't that much experience in that direction and it is a quite productive system.:-)

Best regards
Robert

[franco]

Yes:

# opnsense-revert dhcp6c

This reverts the dhcp6c package to the last know release version (24.7.3 today).


Cheers,
Franco

[franco]

PS: The version you tested is going to be tomorrow's release version in 24.7.4 anyway.

[imk82]

PS: The version you tested is going to be tomorrow's release version in 24.7.4 anyway.

Hi Franco,

tried again with 24.7.4. Unfortunately I still get no prefix delegated on my "wan" interface. I send a /56 prefix hint and use the IPv4 connectivity on the interface tagged with vlan 7. As all the years before.

I've attached the log again. Still no specialist in that topic, but I think the pattern of the log changed somewhat since 24.7.3. It repeats steps and contains multiple times a clear

Code Select Expand

create a prefix 2003:c3:xxxx:xxxx::/56

But later stopping with it and then a

Code Select Expand

advertise contains no address/prefix

Do you have another idea what to check?

Thanks and best regards
Robert

[franco]

Hi Robert,

I think here is what could be the problem:

2024-09-18T13:39:22   Notice   dhcp6c    Sending Solicit
2024-09-18T13:39:22   Notice   dhcp6c    got an expected reply, sleeping.
2024-09-18T13:39:22   Notice   dhcp6c    script "/var/etc/dhcp6c_opt8_script.sh" terminated
2024-09-18T13:39:22   Notice   dhcp6c    dhcp6c_script: REQUEST on pppoe1 renewal
2024-09-18T13:39:22   Notice   dhcp6c    dhcp6c_script: REQUEST on pppoe1 executing
2024-09-18T13:39:22   Notice   dhcp6c    executes /var/etc/dhcp6c_opt8_script.sh
2024-09-18T13:39:22   Notice   dhcp6c    removing server (ID: 00:02:00:00:05:83:32:38:3a:38:61:3a:31:63:3a:36:35:3a:39:66:3a:63:30:00:00:00)
2024-09-18T13:39:22   Notice   dhcp6c    removing an event on pppoe1, state=REQUEST
2024-09-18T13:39:22   Notice   dhcp6c    reset a timer on pppoe1, state=INIT, timeo=0, retrans=557
2024-09-18T13:39:22   Notice   dhcp6c    remove an IA: NA-9
2024-09-18T13:39:22   Notice   dhcp6c    IA NA-9 is invalidated
2024-09-18T13:39:22   Notice   dhcp6c    status code for NA-9: no addresses
2024-09-18T13:39:22   Notice   dhcp6c    make an IA: NA-9
2024-09-18T13:39:22   Notice   dhcp6c    create a prefix 2003:c3:xxxx:xxxx::/56 pltime=86400, vltime=86400
2024-09-18T13:39:22   Notice   dhcp6c    make an IA: PD-9
2024-09-18T13:39:22   Notice   dhcp6c    nameserver[1] 2003:180:2::53
2024-09-18T13:39:22   Notice   dhcp6c    nameserver[0] 2003:180:2:6000::53
2024-09-18T13:39:22   Notice   dhcp6c    Received REPLY for REQUEST
2024-09-18T13:39:22   Notice   dhcp6c    get DHCP option DNS, len 32
2024-09-18T13:39:22   Notice   dhcp6c      IA_PD prefix: 2003:c3:xxxx:xxxx::/56 pltime=86400 vltime=86400
2024-09-18T13:39:22   Notice   dhcp6c    get DHCP option IA_PD prefix, len 25
2024-09-18T13:39:22   Notice   dhcp6c      IA_PD: ID=9, T1=43200, T2=69120
2024-09-18T13:39:22   Notice   dhcp6c    get DHCP option IA_PD, len 41
2024-09-18T13:39:22   Notice   dhcp6c      status code: no addresses
2024-09-18T13:39:22   Notice   dhcp6c    get DHCP option status code, len 43
2024-09-18T13:39:22   Notice   dhcp6c      IA_NA: ID=9, T1=0, T2=0
2024-09-18T13:39:22   Notice   dhcp6c    get DHCP option identity association, len 59
2024-09-18T13:39:22   Notice   dhcp6c      DUID: 00:02:00:00:05:83:32:38:3a:38:61:3a:31:63:3a:36:35:3a:39:66:3a:63:30:00:00:00
2024-09-18T13:39:22   Notice   dhcp6c    get DHCP option server ID, len 26
2024-09-18T13:39:22   Notice   dhcp6c      DUID: 00:01:00:01:2d:a2:0e:6f:00:d0:b4:02:1d:fa
2024-09-18T13:39:22   Notice   dhcp6c    get DHCP option client ID, len 14
2024-09-18T13:39:22   Notice   dhcp6c    receive reply from fe80::2a8a:1cff:fe65:99f6%pppoe1 on pppoe1

So you can see you get a prefix, but the zero lifetime NA causes the client to time out and discard everything at the same time.

Do you have "Request only a prefix" unset? It would be better to set this option if that's the case. If it's already set we need to try and ignore this zero lifetime NA that doesn't even provide an address.

To me it looks like a server quirk to be honest.


Cheers,
Franco

[imk82]

Hi Franco,

Do you have "Request only a prefix" unset? It would be better to set this option if that's the case. If it's already set we need to try and ignore this zero lifetime NA that doesn't even provide an address.

Yes, this was unchecked. Never checked this the years before and it always worked. Nevertheless, gave it a try but without success (see attached log).

To me it looks like a server quirk to be honest.

If we follow this theory, then something must have triggered this server problem on the OPNsense side since 24.7.x. Before I always had IPv6 in use and no problems.

For mit it looks like all is fine, but it just isn't working and getting a prefix. Weird.

One small thing I changed with the migration to 24.7.x is, that OPNsense is now setting the Vlan ID (7) instead of the modem internally (that was the case before). But I cannot imagine how this can lead to the problem, IPv4 is working fine and I even get a IPv6 address for the "wan interface", just the prefix is not delegated.

Best regards
Robert

[franco]

Robert,

As per my earlier comments I wrote this patch to try https://github.com/opnsense/dhcp6c/commit/d2e5fb474f

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907_3.pkg

Reboot to see if it helps.


Thanks,
Franco