Although the Thread is old.

Its also working with PCBSD 10.1.2.

@Hobby-Student:

Update:
EDIT #1:
Downloaded this one https://github.com/pcbsd/pcbsd/tree/releng/10.0 and did

/src-sh/libsh -> make install /src-sh/pbi-manager -> make install

Yes, what you say is correct. And it is all a bit of a pain in PHP, you have to constantly check isset() is_array()…
I have protected all the unset() in /etc/inc/upgrade_config.inc with this pull request:
https://github.com/pfsense/pfsense/pull/1773

I guess it was a bit much for the devs to dump into 2.2.4 just days before release. I can't see anything that would go wrong with it - it can only be better - but it does need to have some upgrades from old configs run against it just to confirm all is well.

It was intentionally added. It's useful for a variety of things. Two immediate things were Azure and some testing automation we're doing.

Thanks for the feedback.

After the last of our changes on Friday, we had an APU and ALIX running power cycles over and over in a loop while permanent rw mounted on the slowest SD/CF I could find. Each went through 1000 power cycles with no issue. IP PDUs are handy. :) Only certain cards seem to corrupt themselves easily in that circumstance. A SanDisk CF even with SU+J and permanent rw didn't break. The Kingston CF I used for the 1000 cycles never made it more than 2-3 power cycles left rw SU+J.

The last part on config writing is being tested right now. The basic case, making a config change and immediately pulling the power, was fine last week. The enclosing directory wasn't being fsynced though, which meant if you did something insane like write_config() in an endless loop called at startup and drop its power right in the middle of that loop, you could be left with a wiped out /cf/conf/backup/ because it overwrote the entire history in 1-2 seconds of the loop and that wasn't fsynced. If you hit the exact right (or wrong) moment, you could end up with a missing config, and no backups to restore. That's about a 1 in 200-300 tries occurrence where you're writing the config in a non-stop loop when power is lost, and probably impossible to encounter in any reasonable real world circumstance. But even that scenario should be fine now. Two systems running in a power cycle loop right now to confirm that. Leaving that running all night.

Yeah they hadn't gotten old enough to be cleared automatically and didn't do so manually until now. They're gone.

@Derelict:

I am just hoping that if anything significant happens security-wise we will see an update for 2.1.5.  Until limiters are fixed 2.2 is simply not an option (at least for me in a couple cases.)

Highly unlikely. We were hoping 2.2.3 would be the last 2.2.x release even, so we could focus more on 2.3. But 2.2.3 has a couple small issues that need addressing so we'll be putting out a 2.2.4 in the near future.

I'm all for releasing more often. In addition to keeping everyone more up-to-date, so long as there are few if any regressions then it's better than letting bugs or security issues sit out there for longer periods of time.

Some people also fall into the false trap of thinking a project is inactive if they do not release very often. If you check our repositories you will see we are very active, but when we go for long periods between releases people seem to think the project is dead or suffering, which is not the case.

While the particular code and implementation of a feature in PHP may change to Python, the logic and process are more important.

Sure there will be a large amount of work involved converting things over but the language is mostly the nuts and bolts of it.

We're more focused on 2.3 at the moment, which has another similar issue. Right now there is a significant amount of work that's happened to convert the GUI to bootstrap which itself is quite a distance away from work in master that has had other, parallel fixes. Merging the two together will be an interesting process.

Right now I wouldn't worry so much about PHP vs Python as much as worrying about the logic and structure/design of the code being sound and easy to follow. Adding even more documentation than usual in the code would also be nice, especially expected inputs/outputs and/or states when defining new functions.

It's being done to make progress in pushing toward pkg-friendly packages. Had to happen that way since "our" package version is being used in a meta-package which then depends on the actual binary package. Not sure what the plan is on exposing those versions again but I believe it's on the roadmap.

[2.3-DEVELOPMENT][root@pfsense.localdomain]/root: pkg search pfsense-pkg pfSense-pkg-Asterisk-0.3.1 pfSense-pkg-AutoConfigBackup-1.28 pfSense-pkg-Avahi-v1.09 pfSense-pkg-Backup-0.1.6 pfSense-pkg-Cron-0.1.9 pfSense-pkg-FTP_Client_Proxy-0.2 pfSense-pkg-Filer-0.60.1 pfSense-pkg-Lightsquid-2.41 pfSense-pkg-Notes-0.2.4 pfSense-pkg-Open-VM-Tools-1280544_10 pfSense-pkg-OpenBGPD-0.9.3_2 pfSense-pkg-Postfix_Forwarder-2.4.2 pfSense-pkg-Quagga_OSPF-0.6.5 pfSense-pkg-RRD_Summary-1.1 pfSense-pkg-Sarg-0.6.4 pfSense-pkg-Service_Watchdog-1.6 pfSense-pkg-Shellcmd-0.6 pfSense-pkg-System_Patches-1.0.3 pfSense-pkg-TFTP-2.1 pfSense-pkg-apache-mod_security-devel-0.43 pfSense-pkg-arping-1.1 pfSense-pkg-bandwidthd-0.5 pfSense-pkg-bind-0.3.9 pfSense-pkg-blinkled-0.4.3 pfSense-pkg-darkstat-3.0.718 pfSense-pkg-diag_new_states-0.2 pfSense-pkg-dns-server-1.0.6.21 pfSense-pkg-freeradius2-1.6.12 pfSense-pkg-gwled-0.2.1 pfSense-pkg-haproxy-0.23 pfSense-pkg-haproxy-devel-0.23 pfSense-pkg-iftop-0.17 pfSense-pkg-imspector-0.3.2 pfSense-pkg-iperf-2.0.5_1 pfSense-pkg-ipguard-0.1 pfSense-pkg-mailreport-2.3 pfSense-pkg-mailscanner-0.2.12 pfSense-pkg-mtr-nox11-0.85_2 pfSense-pkg-netio-1.26 pfSense-pkg-nmap-1.3 pfSense-pkg-ntopng-0.5 pfSense-pkg-nut-2.0.4 pfSense-pkg-olsrd-1.0.2 pfSense-pkg-openvpn-client-export-1.2.16 pfSense-pkg-pfBlockerNG-1.09 pfSense-pkg-pfflowd-1.0.3 pfSense-pkg-routed-1.1 pfSense-pkg-siproxd-1.0.3 pfSense-pkg-snort-3.2.4 pfSense-pkg-softflowd-1.1 pfSense-pkg-spamd-1.1.2 pfSense-pkg-squid-0.2.8 pfSense-pkg-squidGuard-1.9.14 pfSense-pkg-stunnel-5.07 pfSense-pkg-sudo-0.2.5 pfSense-pkg-suricata-2.1.5 pfSense-pkg-varnish-0.2.4 pfSense-pkg-vnstat2-1.12_3 pfSense-pkg-widentd-1.03_2 pfSense-pkg-zabbix-agent-0.8.5 pfSense-pkg-zabbix-proxy-0.8.5

