Messages

@pataps: yay, great, thanks! Among other things AFTR is now natively supported by the daemon (and advertised to the dhcp6c_script as "new_aftr_name") but I made a small mistake with the initial implementation:

https://github.com/opnsense/dhcp6c/commit/60c87d02c

Can you try again?


Cheers,
Franco

Yes, I can confirm it works as expected now. I can see "AFTR domain name" in the dhcp6c logs. Connectivity resorted after restart. Thanks!

Hey,

I've tried to test 1) but sadly dhcp6c fails to establish ipv6 connection despite fetching prefix correctly in the logs. It fails with following message: failed to parse options, malformed DHCP option: type 64, len 21. Revert fixes it of course. Might be something specific to my ISP?

Hi,

I failed to find any answer to this. What are the steps for switching from Development to Community in terms of installed plugins? All have this -devel suffix but after upgrade to community they stay as they were. Do I need to manually reinstall their non-devel versions?

I tried the patch (25.1 beta, with updated base/kernel), and with wan, lan + a virtual ipv6 /64 address (all selected in ntp config) ntp starts up ok :)

Yup, it works great. Thanks franco :)

I guess I spoko too soon. After OPNSense reboot I get the same issue..

Code Select Expand


<101>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 7902 - [meta sequenceId="8"] ----------------------------------------------------
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="9"] proto: precision = 0.109 usec (-23)
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="10"] basedate set to 2024-12-27
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="11"] gps base set to 2024-12-29 (week 2347)
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="12"] initial drift restored to 7.743286
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="13"] Listen and drop on 0 v6wildcard [::]:123
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="14"] Listen and drop on 1 v4wildcard 0.0.0.0:123
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="15"] Listen normally on 2 re0 [fe80::5e85:7eff:fe47:f51a%1]:123
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="16"] Listen normally on 3 re1 [fe80::5e85:7eff:fe47:f51b%2]:123
<102>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="17"] Listen normally on 4 re1 192.168.1.1:123
<99>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="18"] bind(25) AF_INET6 [fdf3:e453:45bc::]:123 flags 0x11 failed: Can't assign requested address
<99>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 8583 - [meta sequenceId="19"] unable to create socket on re1 (5) for [fdf3:e453:45bc::]:123
<99>1 2025-01-12T21:12:00+01:00 OPNsense.lan ntpd 7902 - [meta sequenceId="20"] daemon child died with signal 11

It still doesn't like the virtual ip added to "Lan".

OPNsense 25.1.b_108

I tried the patch (25.1 beta, with updated base/kernel), and with wan, lan + a virtual ipv6 /64 address (all selected in ntp config) ntp starts up ok :)

Yup, it works great. Thanks franco :)

Is this with a specific selection under Services: Network Time: General: Interfaces or using "all"?


Cheers,
Franco

Hi actually it's both. I have "Lan" network with ipv4, ipv6 gua and virtual ip in form of ula/64. I can pick any interface but picking this one breakes ntpd. I also have another similar one, but without ipv4 and this one doesn't do this.

I'll check both unable and patch fixes later today and report back.

Thanks!

I can confirm that using ULAs as virtual IPs in LAN breaks ntpd. As long as lan interface with virtual ip added is selected in the ntpd interfaces list it cannott start saying that it cannot bind to fdxx address. Haven't found any other way around this other than removing virtual ip alias. Although I also think this was already a thing before 25.1.

BUT I have a minor one - on mobile menu button is completely invisible (I guess it's white on white background), but it's there because when blindly tapping where it's supposed to be it works and highlights in dark grey :> Also - new, more white theme looks better IMO.

Can you tell me where, or screenshot with context?

Yeah, sorry here are the white theme screenshots showing same thing as @staticznld:

https://imgur.com/a/Z3AWJz6

Well that's weird,

I deployed it on Proxmox as well, with a single NIC. Deployed it with a vlan from CLI static IP and GW set to production OPNsense without problem.

Regards,
S.

I also upgraded from 24.7 on cloned PVE. Expected mayhem but everything works surprisingly well. No major issues.

BUT I have a minor one - on mobile menu button is completely invisible (I guess it's white on white background), but it's there because when blindly tapping where it's supposed to be it works and highlights in dark grey :> Also - new, more white theme looks better IMO.

Hi,

First, I'm not sure whether I should write separate feedback in this topic or open a new one.

I decided to take part in beta testing and I'm running 25.1 in place of my home setup. So far so good. I'm especially looking forward to PPPoE improvements. Not sure how much new is in 25.1 in comparison to latest 24.7 but still happy about what I've seen so far.

But, I have a question: Since interfaces menu has been reorganised I failed to find point-to-point device logs in the UI. Where has it moved? Or if it was removed, was it intentional or there's a chance it's going to be back at some later point as it's not critical?

Being "blessed" with PPPoE it's useful to take a look there as a first step of troubleshooting down connection. Having this in the UI was nice.

Thanks!

This is a general issue when the DHCPv6 server forgets the lease or rejects it. Does it not auto-recover after 10-30 minutes? I'm not suggesting that's ok, just trying to get a baseline since I've worked on fixes for dhcp6c regarding this situation.


Cheers,
Franco

Haha, internet is so essential that I was not patient enough to try to see if this fixes itself in up to 30 minutes :D At least when it happened during the day. Come to think of it I don't know if it ever happened during the night and I haven't noticed. I will try to monitor that more closely.

EDIT: Actually I remembered one day waking up to internet being MIA and once I checked the logs and confirmed just now the session refresh >2h earlier and it didn't fix itself until WAN config re-save.

I have some feedback regarding PPPoE + native IPv6 by DHCP. I noticed that when (I think) ISP forces PPPoE session refresh then OPNSense fails to renew IPv6 DHCP lease. I have static /56  and from my understanding of logs ppp log seems to be ok, but "opnsense", dhcp6c and rtsold, in consequence are not happy. Way around it is to refresh WAN interface configuration. This is not related to recent release. It happened even on 24.7 but it happens very early (I noticed too few occurrences to figure out a pattern)

Aside from that PPPoE rework works great on every release for me.

Hah, I haven't thought it's going to be that easy! I'll be careful with patching from now on, I suppose :) I will definitely test out the development version.

I appreciate your effort Franco, best of luck!

Neat, thanks for confirming.

Yes, correct. The patch should apply to 24.7.1 as well, but the reboot might get in the way.

Since this code is a change of behaviour in some ways most of it needs to be locked away for 25.1 I'm afraid. We could hook you up on the development version which would do what you need without patching once 24.7.2 hits.

I'm aware of what I'm suggesting but I also don't want to surprise other PPPoE users right now and those that don't have issues right now will need to test this too, which could introduce other problems for you so the development version would give us a quick feedback from you over time as well.


Cheers,
Franco

I understand. I would appreciate some more info on hooking up to development version in advance :)
Also, worth asking I guess - Am I correct thinking that I cannot simply apply same patch as above after each update until 25.1?

Good. Do you get your PD?

I'll trickle the relevant commits into the development version after 24.7.1 is out tomorrow.

I don't want to squash the full history yet the back-and-forth code changes can probably be removed.


Cheers,
Franco

Yes I did! Now after every boot my VLANs get propped IPv6. It works great :)

If I understand correctly, in order to preserve this improved functionality I should NOT update to 24.7.1 and wait for 24.7.2?