Please give more information about your settings - nanoBSD with CF card or full install, what hardware, what settings (output_cdf, recover_cdf, graph…), how long does it go before 100% CPU happens again, do you have any idea what system event might have happened just before it goes 100% CPU...?

All good with the patch. 8)

I've been running full install on 4gb usb 2.0 flash stick for nearly a year and have never even approached 30 minutes for an upgrade.

I typically do console upgrade so can better see progression.  Download is usually a couple minutes.  Then the upgrade is about 9 minutes (~7 rows of dots).  Then the reboot and packages reinstall is maybe another 5 minutes.

To ensure the best USB flash performance use devices that are rated for ReadyBoost.

I did install once on a non ReadyBoost device and it was agonizingly slow.

Sane again with Aug 17 06:10:26 EDT 2013 snapshot.

Extended Query should work so long as you specify it using the correct syntax. Others on the forum have said it worked for them, but I haven't tested it.

See http://doc.pfsense.org/index.php/LDAP_Troubleshooting#Extended_Query

UPnP was fixed in 2.1

Squid would be up to the package maintainer to fix.

When selecting an interface in the GUI, it only adds the -S x.x.x.x parameter to ping to set the source address of the packets.

So:

ping -c 50 -S x.x.x.x y.y.y.y

Where x.x.x.x is your WAN IP, y.y.y.y the target

"principle of cause and effect"
If nobody here which change the cause, we have to fight with the effect.

Thanks for the script.

@vielfede:

@phil.davis:

See this thread: http://forum.pfsense.org/index.php/topic,65231.0/all.html
I think all these problems are related to the apinger changes.

I read it…
It could be... as on RC0 (20130624) it works...

[SOLVED by]
2.1-RC1 (amd64)
built on Thu Aug 15 16:30:12 EDT 2013
FreeBSD 8.3-RELEASE-p9

@vielfede:

I have to point out another issue: proxy failover;
On 2.1 RC0 and RC1 the configuration described in http://forum.pfsense.org/index.php/topic,60977.0.html does not work!
as already stated by fabianoheringer

I had to install 2.0.3 pfsense to get it work.

Workaround for failover
See
http://forum.pfsense.org/index.php/topic,60977.0.html thread

@ermal:

Please search before posting.

You have to tick an option on the interface section of your IPv6 WAN which says 'Use v4 interface for v6'.
With that it will work again.

Thanks for that - as it turned out I had tried those extra options but it had "failed" because at some stage I had made a typo in the address I use for gateway monitoring 8(

Cheers
Jon

@dhatz:

After changing lighttpd config file to include:

ssl.cipher-list =  "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
ssl.honor-cipher-order = "enable"

Hello

A question: Why do you actually disallow AESGCM instead of putting it at the very front of the cipher order?

Hmmm… appears to be an interesting corner case:

I extraced (using qemu-img) a 203-release ova's vmdk to a 10GB raw volume.
As it didn't have the virtio stuff (I missed the fact that is wasn't in 2.0 only the 2.1-RC) I then tried the latest snapshot, which gave this error.
By thrashing the disk/volume and creating a new 8GB volume, it passed this point.

As I don't know FreeBSD that well, I can't give/help that much :(

For what it's worth I have seen this behavior too and reported on it. Too lazy to look for the post to link to it. What I do for a work around is verify the interfaces are assigned to the correct vlan before applying the change. I have also seen this behavior when adding  a new vlan to an existing interface. Glad to see some movement on this one.

I setup 2-port LACP LAGs with multiple VLANs on a redundant pair of pfSense firewalls (2.1 RC0 8/12) using a pair of stacked Netgear GS7xxTS series switches yesterday.  I even setup a crossed configuration where the LAGs from the firewalls were spanned across both switches, i.e., fw1 lan1>sw1p1, lan2 > sw2p1, and fw2 lan1>sw1p2, lan2>sw2p2.

The crossed configuration was cool, except that I had a handful of of connections that were not LAG'd and therefore if switch 1 failed, the firewalls would have failed over anyhow, so it didn't really make sense to cross them.  I ended up with a 2-port lag from fw1 to sw1, and fw2 to sw2.

As of this build… it works for me.

A few days earlier it did not.

2.1-RC1 (i386)
built on Tue Aug 13 13:39:48 EDT 2013
FreeBSD 8.3-RELEASE-p9

If you're using IE, try a different browser or a more recent version of IE. IE hates our AJAX, and it's a long standing/known issue.

Pretty much any other browser on the planet works fine with it (and also the most recent IE does, last I saw)

http://en.wikipedia.org/wiki/Year_2038_problem

Restrict yourself to the year 2037.

Yup, thought 100 years would be nifty myself. I chose 36524 days, of course, to accomodate for leap years. I didn't want to end up afew days too short… ;-) ...and, despite my ultimate smartness, ended up in the same situation as you.

Forgive my lack of knowledge about pf, but setting a "pass action" on a floating rule, direction -> in, could be a risk for internal LAN protection? (or should we use "match" instead, as suggested).