@stephenw10 kvm creates a bridge making the physical lan card available to pfsense, other virtual machines, and the kvm host. Since this is a bridge to lan, other stations are also connected via physical ethernet So whatever is on physical network and is policy routed to ppp connection doesn't work. (but can ping) It works great if policy routed to dhcp/static wan connections. The policy is unanimous. all lan connected networks to ppp wan. Whatever comes from physical doesn't work. whatever comes from virtual machines bridged to the same vlan as pf lan interface works. as for dco, virtual machines connect via openvpn with dco enabled work fine, physicaly connected machines can only ping remote stations. all vlan configuration is done at the kvm and management switch level. pfsense is presented with different virtio interfaces. I have thought that it could be a mtu issue, however pinging with df flags reveals no issues too. (and dco can't be mtu too) Disabling dco, allows all machines to connect via the vpn (but doesn't solve the ppp wan issue)

@Phil2025 said in New PPPoE backend, some feedback: I will try the ppp-ipv6 pppoe0 up command next time rather than a gateway service restart. Hmm, yeah, that would be an interesting result if you can replicate it.

I would first try to make it work in FreeBSD where the package exists.

@IonutIT thanks

New package for 25.11 is ready for testing. pkg add -f 'https://raw.githubusercontent.com/woffko/pfSense-pppoe-ha/refs/heads/main/pfSense-pkg-pppoe-ha-0.1.3.pkg'

Aha, nice!

@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.