Yep, follow those rules in the style guide, make the edits on GitHub (or in a local Git repo that you make on your system) in a separate branch and do a pull request to the master branch of the pfSense repo(s). The ESF guys will back-port to old branches if appropriate.

Even without using ALTQ, we could just use limiters with fq_codel for a "set it and forget it" AQM config with fair queuing and AQM (sort of like sqmscripts for OpenWRT/LEDE). Sure, this wouldn't be for everyone, but I can see it as being quite valuable for many folks.

The login beep isn't an action that happens on purpose, it's a byproduct of the way the login is logged. It would be possible to make an option for this but it would likely turn out to be annoying for most. You may as well hand edit a call to beep into rc.newwanip to beep when it's called.

@kpa: @stilez: @kpa: 2. Forget the idea of localizing those IDs, it's not going to happen. That might be a misunderstanding. It's the plain-text descriptions, not the sysctls themselves, that I referred to. I started to wonder if that's what you meant  :) It's that the config file "sysctls" section currently looks like this: <tunable>vfs.read_max</tunable> <value>default</value> but the meaning of vfs.read_max should be moved out of the config file and read as needed from the system itself, or stored as strings/gettext() in the router code.

Not usually. You can run that script and if the diff looks sane (just your own update), submit that as a PR as well, perhaps the same PR as the other change, but it's something we usually run before each release anyhow to make sure things are caught up. Sometimes that file gets inadvertently hand-edited and the diffs make less sense so they need manual review, but at the moment things are quite good there. Running the script produced only a one-line diff.

Thank you. Just for the record to others. The sign.sh is a script describe in pkg repo manual from freebsd. The line in builder can be replaced to this local script.

@cmb: Having all the history does come in handy on occasion, and doesn't have any negative impacts for me. That poor SSD getting hammered every time checking out a branch, for the sake of occasional ancient history.

As a diagnostic learning tool, take a look at the comprehensive output of status.php.  (I don't think it's a gui menu choice, just go to https://192.168.1.1/status.php, for example). Find an area you want to learn about, then read through /usr/local/www/status.php and see how that output was generated.  A far cry from what you are asking for, but still a good place to learn

I have managed to successfully build and run the above simple example as well as the pfctl. For those interested, here are the steps I took: a) downloaded source from https://github.com/pfsense/FreeBSD-src b) make buildworld c) compiled the above test with``` clang -I/usr/obj/usr/home/ethicius/develop/FreeBSD-src/tmp/usr/include -o sample sample.c ~~I still don't quite understand what the underlying problem is. Could it be that the _IOWR macro constructs a different number? I might have to disassemble those two files to find the culprit…~~ It's simply just a different API. pfSense has modified sys/pfvar.h and related files.

Thanks for help, now it works :)

apply_patches.php is not part of pfSense_BASE. its is part of the system_patches package. you could try reinstalling/installing system_patches if you really wish to manually copy: https://github.com/pfsense/FreeBSD-ports/tree/RELENG_2_3_0/sysutils/pfSense-pkg-System_Patches/files/usr/local/bin

Same discovered here  8)