And then

[2.3-DEVELOPMENT][root@pfsense.localdomain]/root: pkg install pfSense-pkg-sudo Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: pfSense-pkg-sudo: 0.2.5 sudo: 1.8.13 The process will require 2 MiB more space. 455 KiB to be downloaded. Proceed with this action? [y/N]: y Fetching pfSense-pkg-sudo-0.2.5.txz: 100%    5 KiB  4.6kB/s    00:01    Fetching sudo-1.8.13.txz: 100%  451 KiB 461.8kB/s    00:01    Checking integrity... done (0 conflicting) [1/2] Installing sudo-1.8.13... [1/2] Extracting sudo-1.8.13: 100% [2/2] Installing pfSense-pkg-sudo-0.2.5... [2/2] Extracting pfSense-pkg-sudo-0.2.5: 100%

And then some errors because it's not 100% there yet, but you get the idea.

All in due time.

Yes that would be good, choosing the site for "what is my IP" would be good, and open to potentially use private sites setup for the job.
Nevertheless this Opendns feature 'myip.opendns.com' is very clever. They use a fast service used to discover IPs and respond with the requester IP.

I guess behind this was the need or the PHP code to handle properly the case when the value is not present in the config. There are many values like this which are assumed to some default in the php code in the case the definition is missing from the XML. That requirement makes indeed the programmer to use inverted logic variables. Thank God the inverted logic is suggested by the variable name…

I've seen cases where the PHP code explicitly deletes (unsets) the value from the config file for the negative value, and sets it to "true" in the config file for the positive value. There's no possibilty to ever see "false" in the XML config file for that variable, although the parsing code handles that too.

Is a app for captive portal we are trying to develop.
  We are working with php-mysql, but we work with php-mysqli on other os like freebsd or centos.
  For the reasons we have, some functions that the old driver doesn't have.

On stock FreeBSD, you can't freebsd-update to get fixes that aren't in a stable release yet. The associated commit there is only in 10-STABLE. You'd have to svnup stable and build world and kernel.

In our case, we backport fixes along those lines and include them in our releases. 2.2.3 snapshots are available and the fix for 195802 was added today. If you could help test that and report back, it'd be appreciated.

I wonder if there is an official pfsense splash.bmp???

Maybe this sparked his ire. Allow me to rephrase.

I wonder if Pfsense has an included image in the theme that would be appropriate.

some cable providers/modems send out private ip's by dhcp when the coax-line goes down …
so then pfsense would get a private ip and might think it's gateway is online when it isnt

So, I had another WTF instance… upgraded an i386 install to amd64 (by accident, apparently there's still absolutely no check/confirmation anywhere, sigh). All went well except for the WTF moment and manual hard reset required. Now, some packages reinstalled. Couple of days later, I thought to use nmap. Hmmm. This idiotic PBI thing picked up an i386 stale libpcre.so.3 (mind you - it ships its own bundled PCRE) and refused to do anything.

Incredible garbage.

Use the already-connected function described by Gert-Jan in this topic:
https://forum.pfsense.org/index.php?topic=77143.0

Add a query for cpentry[4]

Yes, that is a latent issue waiting for some sucker to try and call it with an IPv6 address!

subnetv4_expand() is called directly from a couple of places in the base system and works.

subnet_expand() is not called by anything in the base system.

subnetv6_expand() is only mentioned inside subnet_expand()

and yes, I can't imagine anything that would require and handle subnetv6_expand() of a /64 (or bigger)!
The only small use for this would be in some places where there are pools. e.g. for V4 it is used in vslb.inc where people can have put a virtual server pool by specifying a "subnet" like 10.11.12.8/29 gives a pool of 8 IP addresses. The front-end GUI code limits it to a maximum size pool of 64 (x.x.x.x/26).
I guess the same possibility of having a group of servers with IP addresses in a tiny IPv6 "subnet" would also work.

The reference to a non-existent function was introduced in 2012 by:
https://github.com/pfsense/pfsense/commit/0917cb214b2bbf7f4b374c901c642987fc4ac63b