@chris-doldolia Hello! You can safely make configuration changes on a running pfSense firewall, it's designed for that. Most settings apply immediately without needing a reboot, though some services (like IPsec, OpenVPN, or interface changes) may briefly interrupt traffic when restarted. Just make sure you have console or alternate access in case something goes wrong.

@stephenw10 Correct, I've waited about 10 mins and gave up. The config is 201KB. Send me a link to up load it.

Well, same here.

After the update, it stops here:

d39683aa-70f6-4351-a550-cc26179aef4a-image.png

Version 2.7.2, it starts normally.

cede8b80-c7ff-4e1f-b6d3-fda3be8aebde-image.png

@stephenw10 said in PPPoE: Problems getting an IPv6 address on reconnection and other problems:

That's with the new test patch for if_pppoe?

Yes.

One more thing: the link always comes up fine after a clean boot. Also I have better luck if I don’t click Connect WAN immediately after the page reloads from Disconnect WAN. It feels as though something is still running and hasn’t fully released when the new session starts.

Also, this message seems new—I don’t recall seeing it before the last build/patch :

2025-06-19 05:35:10.946591+03:00 kernel - if_pppoe: pppoe0: failed to clear IP address: 49

Managed to write a script that updates it. I found a directory /var/preserve that according to some random person somewhere will survive OS updates. There doesn't seem to be much documentation on this.

I've now set it as a cron job to run every hour, but it would be nice to have some kind of trigger. I feel like this whole thing could be made a lot easier inside the built-in Dynamic DNS updater.

Hmm, so in both those situation is does eventually boot?

We've seen some other device hit those but AFAIK they never boot from there.

Try booting verbose to get more output from the 2nd scenario.

@johnpoz I am glad you also noticed it, I see it a lot on my proxy I decided to block it and see what breaks but nothing changed so far. I also have the DNS manually set on the iMac, so it should not attempt to use DoH

Hmm, and that's repeatable after every reboot?

And does it initially show an error in the dashboard widget for updates?

@wickeren Honestly, at least peak performance of the interface appears to be about the same.
I was not using any explicit CLI options, including those above, just reconfigured all PCIe devices in libvirt's XML definition of the domain.
It is still atrociously slow comparing to Linux performance, there I have no problem getting well over 10 Gbps on virtio network interfaces.

Interesting. I suspect that might have been a coincidence. But, as I say, adding static ARP can make troubleshooting more difficult. If a MAC is typo'd things just fail silently.

Hmm, no errors shown there but the daemon log should have a lot more in it....

The only time I've ever seen that is after restarting the installer without rebooting. But I assume you are rebooting here between attempts?

@eeebbune
Yes, it's recommended to assign the IP to the bridge. And in case, that any member interface is hardware base, I'd change this.
If all interfaces are virtualized, I think, it makes no big difference.

@pst Cool thank you I will get it updated and see how I do. Fingers crossed.

I raised redmine #16275 on this.

... and to manually remove unconnected queues one can use

/sbin/dnctl queue list

followed by

/sbin/dnctl queue delete n

where n is the queue number

I don't see those specifically only:

[2.8.0-RELEASE][root@m370.stevew.lan]/root: ls -ls /usr/local/www/apple-touch/ total 26 5 -rw-r--r-- 1 root wheel 3669 May 20 15:25 apple-touch-icon-ipad-76x76-precomposed.png 9 -rw-r--r-- 1 root wheel 7260 May 20 15:25 apple-touch-icon-ipad-retina-152x152-precomposed.png 5 -rw-r--r-- 1 root wheel 2965 May 20 15:25 apple-touch-icon-iphone-60x60-precomposed.png 9 -rw-r--r-- 1 root wheel 5640 May 20 15:25 apple-touch-icon-iphone-retina-120x120-precomposed.png

So those requests are from Safari in MacOS?

To clarify on what's happening with the pending gateway, in your instances IPV6CP negotiation establishes the IPv6 endpoints on the PPP session, and the link local peer address is intended to be the gateway for your DHCPv6 assigned address, with no RAs to nominate a gateway. The interface gateway is correctly set to the address of the peer endpoint by the driver, but the existing LL address on the interface is not updated with the remote destination address, and that destination address is expected to be present in order to identify the PPP gateway when the gateway monitoring setup is triggered. The patch intuits the PPP gateway from the routing table instead of the interface address in the IPv6 case. I'm working on a correction to the driver that should eliminate the need for this special case handling.