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

Surely pfSense is not the first project to ask that?  Can we learn from someone else (RedHat, FreeBSD, KDE, mozilla, maybe even Cisco…)?

The Fedora project had (and probably still does) volunteer translators, with one lead person per language.  I think there was some infrastructure or guidance set up for them, maybe something is there?

Fixed for me also with same snapshot.

https://forum.pfsense.org/index.php?topic=77143.0

will probably need adjustments, but it'll get ya started

@dylanh724:

EDIT: Sorry wrong thread! Can someone move me to Development area? Thanks/sorry .. didn't realize there was a section~

Hi,

I'm pretty new to php until I started working with PFS. I find myself pretty good at editing, but as for making new files .. not so much:

#!/usr/local/bin/php -f Is this above code required for all php files within PFS?

This means you can call the file in shell if you give it +x.

require("config.inc"); If I put this up top, this means I can use code from config.inc, right? Like imports from .NET?

YES you can call functions on that file.

I noticed that files are "included" very generally – like 'xx.inc' rather than '/etc/xx/xx.inc' .. does this mean there's a file I need to edit to include any new files for easy importing such as this?

pfSene uses PHP and exploits as much as possible its configuration settings.
The short way is used since a include path is setup for php where to find things.

Finally, can any of these files be called from captive portal files? Can a captiveportal-customupload.php call , say, config.inc?

Surely there is nothing preventing that since even the existing page does that.

Much more clear now!

Fixed, thanks.

Yeah they were missing bits, I deleted those. The most recent ones up now work fine.

Ahh, I didn't see that one, thanks.

Access the tools repo and see yourself.
Unless you use pfSense port it will not work.

It's a bug, reproduced in 1 minute on a system as you describe with LAN and OPT1.
And yes, the bug is only if you put "none" into the DHCP gateway field of some interface and then the DHCP gateway field of some later interface is left blank.
Fixed by this code change: https://github.com/pfsense/pfsense/pull/1511

Well, 2.2.1-DEVELOPMENT-i386-20150213-1429 works, though the PHP is clearly severely miscompiled. Should not link against the outdated libpcre at all. Plus:

Warning: PHP Startup: Suhosin was compiled without session support, which is probably not what you want. All session related features will not be available, e.g. session encryption. If session support is really not needed, recompile Suhosin with -DSUHOSIN_NO_SESSION_WARNING=1 to suppress this warning

upon further investigation it seems filter.inc has a function called filter_configure_sync where everything happens so is it fine if i add the on and off code there or do i create a new function for it?

IMHO bogons should be just for variable address ranges that would be routable on the public internet as "normal" IP addresses, but that are not expected to actually appear because of things like:

as yet unallocated allocated to a now defunct organisation and not yet reclaimed for re-allocation known to be squatted
…

The pieces of fixed address space reserved for particular purposes in RFCs should not be in bogons and are better handled by using aliases or predefined lists for the purpose, so the user can control those as they need to.

+1 for year2015  ;D

First check if freebsd can run on it.
Second is to build pfSense for it.
Than follow-up anything else.