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.

@charliem: As far as I know, only offset and frequency could have possible negative values.  Jitter and wander are calculated as RMS averages and so should always be positive.  Dispersion is related to delay and latency measurements, both of which should be positive (unless you live in a Tardis …) I'd say it's still good if the graphs themselves could plot negative values, because that could potentially show if there are some problems with ntpd. I plan to test next week and post a diff too.

So you don't like UPnP – fair enough. I happen to find it useful for a bunch of dynamic stuff (mostly Mac clients -- BTMM etc.), but I also don't have untrusted clients on my network. In any case, whatever your opinion about it may be, miniupnpd is included in the pfSense base install, and IMO it quite simply makes sense to perform this check, given how trivial this is to enable (port option).

You will first need to execute the ICA/CCA (pick one). If you already have an account on the portal, you can login with it or you will need to create a new account: https://portal.pfsense.org/members/signup/ICLA  (if you're signing as an individual) https://portal.pfsense.org/members/signup/CCLA  (if you're signing on behalf of a corporation) without either of the above, chances are small to get your patch merged into main

@luckman212: What is the correct way to submit a proposed patch for a package? Am I supposed to send a pull request on github? open a ticket on redmine? email or PM the package author? Sorry if this info is posted somewhere but I didn't immediately find it … I suggest creating your own "repo fork" of the pfsense-packages repo on Github.  Then make your changes to the package in question and submit them as a Pull Request back to pfsense-packages.  Instructions for creating a fork and have it track the upstream master are on the Github site (Google can also be a good friend when learning how to use Git). If you go to the pfsense-packages site and click Pull Requests in the upper right, you will see the currently open requests.  Here is a link:  https://github.com/pfsense/pfsense-packages/pulls. Bill

check http://freedns.afraid.org/ no need to login every x weeks ; works with your own domain or ones that are available no need to create another "dyndns" as there are thousands allready

Hi Hollander! the first iso i build on freebsd i386 cpu very high load. Then i rebuild on freebsd amd64 cpu load normal…!  :D thanks!

This is a bit late and in fact it looks likd you've got some other problems there but…. You can reload the config file from the command line using: /etc/rc.reload_all Your vpn client shouldn't be failing. Steve