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

@cmcdonald Appears to be back/fixed. Thanks.

You can set the size it rotates at and the number of files to retain in the log settings at Status > Logs > Settings. As long as you have the space you should be able to increase it.

@stephenw10 The Ultra Ethernet Consortium

@stephenw10 Aye that's right

Hi guys, I create simple shell script reports for AbuseIPDB from filter.log file. Maybe it will be helpful to someone. It was tested over a one-week period and works as expected. Here is the link: ttps://github.com/whoami-0x44/abuseipdb-reporting-pfsense

Yes you can choose 2.8.0-beta from the installer menu. Edit: Now 2.8.0-RC

Nope, none of those are a big concern. Some of that could be cleaned up but they are just ugly.

@w0w Seems so or possibly an interaction with if_pppoe and something else within the new beta. Regressing to 24.11 again and symptoms vanish. Reverting to the old backend on the beta seems fine too (albeit with the old pppoe issues). I had to work back again and re-test as I had the test diff patch applied with the revised beta, which drew some doubts on my results for a while. Fat-fingering in a config error when testing is something I try to avoid but you have to admit your mistakes. I'm waiting for the next beta drop really, to see if the changes also impact the issues I see. Opening up all the cores may just be peeling back something that was already latent and just masked by the old backend process. I did do a couple of tests that suggests the upload fq_codel settings may need adjusting against a different workload for if_pppoe; but too early to be sure. I'm also being nudged to try Kea again, as apparently it has matured a bit since its launch. ️

Hmm, it does seem kinda shady! There's no FreeBSD port as far as I can see, though there is one for v2ray which this was forked from. You are asking about adding it as a client to connect to the xrayvpn service only? I'm not really seeing any advantages over existing VPN options TBH.