For my purposes, I will manually set my skew values by not syncing VIPs automatically, however the 255 value is a legitimate bug, and I've updated the bug report and made a pull request in github with the fix:
https://github.com/bsdperimeter/pfsense/pull/127
http://redmine.pfsense.org/issues/2012

Thank you Jim,
I have gotten past the part where it normally errors out. It is building kernels now and it should finish normally from here.

I'm not sure but it can be about php.ini file.

Using this like reference:
http://lists.shmoo.com/pipermail/hostap/2005-March/009879.html

The TKIP mode works. AES seems not compatible

That is very strange because that function is part of util.inc which should already have been included at this point.

I see that this is in the upgrade code, I'll have a look.

Sure, I'd like to see the scripts and the instructions. Thanks!

I'm inclined to think this is a priority. Checkpoint released an amazon ami they charge $2000 . The question is do you want to own the cloud firewall space. Currently Amazon vpc won't terminate to much of anything. It won't terminate to a cisco asa, it won't terminate to a sonic wall or a watchguard. Companies need to spin up cloud firewalls for private clouds , and I'd prefer to be using pfsense rather than closed bloat ware.
If it's cash deductible I'll even throw money into the development pool.
Cheers
Nate
@cmb:

Haven't had too many requests for it, though it's come up a couple times recently. It's like anything else with the project - it'll happen when someone is willing to put money towards it up front. Nothing against you personally but we almost never see "I promise I'll donate if/when X" money actually come in when X is done. EC2 requires custom kernel patches, so would require a complete custom build profile, possibly adjusting some of our patches to fit in with it, setting up a new VM build server to maintain it, would likely need to contract with Colin Percival (the guru of FreeBSD on EC2) for a few hours to help in some areas and verify best practices, and we'd have to pay for EC2 time. It easily would cost us in excess of $3000 USD in labor alone, and I don't see us ever able to get that back on it specifically, so at least for now I can't justify that unless someone funds it up front. There are things that are widely used that are better to put the money we have for general open source development towards.

It's a project I would consider if we at least don't lose too much money on it, don't necessarily have to break even or make anything on it. But it'll have to be close to breaking even. If anyone can justify putting close to $3000 USD into making it happen, please email me and we can discuss. cmb at pfsense dot org

Or maybe if there are enough people with smaller amounts to put towards it, a bounty could work. May want to start a thread on the bounty board.

@markky:

Hi,

Has anyone successfully got dtrace working in a pfsense/freesbie build environment?

Looking around builder_common.sh, it looks like including dtrace support in a kernel is a simple as setting an environment variable.
i.e. something like
  export WITH_DTRACE="YES"

Unfortunately it doesn't work, at least in my experience.

Generally with FreeBSD, there's a couple of things you need to get DTRACE working, some has to do with kernel config, some to do with compile options, but it's all pretty straightforward.

What's very odd with the pfSense build environment is that something seems to be redefining CTFCONVERT as null.

At the top, i.e.
 /usr/pfSensesrc/src/Makefile.inc1,
CTFCONVERT is correct, however by the time you get down to a module Makefile, such as

/usr/pfSensesrc/src/sys/modules/i2c/controllers/amdsmb

CTFFLAGS is still set, but CTFCONVERT is now an empty string, which means that the command run after compilation is "-L VERSION …" instead of "ctfconvert -L VERSION ..."

If I'm missing something obvious, please point it out.

Thanks,

Mark

Well, I think I've worked out what was going wrong with the Makefiles, and it definitely wasn't obvious, imo.
I'll write up why the build was failing in the next couple of days.  Still verifying the final bits.

Cheers,

I was able to get google-authenticator working in Pfsense 2.0 with SSH using this tutorial as a guideline:
http://www.mywushublog.com/2011/07/cheap-two-factor-authentication-with-google/
In order to compile the code, I stood up a Freebsd 8.2 virtual system.  After the binaries worked for the virtual system, I copied the files over to PFsense.

As for the web server, i think pfsense is using lighttpd.  Not sure how close that is to Apache, but there is a google authenticator apache module for use with apache web servers.  I've not tested it.
http://code.google.com/p/google-authenticator-apache-module/

I'd be interested it seeing it all work in pfsense though.

The patches were broken for a couple days but they should be fine again now.

Ok this is what I did so far. Not sure if it's OK or I'm missing something, so any comment is welcome.
For now I assume the adp and hadp modes are different, and I'm using hadp as default since it's the default for FreeBSD when not using battery according to the man page. Can't think of a pfSense installation using battery so I believe separated options for AC or battery are not really needed.

https://github.com/vizvayu/pfsense/commit/53c210dd6451f1bb82347e37c89652f7818122aa

Thanks Steve, I will try a snapshot.

Markus

My English isn't good so I probably couldn't explain :)
I mean;
When I install a custom port for pfSense, how can I configure it before building ISO image?
For example I installed MySQL and i want to configure it  to starting at startup like lighttpd.
Thanks.

I try to get updated patch to newer versions of FreeBSD.
Here worked fine, but without the jail_billm_mount_enable="YES" line mentioned in wiki devel page.

If somebody want test, here is the files.
Remove .txt letting .diff extension.
The patch file have to be in /usr/src and patch < pfsense_jail_builder_x_x.diff

pfsense_jail_builder_8_3.diff.txt
pfsense_jail_builder_9_0.diff.txt

Thank you!!  ;D

Very good explanation. I couldn't say it better :-)

Yes, edit /etc/inc/system.inc - change the "15" to "3". That will happily survive reboots.
Of course, when you update your pfSense software to a new version then you will get a new /etc/inc/system.inc and have to apply the edit again. Ideally, don't hack too many scripts on an installation - you have to keep a record of what you did and make sure to re-do it after every upgrade. It is better if the parameters that users want to set are available on the GUI. Maybe go to Redmine and submit a feature request.

Those surely need synchronization.
Though its a more cleanup that needs to be done.
There really is no reason to use so many tags for the same thing and just need to unify those tags to just one 'item'.

But surely someone needs to do the heavy work and upgrade code behind.

The others are leftovers missed from devs. Its better to report this issues through redmine.pfsense.org.

The lawsuit was resolved in Feb 2012 - see http://en.wikipedia.org/wiki/Tz_database#2011_lawsuit - so at least that is not an issue. The TZ database is now managed by IANA, so it has a well-defined public life! The Wiki page has the link to "Official IANA sources" at http://www.iana.org/time-zones but for pfSense we will normally just want to use whatever version is distributed with FreeBSD from time-to-time, so these official pages are an interesting reference, but there is usually no need to actually get the source data from there.
I will open a ticket today.

It depends on where the code is being used.  If it is a web gui or console program, the output should go there.