Messages

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?

Ok, so far so good. :)

Finished the POC: https://github.com/opnsense/core/commit/e6f0ac158dc

# opnsense-revert opnsense && opnsense-patch e6f0ac158dc

If all goes well it should start dhcp6c automatically now in the latest config you mentioned.

IPv4 connectivity setting is gone now and the default. You need it anyway since you want DHCPv6 over PPPoE.


Cheers,
Franco

Wow, amazing! Can confirm dhcp6c starts automatically now :D Thank you Franco :)

Suppose now is as good as ever to work on this while there are testers? :)

DISCLAIMER: I have worked on PPPoE for many years with users, but I do not have a setup to test. I can verify the config looks correct and mpd5 starts, but that's about it.

https://github.com/opnsense/core/commit/84a6d3ad

What I did:

Decouple IP modes from the decision that mpd5 daemon is going to be used. It's now possible to set IPv4 None and IPv6 DHCPv6 and still run in PPPoE mode if the PPPoE device is assigned to WAN.

What I didn't do yet:

Wire DHCPv6 to the IPv6 event in case PPPoE only runs on IPv6. I'm not sure which way to go. It also requires "IPv4 connectivity" changes that I wanted to do anyway because this doesn't make any sense when only IPv6 is acquired. But in the end only the user knows if we should trigger further connectivity on IPv4 or IPv6 tunnel establishment.

Feel free to try and tell me how it goes:

# opnsense-patch 84a6d3ad

(This is especially helpful with people already using PPPoE successfully.)


Cheers,
Franco

This is awesome! I can confirm after brief testing, that after changing ipv4 configuration type to none and unchecking use ipv4 connectivity my connection works great. I still need to manually start dhcp6c for some reason, but that is another story.