Doesn't exist currently. No plans for that at this time.

When I setup ipv6 NAT, all pf NAT down.  ipv4 NAT down also.

pfSense-Full-Update-2.1-BETA0-i386-20121128-1058

cranking up the pf debug level is probably your best bet to troubleshoot.

not to mention the system log full of the below

Nov 29 17:22:02 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:22:02 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:22:02 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:31:52 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:31:52 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:31:52 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:31:52 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:41:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:41:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:41:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:41:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 17:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:01:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:01:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:01:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:01:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:08:55 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:08:55 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:08:55 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:08:55 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:15:56 miniupnpd[57305]: remove port mapping 65176 TCP because it has expired Nov 29 18:15:56 miniupnpd[57305]: remove port mapping 65176 TCP because it has expired Nov 29 18:15:56 miniupnpd[57305]: remove port mapping 65176 UDP because it has expired Nov 29 18:15:56 miniupnpd[57305]: remove port mapping 65176 UDP because it has expired Nov 29 18:21:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:21:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:21:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:21:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:38:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:38:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:38:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:38:26 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:51:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:51:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:51:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 18:51:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:01:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:01:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:01:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:01:56 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:11:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:11:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:11:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:11:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:21:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:21:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:21:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:21:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:29:04 miniupnpd[57305]: remove port mapping 26367 TCP because it has expired Nov 29 19:29:04 miniupnpd[57305]: remove port mapping 26367 TCP because it has expired Nov 29 19:29:04 miniupnpd[57305]: remove port mapping 26367 UDP because it has expired Nov 29 19:29:04 miniupnpd[57305]: remove port mapping 26367 UDP because it has expired Nov 29 19:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:31:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:41:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:41:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:41:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:41:58 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:51:57 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:59:54 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:59:54 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:59:54 miniupnpd[57305]: upnp_event_send: send(): Broken pipe Nov 29 19:59:54 miniupnpd[57305]: upnp_event_send: send(): Broken pipe

I remember committing it but it must not have been pushed back to the repo. I can't find any trace of it here. I did it again and confirmed that it pushed this time.

For some reason I was thinking we either already had a similar fix or someone committed some code to work around it. I remember seeing a commit in our repo a few months back that was supposed to fix switching between tun/tap which was the last issue left there, I believe.

Well, under that aspect, it makes quite it makes sense to pf(Sense) ;-)

Maybe I understood what is driving me crazy about the Wifi connection, it's the WME setting.

Under heavy traffic, in the first seconds I see a good speed, then it drops down… and I see the "RATE" in the Status->Wireless page dropping from 54 to 11 mbps, and the transfer speed drops.

If I run "ifconfig "run0_wlan1" list wmm" I see:

       AC_BE cwmin  4 cwmax  6 aifs  3 txopLimit   0        AC_BK cwmin  4 cwmax 10 aifs  7 txopLimit   0        AC_VI cwmin  3 cwmax  4 aifs  1 txopLimit  94        AC_VO cwmin  2 cwmax  3 aifs  1 txopLimit  47

which could makes sense with the drop of the download speed.

How is it possible to change this settings in order to be able to transfer a 300Mb file using the Wifi connection without spending the double of the time?

Thanks,
Michele

EDIT: This happens also with the "Enable WME" set to false, so ifconfig should set -wme …

If you would like that connections from your LAN to the internet get proxied - this is the "normal" mode of squid and also called "Accelerator mode".

If you would like to access your proxy from the WAN then this is called a "reverse proxy".

Squid3 can do both. There are two different GUI entries. "Proxy Server" and "Reverse Proxy"

@cmb:

@rcfa:

It's also an example why the dual-partition thing that's available for the nanoBSD version of pfSense would be rather helpful for the regular version, too. This happens to be my home box, and I'm not traveling right now, but imagine this thing being somewhere else e.g. in some server room halfway across the country or globe? You may deal with major expenses and lengthy down-time if you can't just switch to a previous config on a different partition.

This is why the full backup feature exists. It's also why you don't blindly upgrade to snapshots on any system that's remotely important without thorough testing unless you really, really know what you're doing.

That really wasn't the point here. The problem is, the system installed just fine on another box, so it's not an obvious issue with a broken build.
Also, things got really out of hand when I tried to restore the configurations that were created by the "full backup" feature during upgrades. So your suggesstion that this is why the full backup functionality exists is a tad besides the point, because obviously it didn't work as expected in this situation.
Further, the full backup is kind of useless if you can't use the GUI to be able to roll back, and lastly, restoring to a full backup didn't work as expected either.

It's still not quite clear exactly what went on, e.g. if network glitches upset the upgrade process and left the system in an undefined state, or if accessing (not changing settings!) the GUI before the system was fully installed and all packages were reinstalled upset the upgrade, which would be not a good situation.

My points were simply these:
a) maybe someone knows what might have triggered that behavior, so I can be watchful of specific things that would trigger it, or it might lead to the discovery of some bug (e.g. some issues with locking or something like that) that could be fixed, and

b) things can get messed up, and a nanoBSD style alternate partition could be quite helpful in that situation.

I simply posted a description of what went on, to provide and gather information, I didn't accuse anyone of anything.
I'm perfectly well aware that this is still beta, but after all, just because at some point the beta status is removed doesn't mean the system magically is 100% bug free after that point.

A similar question was once asked: http://forum.pfsense.org/index.php/topic,28433.0.html

2.0.2 should come out soon: http://forum.pfsense.org/index.php/topic,52810.0.html

For most setups 2.1 works ok. If you have newer hardware or a bug which is a dealbreaker for you just check it out.
I'd call 2.1 beta a lot more stable than releases of various other software developers ;)

pppoe mtu fixed at 1492 is a known bug(enhancement) for 6 months plus, pppoe will ways connect at 1492 even if you manually try to insinuate from command line. also it suppose to auto negotiate the mtu but never worked for me. Not everyone has this problem so it doesn't get fixed, personal i didn't have this problem till my isp updated there servers in june and now no internet through pfsense. lucky for me i just swapped it out but i do want pfsense back so i keep checking the forum each month seeing more and post about or related to the issue.

P.S,
interfaces_ppps_edit.php you can change the code and put the settings back on the page but it will make no difference. been there done that

@rmoulynox:

followed by corrupting the entire file system when attempting to enable Intel 4965 PCIe card in AP mode on a fresh install, but that's far less critical at this point)

The man page for the FreeBSD iwn driver says it supports the 4965 device but doesn't say AP mode is uspported. (See http://www.freebsd.org/cgi/man.cgi?query=iwn&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html )

A panic is a poor way of saying "AP mode is probably not supported". But it probably gets more attention than a message on the console or syslog. :)

@ermal:

Normally you use labels for these things.

Don't see how putting a label on the device will accomplish the objective of forcing da0 to be the device FreeBSD booted from.  Except of course in the case where the boot device also is the device with label corresponding to da0.

All ears if someone knows how to do this.

Working great now on this version:

2.1-BETA0 (i386) built on Thu Nov 22 13:25:28 EST 2012 FreeBSD 8.3-RELEASE-p4

(1GB nanobsd i386 on Soekris net5501)

Thanks for the fix!

Bruce.