I've experimented a lot with code, here is what I did to make it work with “buggy” config. pppoe_ha_event.php . The biggest difference is that we shouldn’t run pfSctl -c 'interface reload <friendly>' (e.g., wan) if the PPPoE interface already exists. We only do that if, for some reason, the interface doesn’t exist. The shell script does the same, by the way. Changes: MASTER bring-up path updated: on MASTER we now first try ifconfig <real pppoeX> up if the PPPoE interface already exists; if it doesn’t, we fall back to pfSctl -c 'interface reload <friendly>' (e.g., wan). (Original only triggered the pfSctl reload path.) CARP event suppression window: after switching to MASTER, the script temporarily ignores further CARP events (~60 seconds total in two 30s steps) to prevent flapping during stabilization. Staged targeted reconciles: after ~30s (still MASTER) run a focused reconcile; after another ~30s run a safety reconcile. These checks act only if state truly differs (see next point). Smarter reconcile rules: if MASTER and PPPoE already has a valid IPv4 P2P or global IPv6 address, do nothing; if BACKUP, ensure the real PPPoE iface is down. BACKUP/INIT handling refined: on BACKUP/INIT we bring the real PPPoE interface down. On INIT we first re-read actual CARP state; only bring the PPPoE real iface down if the current state is truly BACKUP. Actually ignores init state, only backup brings pppoeX down. Quiet periodic health check: every 5 minutes, perform a low-noise reconcile (skipped during the suppression window) to keep state honest if it missed for some reason. - this feature currently broken and I don't think iti is needed anyway @perrin I apologize for the possibly clunky AI-assisted code changes—I hope it works for you too. For now it’s been running quite stably on my side. Failover is instant and stable. Thank you for bringing it to life in a more acceptable form than what I had.

@stephenw10 nothing in the logs for the DHCP client. I will enable the debug logging and check the logs upon the next reconnect

@Gertjan I do not actually have access to my ISPs upstream router. That is why I decided to install a pfSense box and (by phone) asked my ISP to put their router in bridge mode. When my pfSense WAN DHCPv6 Client Configuration has "DHCPv6 Prefix Delegation size 64" then my ISPs router gives me the Delegated Prefix: WAN/0 (2001:8a0:fcc2:6600::/56)/64, that means: my ISP is delegating a /56 prefix to my pfSense. This is the 2001:8a0:fcc2:6600::/56 part - the big block of addresses my ISP is giving me to work with. my pfSense is specifically configured to request a /64 for its WAN interface and also to handle the delegation of a /64 (the WAN/0 part refers to the first /64 out of the delegated /56) to its LAN. This means that out of the 2001:8a0:fcc2:6600::/56 block my ISP gives me: 2001:8a0:fcc2:6600::/64 (mine is 00 you e2) is being used by my pfSense LAN interface (as indicated by WAN/0). This leaves 2001:8a0:fcc2:6601::/64 through 2001:8a0:fcc2:66FF::/64 available within that /56 block for further delegation to pfSense clients upstream. So, I have plenty of /64 subnets remaining from the /56 to delegate, for pfSense to give to my internal clients. But that stuff is all good for me, my problem still remains the same; my internal machines, all with latest ubuntu OS & IPv6, get DNS Resolve registrations wrong: servers (with systemd-networkd) & register on the incorrect domain unknown.home.arpa desktops (with NetworkManager) & register on the correct domain home.arpa can someone help with this?

@bmeeks Yep, in this case I am just talking about the kernel source. The head for CE kernel is still public from what I can see, its for whatever reason the 2.8.0 and 2.8.1 branches are not.

@w0w thanx, now all typing-in works well and fast

Also see: https://docs.netgate.com/pfsense/en/latest/development/develop-packages.html

Yup, seeing that here. Likely related to the upstream firmware API issue. But those drivers shouldn't need to load anything without the hardware present anyway.

I suspect the root cause here is the same as this: https://redmine.pfsense.org/issues/15770

@luckman212 I use a manually added FreeBSD package, 'munin' that came with a file to be placed in /usr/local/etc/rc.d/ As per pfSense needs, I renamed it - added the .sh extension, and now the munin process get started at boot, and stopped at shutdown. I made this install many years ago, and as far as I know, the script only executes during boot and system shutdown. Not for network or other events etc. If FreeBSD would look like a Debian system (or clone) using init or systemd I could tell you way more, and I even think pfSEnse isn'tv really FreeBSD (no surprise, at it is, and it isn't ^^). Look at the kea script for an example, the first 3 / 4 lines. Afaik, pfSense it self, see here /etc/, all de rc...... files - for example rc.bootup - will all all these files. pfSense handle the hardware and software system events, and call whatever is needed, if system processes like 'unbound' needed to be restarted. So : and also during certain system events (e.g. interface link changes, IP address changes, and gateway events). never saw that happening with my own processes - as pfSense isn't really aware that these are running ones the system is up.

Not currently, it would require some development.

@dennypage said in pfsense-tools.git clang gcc: @phil80 said in pfsense-tools.git clang gcc: portsnap fetch properly fetches freebsd ports collection FWIW, portsnap is very dead as far as the FreeBSD folk are concerned. All references to it were removed from the documentation 5 years ago, and its use is no longer supported. The original announcement is here: [HEADS UP] Planned deprecation of portsnap. Thank you for the reminder. I usually only use Latest. I always use git for collaboration In short life or one use jails, portsnap is way faster to fetch than git for one package compile Based on your linked article, I'll favor git in the future

Mmm, so prevent source tracking for specific IPs or subnets? I did wonder if sticky connections could be per gateway group. That seems like it should be possible. You could then use rules to route specific clients or subnets to a non-sticky group.