Well, I've completely removed squid from the equation, re-installed pfsense from the latest ISO and updated, then re-created the rules again.  It still isn't working, and I'm just too frustrated to deal with it for a bit – it is making me feel really stupid, 'cause I just don't understand how the traffic is going where it shouldn't.

It isn't properly shaping traffic out or in for traffic that I've bound for specific ports, and checked 50 times to make sure that the traffic itself is behaving as it should.  I've even rebound the rules to the wizard's default ports for the traffic I need to shape and it still isn't working.
I'll admit that much more traffic is indeed going to the correct queue without squid installed.  But this was a non-issue with 1.2.3.  So I'll wait for some stuff to happen.

The GUI needs some TLC.  The wizard is broken, half the stuff in the configuration screens is not documented or explained -- which is understandable since nothing is set in stone yet and something might change that would require a lot of GUI rewriting.  Rules that make sense in 1.2.3 are largely ineffectual in 2.x.  I don't know if maybe the change of rule order in pf, or something else, is doing this.

Basically for me to test 2.x I'd need traffic shaping (and squid, my link sucks so I try to save bandwidth).  Traffic shaping is too darn confusing to use right now, bad enough that I'm getting really niffed with it.  So I'll sit back and wait till there is some focus on it in development, and I'll be happy to test it out for ease of use and functionality when it gets put into the spotlight.  Right now it seems there are other areas that are more important.

But, I hope that it is looked at soon.  QoS is important.  I may not be a pf god, but I'm not quite an idiot.  And if I can't figure out how to shape traffic that I know but the incoming and outgoing ports for, then there is something wrong somewhere.

The problem does appear to be resolved now.

I was using FireFox 3.6.13 under ubuntu and Firefox 4b8 under windows 7.

Of course a fix would be better - this is just a workaround.
But I am not sure who is responsible for this package - I don't think the pfsense builders are.

I only know that I do not have the skills to do that ;)

Here, or the general discussion board, doesn't really matter a whole lot.

Eventually it would be a feature request ticket on redmine.pfsense.org if it's viable.

I've seen that happen when a package reinstall didn't go quite right, but it should be OK after a reboot.

It is odd, though.

Hi,

If you expect problems with load balancing, you could enable sticky connections in
system - advanced - miscellaneous - load balancing

Creating Vouchers:
You could creat a new User which is only allowed to see the Main WebGUI Startup page, so your friend can check, if the WAN connections are up and further can browse to:
service - captive portal - vouchers to create vouchers
and to check, if a voucher has expired to
status - captive portal

Here there is an excel sheet for creating a voucher print
http://ts-telecom.net/voucherdrucker.xls

It is only german, but there is a scenario explained for a Captive Portal
http://www.administrator.de/index.php?content=91413

Alright, finally got the AP to work!  It was conflicting with another SSID with the same name on my network.  Which is really bizarre since I took that adapter out of peer to peer mode.  I don't know how it was still broadcasting the old SSID.  Freaking WINDOZE!

Everything is now operational!  Awesome!  And, I'm so glad there are no sleep/hibernate interrupt requests made when I close the laptop screen!  Although, it would be nice if I could shutoff the screen somehow.

Ok, I have finally figured it all out.  Access point is working, and so are all three interfaces!  Whew!  However, this is still an issue:

http://redmine.pfsense.org/issues/1121

For some reason, after I reboot, the channel that I want the wireless AP to broadcast isn't accepted.  I have to save and apply the changes to restart the daemons to see the changes affected to the adapter.  I'm also using an Atheros chipset in the 2g surf.  Hmmm…coincidence?

bump just a reminder: Anyone who would like to have compression support for ipsec, please add to the bounty. Even if it's just 5 USD ;)

Thank you!

http://forum.pfsense.org/index.php/topic,31527.0.html

Should hopefully be in the nanobsd and update files on the next new run, too.

had a chance to get a screen grab when this happens

I can not get the error on the other hardware in the field, but the same problem happens.
Same hardware worked with older snaps. The Oct snaps as mentioned by another poster seems to be the time frame this last worked.
Thanks!!

NOTE: my firewall does not reboot after this. It has to be manually restarted.

fw.JPG
fw.JPG_thumb

If it needs binary files it wouldn't cache those.

It detects the browser string for iPad, iPhone, and Android and switches automatically.

amd64 has more registers than i386, so if the compiler is efficient, that alone brings a performance gain.
There is of course usually also a small performance penalty, because more data is transferred to and from the CPU (64-bit ints and addresses rather than 32-bit ints and addresses), so very simple algorithms that need a lot of data may be slower due to that.
On the other hand, there are e.g. 64-bit optimized crypto algorithms that are leaps and bounds faster, because they can work on bigger chunks of data.

These are all generalized statements, I have no idea as to how pfSense in particular is affected by this.
However, I want to keep things as future-proof as possible, such that if in a few years I should have to upgrade to faster hardware, it might be as simple as sticking the disk into a new computer and turning on the power switch. Eventually, 32-bit machines and 32-bit operating systems will go the way of the Dodo.

That snapshot probably was in the process of being made when I did that commit. Wait for the next one and see if it's there.

The second snap for today (Mon Jan 10 13:14:45 EST 2011) allows me to see snort_interfaces.php again and all seems to be working as it should.

Should be fixed on tomorrow's snapshots.