@w0w said in pfSense GUI search alpha version for testing: This icon alignment bug seems to depend on the theme Maybe you previous approach is easier. With the overlay it's probably a good chance it's all over the place :)

In my first report, I reported "IPv6 Address is set but not reachable", but found a condition to obtain global reachability. (I checked the global response in pfSense's "Diagnostics > Ping".) My ISP has a limit on the number of PPPoE sessions available. My ISP won't allow me to open a new PPPoE session until it knows the previous one has been closed. Also, if I disconnect a PPPoE session without manually closing it, my ISP takes about 5 minutes to recognize that the PPPoE session has been closed. These specifications make the following difference: (a) If I reboot pfSense with manually closing the PPPoE session, pppoe0 links up and the IPv6 address is set before "Bootup complete". (b) If I reboot pfSense without manually closing the PPPoE session, pppoe0 links up and the IPv6 address is set after "Bootup complete". In case (a), the ping passed, but in case (b), the ping failed. When I checked "Use if_pppoe kernel module for PPPoE client" to enable if_pppoe, this fell under case (b). As a result, the ping failed. Here are some other facts I have confirmed: [PPP log] Each time a PPPoE session is established, the message "failed to set default route 17" may or may not be displayed. The message is not displayed after bootup. The message is displayed after executing the "ifconfig pppoe0 down/up" command. The message is not displayed after clicking the "Disconnect/Connect" button in Interfaces Status. Every time a PPPoE session is established, the message "failed to clear IP address: 49" is displayed. [Interfaces Status] The "Gateway IPv6" item is not always displayed. It is not blank. The item itself does not exist. The "Gateway IPv6" undisplayed issue is unrelated to the message "failed to set default route 17" displayed/undisplayed issue. The "Gateway IPv6" undisplayed issue is unrelated to Ping pass/fail. In case (a), Ping passes. [DHCP log] Basically, the message "add an address [IPv6 Address]/64 on em1" is displayed each time a PPPoE session is established. The message is displayed before or after "Bootup complete" and the IPv6 address is set. The message is displayed after executing the "ifconfig pppoe0 down/up" command and the IPv6 address is set. However, after clicking the "Disconnect/Connect" button in Interfaces Status, "Sending Solicit" is displayed repeatedly, no message is displayed, and the IPv6 address is not set. After that, even after executing the "ifconfig pppoe0 down/up" command, "Sending Solicit" is displayed repeatedly, no message is displayed, and the IPv6 address is not set. If I reboot again, the message is displayed and the IPv6 address is set. [Ping] In case (a), the ping passes regardless of whether the "failed to set default route 17" message is displayed or not. In case (a), the ping passes regardless of the dpinger Status (Running/Stopped). In case (a), the ping passes regardless of the Gateways Status (Online/Pending). In case (a), the ping passes even after executing the "ifconfig pppoe0 down/up" command. [Gateways/dpinger] When dpinger Status is Stopped, nothing is displayed in the Gateways Log. If I set Gateway's IPv6 Link Local to "Monitor IP", the dpinger Status is displayed as Running. Then, "send_interval" and so on is displayed in the Gateways Log. The dpinger status (Running/Stopped) is unrelated to Ping pass/fail. Ping pass/fail is determined by case (a)/case (b). The Gateways Status (Online/Pending) is unrelated to Ping pass/fail. Ping pass/fail is determined by case (a)/case (b). Based on the facts presented, I assume that the issue of "Gateway IPv6" not being set and the issue of ping failure are independent issues.

@g405tsh311 the online installer you "buy" for $0 in the Netgate store gets the versions dynamically, 2.8.1 is among them. [image: 1757746372965-screenshot-2025-09-13-at-08.49.56.jpeg]

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

@perrin said in new if_pppoe Backend - getting HA/CARP to work like in MPD: @zjamali yep, same here. I'll debug why it is not working on the first VIP later. Can you temporarely work with a different VIP? Should be OK. no issue

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.

@kprovost you've been kind enough to review, test and merge the PR. Maybe you could help me do a similar kind of build as you did?

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.

OK so it looks like you had two issues: The installer didn't work as you expected it to but you were able to get 2.8 installed and booted. The resulting install didn't behave as you expected. That's independent of the installer and 2.7.2 would have behaved identically in that situation. So after install you assigned two interfaces, pfSense names them WAN and LAN but any interface can be anything. And you configured them both to be DHCP since both subnets already have a DHCP server? The typical subnet conflict that users hit when installing behind another firewall if that pfSense uses 192.168.1.1/24 as the default LAN address and that subnet is also used by the upstream firewall WAN side. I assume you didn't hit that since both subnets already existed in your network so must be using different subnets? What are they? However you then say you set the LAN back to a static address? Presumably in the same subnet? By default pfSense creates firewall rules on the LAN interface to allow access to the webgui there. That applies whether the LAN is static or DHCP. How exactly were you trying to connect? From where?

Currently nothing I'm aware of but going forward some functions will likely be written in go and hence in the Nexus package. Obviously that assumes the Nexus package is always present so it is automatically re-installed at upgrade.

@cybrnook It looks if you are referring to the pimd engine version [image: 1752688668863-854cb5be-fd74-43b0-848a-b83df5637c1b-image.png] Which is quite old, and as far as I know not working under FreeBSD. I have compiled the never released pimd-3.0.b1 version (using FreeBSD15 current).