Messages

N100 and microcode... it's always those, isn't it... ;(

Hi Franco,

ok, so disable the plugin, update and enable again?

Best regards
Robert

Hi all,

just for the record: this solved theproblem.

* disable microcode plugin
* update go 25.7.2
* enable microcode plugin again

All well now so far on my N100 box.

Best regards
Robert

N100 and microcode... it's always those, isn't it... ;(

Hi Franco,

ok, so disable the plugin, update and enable again?

Best regards
Robert

Hello, complete noob and first time poster here ! I'm happy to join Opnsense community !

Got Black Dwarf Terra G2 box some weeks ago with 25.1 on it. Got everything up and running rather fast and smoothly. I have no fancy configuration, but also using Wifi AP (Atheros) on it (due Chromecast). All fine. Upgraded smoothly to 25.1.12, also installed os-realtek plugin/driver as my box has RTL8xxx cards on it. Run even system audit. All OK.

Today I tried to upgrade to 25.7 via webgui - everything downloaded fine, initial checks were OK. Last line on webgui console window was !!!ATTENTION!!! but I do not know what came after that, as box went to reboot.

I waited 30-40 mins but box never came up again. Then I lost my patience and re-plugged power cord. It booted fine, but I'm still on 25.1.12. Everything seems to work as I'm posting this. No traces of upgrade. How can I check what (if any) is the error ? I have no console options available right now and all LOG files start with current (successful) boot.

Hi Suur13, Hi Franco,

cannot really contribute right now, but what I can tell:
* had the exact same problem with my N100 box
* solution was a reboot. No hard shutdown, pressed power button only short and once. So something must have been alive shutting down cleanly and resetting to 25.1.12
* didn't find the trust to try again right now, still on 25.1.12 now

Best regards
Robert

Hi dseven,

I doubt, but cannot proof it in any direction because it is a "production" (multi house hold + we live in home office times) system and I cannot change configs for testing right now.

What I can tell is, that the IP address before and after setting the range was identical.

Nevertheless, even when marking this a solved for now, I will have another look later.

Thanks so far and best regards
Robert

[an address range is specified in the DHCPv6 service settings]

It should be possible to do a static mapping with a dynamic prefix - you'd just specify the suffix part of the address only, e.g. ::0:0:0:abcd - but, so long as you have a pool of addresses available for dynamic leases, that should not be necessary in order for the route to get added.

I've played around with this a bit, and I did get it (prefix route added when using a dynamic lease) to work, but it wasn't exactly straightforward - possibly partly because I already had my prefix delegation configured for a static (not tracking) interface, and cleanup of my old config seemed incomplete.

I'd suggest that, for any interfaces using tracking for IPv6, you check the "Allow manual adjustment of DHCPv6 and Router Advertisements" box, and configure DHCPv6 (and RA) explicitly the way you want - it seems that the automatic mechanism may make some egregious assumptions when it comes to prefix delegation (possible topic for another thread).

Failing that, describe how your interfaces and the DHCPv6 service are configured, and how you're observing that the route is not getting added...

Hi dseven,

thanks for your reply. I did some more investigation as well in the meantime and came across one sentence in the DCPH documentation https://docs.opnsense.org/manual/dhcp.html:

Dynamic DHCPv6 address lease: If an address range is specified in the DHCPv6 service settings and the downstream router requests both an address (IA_NA) and prefix (IA_PD), the prefix will be routed to the leased address.

This was not the case in my configuration because it was (technically) not necessary. The IPv6 address was handed out by the DHCP server without it as well to my downstream router (based on the prefix ID setting in the "Track IPv6 Interface" config of my relevant interface of the OPNsense box). Nevertheless, to match the documentation I added a range and..now the route to my /57 prefix is created automatically targeting the router IP (v6).

Next thing I want to try is the static configuration part mentioned in the documentation as well. But I am unsure how the DUID must look like to be kind of dynamic for the (often) changing prefix. But..next year. :-)

Best regards
Robert

Found another related discussion: https://forum.opnsense.org/index.php?msg=174073

But not fully sure about Francos comment there relating to the static mapping approach and how this may work with an dynamic prefix from my ISP?

Hi all,

just to confirm I am not doing a stupid mistake.

This is my setup:
* I get a /56 delegated from my ISP
* the OPNsense box is directly behind the modem
* box is delegating a /57 to a downstream router

Until that point, all works as desired. What NOT works and I don't find the "why": OPNsense is never creating a route for the delegated /57 to my downstream router via the interface it is connected to. In consequence, IPv6 is not working at all in that network segment.

Is there anything specific I must know here or is this just a bug?

What I found is this: https://forum.opnsense.org/index.php?topic=7719.0 describing exactly my problem. But, I do request a IPv6 address from the downstream router already and it is handed out. But in that case, only a route for the /64 which contains the dhcp pools address range is created, not for the /57 which is delegated.

Thanks in advance
Robert

Hi all,

a question for understanding how ISC DHCPv6 configuration is desired to work. What I want is to delegate /57 out of my /56 prefix to a downstream router. I try the following configuration (see screenshot as well):

Code Select Expand


Prefix Delegation Range
from: ::80:0000:0000:0000:0000
to: ::ff:ffff:ffff:ffff:ffff


But, this is not working, I get a "network mask too short prefix6" error message in the log if trying. On the other hand a:

Code Select Expand


Prefix Delegation Range
from: ::80:0000:0000:0000:0000
to: ::80:0000:0000:0000:0000


is accepted.

Has someone experience here and can explain the logic behind to me?

From my understanding, the first config is correct while the last is not.

Thanks and best regards
Robert

Hi Robert,

Sorry for the response delay.  It's still true but the package moved to a new rebuild (but holds the same source code as discussed):

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

Just update to 24.7.5 and see how that goes as a separate data point. Then install the updated client and reboot again to see if that changes things.

Cheers,
Franco

Hi Franco,

good and bad news.

Did another series of tests to track this down further. Just as a recap, my setup is:
* OPNSense setting vlan7 (necessary for my provider Deutsche Telekom) and doing PPPoE dialing
* Modem directly connected to the OPNSense Box not setting a vlan7

1. installed 24.7.5 -> not working (see attached log)
2. installed patched dhcp6c client on top of 24.7.5 -> not working (see attached log)
3. connected a OpenWRT box in the exact way to the modem as the OPNSense box and let it set vlan 7 -> working
4. reconfigured OPNSense to NOT set the vlan (using the underlying interface directly) and let the modem set the vlan -> working (can provide log if needed, forgot to collect)

Based on this there are three new data points:
* it is no longer sure, that the problem was introduced with 24.x.x (I doubt so). But I reconfigured the vlan thing at the same time (mentioned it in earlier posts already)
* it is no provider side issue
* there is a problem with OPNSense and IPv6 PD when it is based on a vlan instead directly at the physical interface

What do you think how we should go on here, is there anything I can test for you?

I think a bug in the dhcp6 client is not longer likely, more one deeper in the network stack?

Best regards
Robert

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

Hi Franco,

is this still true for 24.7.5 or will things break if I apply the patch/install the package? Or in the other direction, needa the patch/package a adaption for 24.7.5 before trying it?

And should I install one by one and check the effect or both together?

Can do this now, my box has not that much critical traffic this weekend.

Best regards
Robert

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

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

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

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

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