@andresense said in Create makefile package:

Can you tell me where I can find references to variables like these from makefile:

$ {WRKSRC}
$ {INSTALL_DATA}
$ {FILESDIR}

You need to research the format of FreeBSD Makefiles. Start here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefiles.htmllink text.

When I run an iperf UDP Test that involves pfsense as router and a filter reload is done there is packet loss while the filter is reloading. This is especially annoying if an IPv6 Gateway goes down, the filter is reloaded and this affects the IPv4 Link aswell. If pfsense could selectively reload ipv6 only if an IPv6 Gateway goes down that would make things a lot easier.

This was not meant to be a "problem post" but rather a "couldn't we improve by splitting ipv4 and ipv6 rules in 2 anchors" though. My first idea was something that could be done in iptables but not pf: Have a list of rules we want and one with rules we have and issue the commands to make them match. The closest we could get to that is probably splitting up, comparing when we want to reload and only reload if last != current.

@stephenw10 yup but no single source can provide that, and even if I create 2 connections (e.g download from steam and Battle.net at same time) which are independently capable of around 90MB/s, I can’t push much further than 140MB/s. Load on cpu is minimal, so feel like somewhere downstream at the ISP is restricting the bandwidth.

@kiokoman said in Suricata crash log:

@bmeeks
i had this today after upgrading pfsense 2.5 and reboot to the latest revision

Crash report begins. Anonymous machine information: amd64 12.0-RELEASE-p9 FreeBSD 12.0-RELEASE-p9 e23c75c4280(RELENG_2_5) pfSense Crash report details: PHP Errors: [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_3908_pppoe0/rules/suricata.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 999 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_3908_pppoe0/rules/flowbit-required.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 1001 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_3908_pppoe0/rules/custom.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 1003 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_35924_igb2/rules/suricata.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 999 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_35924_igb2/rules/flowbit-required.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 1001 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_35924_igb2/rules/custom.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 1003 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_55009_igb1/rules/suricata.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 999 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_55009_igb1/rules/flowbit-required.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 1001 [27-Aug-2019 20:56:56 Europe/Rome] PHP Warning: filesize(): stat failed for /usr/local/etc/suricata/suricata_55009_igb1/rules/custom.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 1003 No FreeBSD crash data found.

I just upgraded a test virtual machine to the same version without issue. Something went awry with your system during the update. Those errors indicate none of the rules files got created properly. I suggest you delete the package and install it again from the Package Manager menu.

If you have a RAM disk configured, be sure there is at least 256 MB of free space on /tmp.

pfSense is built on top of FreeBSD, so use your Google-fu to research how to analyze FreeBSD crash dumps.

Trying to think who maintains the stuff for snort.. This is related to that I take it..

Prob be easier to just post up the "fix" and who maintains the package/port for pfsense could include it if they agree with the fix, etc.

You might notice that my fix was for a like 1 person ;) But did submit it to freebsd, and it got finally pushed down.

edit: Ah I see @bmeeks is already in your other thread - yeah that would be "the guy" to help for sure!!

These errors should all be fixed in the latest Snort-4.0_4 package for pfSense-2.5 snapshots.

Ahh yes, sorry for the mix up. Had to work late on a migration project last night and I'm kinda behind today.

Nice that's good to know. Thanks!

yikes i hope not :(
did reinstall still issues after installling packages .
all seemed well :( reset is the name of the game i guess.
cause daddy dun f'ed up :(

@bmeeks said in Suricata stopped working on 2.5.0-DEVELOPMENT (amd64) built on Sat Jun 01 20:37:20 EDT 2019:

That does sound interesting. I agree it sounds like a lot of coordination work to keep things straight. So does the user still have to choose the correct package from something like a list, or can pkg make a choice at install time?

If the package has a dependency set, it would have to depend on a specific flavor, so you'd have, say packagename@option1 for the package name with option1 enabled, and packagename@option2 for the package with option 2 enabled. What typically happens is then you'd have meta-ports for either one with slightly different names, and unique dependencies, and the user would choose one to install.

Another way would be to remove a specific dependency from the port and have the installer pick which flavor to install but since that breaks dependency tracking I wouldn't want to encourage that.

@JeGr Thanks!

It does boot but stops outputing to the console after mountroot. Exactly as though it's set to serial console as primary. But it isn't and you can't force VGA/EFI console from the boot loader.
Bigger brains than me are assigned to it. 😉

Steve

Just upgraded to the latest snapshot, 2.5.0-DEVELOPMENT-amd64-20190520-1137, and can confirm that this now seems to be working properly. Thank you for the quick response!