Interesting. So it appears the ale(4) driver was causing problems for fragmented packets. Thanks for posting that. Steve

Thanks a lot for the hint Gertjan!

There is no 8GB nanoBSD image built. Install the 4GB image. It will use the first 4GB of the 8GB CF card. The last 4GB will be free. Who cares? Dansguardian (becoming E2guardian) and Squid (as long as you do not want to cache) run on nanoBSD. If you are going to do Squid caching then you need a full install. Some packages are not supported on nanoBSD - to see which are not supported you can look in https://github.com/pfsense/pfsense-packages/blob/master/pkg_config.10.xml - search for "noembedded" to find packages that do not install on nanoBSD.

Upgrades should go fine - the vr* interfaces are already in the config of the upgraded system. I have upgraded 10 Alix 2D13 to 2.2.2 all without trouble. The change to factory default behavior is documented in just 1 line I can find: https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes Change default NICs from vr to em – vr is on the way out and em is the most common NIC in use today. A reader needs to already know a bit about pfSense and default interface assignment… to understand the ramifications of this 1-line statement  :)

Uhm… perhaps it would work better if you changed your PC's IP address as well to match the pfSense LAN subnet. Or perhaps enable DHCP? Or maybe just try again so that you can tell us what exactly you have done, since you apparently cannot even remember? Sigh...

@jailbreaker: added the next 3 lines hw.ata.atapi_dma="1" hw.ata.ata_dma="1" hw.ata.wc="1" This has no effect on 2.2.x, read the wiki for proper hints.

Ah, I didn't know BIND was a package now.  Got rid of that tiny-dns thing and installed BIND.  Looking good and I actually have the features I wanted.  :D Still no go on the arpwatch front, but whatevs.  I will deal with it.  Thanks for all the help!

So I figured out a hilarious workaround for this and I'll post it here so maybe I can help a brotha out… I downloaded VirtualBox on my Mac and installed pfsense to a qcow image and immediately powered it off. Then I copied the qcow image to my host, converted it to qcow2, then re-ran my virt install command. It boots now :)

Kool…...seems to be the best method of upgrade. That way "little surprises" don't bite ya on the can. Going to order a new CF card here to use for "Upgrades"....burn the new one, restore the config.xml file. The autoupdate is a .........well...........rough around the edges. Glad it worked.

@cmb: Shouldn't be a problem in that case. I guessed Hyper-V since it's weird about reporting its interface speeds. Only way I can think of that happening on a C2758 is if you configured the shaper for > 100 Mb on an interface that's running at 100 Mb. Is that possibly the case? The upgrade wouldn't have changed anything there, it was just pre-reboot you were still running a previous ruleset that loaded without errors, which was gone post-reboot. All the interfaces are running at 1Gb & I'm pretty sure the highest I had specified in the shaper was 300Mb. One LAN interface that was in the shaper is unplugged. Maybe that did it? I had specified the minimum bandwidth I wanted available to VoIP on that interface for when I start using it.

The only major issue with  ver 2.2.2  was a  (very) slow reboot issue connected to serial port assignments (or lack of them). It was resolved by 2015-05-17 21:30 with a re-release of the upgrade files including the necessary fix, see:https://forum.pfsense.org/index.php?topic=92408.msg512890#msg512890. Short and sweet - all clear now  ;)

here maybe this helps.  So you see I have 4 physical nics in my esxi host.  Each is connected to different vswitch.  Pfsense has a virtual nic and connection to each vswitch. The wan physical interface goes direct to my cable modem.  The other physical nics connect to my switch and then on different vlans, etc. But they could be different switches completely if you wanted full physical separation of your networks. pfsense does not have a leg in vmkern switch because this is just for management of esxi host.  this is connected to same network as lan, I noticed a huge performance increase when moving files to and from the datastore when vmkern did not share the same physical nic as your lan network, etc. wlan has an AP plugged into the switch, and my unifi controller vm is connected to that vswitch. dmz is just a vswitch with not real physical connection to the real world network.  And then my lan is the normal where most of the vms sit. [image: esxinetwork.png] [image: esxinetwork.png_thumb]

hi charliex this is a surprise for me because i thought this problem appears only on the igel thin client.maybe because of the via padlock. but if you have the same problem on a different hardware it seems not related to the igel. i am with networks clueless so i have no idea whats the trouble. but it worked fine on 2.1.5 and after the update it didnt work anymore whitout me changing anything so i think its a bug in the software. i think will open a bug report. best regards steve

I had the same error as the OP after upgrading from 2.2.1 to 2.2.2 and the above commit does indeed correct the issue. Thanks Phil!

An enhancement could be for an automatic reboot after 1 hour to the previous slice if the upgraded slice is not confirmed as being successful from either the GUI or a CLI prompt. This would be very useful to anyone supporting remote systems as downtime would be limited to 1 hour following a failed upgrade. That would be a nice thing, but would only work if the OS on the new slice is actually bootable. I guess that could still catch some application issues, e.g. if the system booted OK but some firewall rules startup/VPN links/road warrior VPN server… did not come up. If it got some issue booting then any process that monitored things checking to see if success is confirmed by someone/something, would not be running. I can think of 2 cases like this that have happened to me - some dev snapshots that were missing a kernel, and hardware that worked with FreeBSD 8.3 + pfSense 2.1.n but did not boot FreeBSD 10.1 + pfSense 2.2.n - in both these cases the system was sitting at a console boot prompt of some sort and unable to proceed. I always have at home or at my local office an example of every hardware combination that is installed somewhere remotely. Then I can do local upgrades first and know that all my hardware combinations are at least bootable.

Jim, I read what you wrote in the upgrade guide.  There is no mention in what you wrote WHY one would want to add the tunable to their firewall configuration.  What specific symptoms would lead you to needing this tunable? With respect to the open mesh access points, the traffic doesn't need to be handled by the firewall at all.  The main issue was messages filling up the system log, making it basically unusable.  Windows NLB is another animal altogether. Also, my question of the security ramifications of adding this tunable, thereby reverting the kernel back to its previous behavior, has yet to be answered.  Just for the sake of completeness, I think we should have a discussion of how this impacts security.  Was the behavior changed from FreeBSD 8 to FreeBSD 10 just for the sake of being RFC 1812 compliant, or is there a good sense security reason for the change? Is there a possibility that logging this kernel message could be suppressed (in a future version of pfSense), instead of enabling a behavior that violates the RFC? Thanks for all you guys do, Anthony

That Supermicro system looks a lot like the FW-525B which will not boot FreeBSD 10.1 and thus does not work with pfSense 2.2.n The FW-525B is based on: Hardware: Intel PineTrail D CPU - ICH8M Express Chipset Motherboard Jetway FW-525B With CFCard! versus a And the Supermicro A1SRM-LN5F-2358-O is based on Intel Atom processor C2358, SoC (Rangeley), 7W 2-Core, 1.7-2.0GHz 5x GbE LAN including 4 ports pair LAN bypass (SW programmable) ports with SoC I354 and I210-AT Without CFCard! It is a Rangeley 2 Core SoC platform or the little brother of the C2558 and 2758 SoC.