Just for the record: I wasn't able to fix this problem with an "online" pfsense. To fix the problem, I had to reinstall the whole system. Don't forget to backup your configuration settings.

@kejianshi: Are you also mixing and matching oil and brake fluid in your car?  Don't do that either. That analogy may be a little extreme.  ;) Closer to running 10w30 oil and topping it up with 5w10. You shouldn't do it but it's unlikely to cause a problem. If it does though your dealer just going to turn around and say 'well we said use this oil and you didn't so no replacement engine for you!'. I have run dissimilar memory modules successfully many times however I couldn't recommend it for a production environment. Steve

I got it. Thanks & Regards amitaussie

Hmm, long while since I've used 2.0! I assume it doesn't say underneath the graph then? From your state-table size and number of mbufs it looks like a small ammount. You can grep for it in the boot log from the command line like so: [2.2-RELEASE][root@pfsense.fire.box]/root: cat /var/log/dmesg.boot | grep memory real memory  = 1072627712 (1022 MB) avail memory = 1015791616 (968 MB) agp0: aperture size is 256M, detected 764k stolen memory You can probably also run that from Diagnostics > Command Prompt. Steve

The only person in the world! Cool. My mother always told me I was special ;) Yes, it's running a 533 Mhz FSB Pentium M. I'll try to replace it with the stock processor in a couple of weeks, and do a fresh install. I'm about to move, most of my stuff is already packed and for now it's easier to just run the Firebox for a while without Radius. I think I'll have to stick with WPA2-PSK for a little while  :-X Thanks for your input!

Looks like I will take another workstation toss in a couple quality NICs and create another test FW.  If .36 fails to receive traffic it's ISP problem for sure.  Thanks all for the help/info.

Confirmed I reinstall a clean 2.1.5 and did basic config edit the boot file /boot/loader.conf to add the line hw.ata.atapi_dma="0" created a new one /boot/loader.conf.local and put the line hw.ata.atapi_dma="0" Upgrade from the internet to 2.2 and next boot with new version was done without problems. Thx guys !!!

jimp, mystery solved.  Bottom-line: The pfSense release 2.2 ufslabels.sh script fails to set $DEV properly The ufslabels.sh f76cbd6 or later in git contains the fix Manually labelling the swap partition will silently fail if you don't disable swap first (swapoff) Thanks for all your help.  In hindsight, I should have simply run the latest ufslabels.sh per your suggestion instead of simply inspecting the difference on github. Best, Bruce Here are the supporting diag/debug details. Command-logging of 2.2 ufslabels.sh script (the grep regular expression fails to return the swap device entry) + [ y = y ] + echo 'Disabling swap to apply label' Disabling swap to apply label + /sbin/swapoff /dev/ada0s1b + echo 'Applying label to swap parition' Applying label to swap parition + SWAPNUM=0 + find_fs_device /dev/ada0s1b + unset DEV + /usr/bin/grep -e '[[:blank:]]/dev/ada0s1b[[:blank:]]' /etc/fstab + awk '{print $1;}' + DEV='' + DEV='' + [ '' != '' ] + echo 'Activating new fstab' Activating new fstab + /bin/mv -f /etc/fstab /etc/fstab.old + /bin/mv -f /etc/fstab.tmp /etc/fstab + echo 'Re-enabling swap' Re-enabling swap + /sbin/swapon -a Command-logging of post-2.2 ufslabels.sh script (the grep regular expression properly returns the swap device). + echo 'Applying label to swap partition' Applying label to swap partition + SWAPNUM=0 + find_fs_device /dev/ada0s1b + unset DEV + /usr/bin/grep -e '[[:blank:]]*/dev/ada0s1b[[:blank:]]' /etc/fstab + awk '{print $1}' + DEV=/dev/ada0s1b + DEV=ada0s1b + [ ada0s1b != '' ] + SWAPDEV=ada0s1b + [ -n ada0s1b ] + echo 'Disabling swap ada0s1b to apply label' Disabling swap ada0s1b to apply label + /sbin/swapoff /dev/ada0s1b swapoff: /dev/ada0s1b: Invalid argument + /sbin/glabel label swap0 /dev/ada0s1b + SWAPNUM=1 + echo 'Activating new fstab' Activating new fstab + /bin/mv -f /etc/fstab /etc/fstab.old + /bin/mv -f /etc/fstab.tmp /etc/fstab + echo 'Re-enabling swap' Re-enabling swap + /sbin/swapon -a ```****

@stephenw10: There's no package manager if you're running the live-cd by mistake.  ;) …  ;D ;D ;D

I'm not suggesting your should wait for anything. What I'm suggesting is that when you plop 64bit on the same inadequate HW there's absolutely not gonna be any improvement regarding performance. Saying that 32-bit pfSense 2.2 on 1GB RAM is unuseable is a non sequitur.

LAN and WAN are in the same 192.168.1.0/24 subnet. That does not work. When plugging a system into an upstream private network for testing or whatever, make sure to first change the LAN IP/subnet to some private address space that does NOT overlap with what the WAN DHCP is about to receive.

Ok, its ok now. it was a download problem.

@hayedid: Sure, triple NAT may not be a perfect plan, but shouldn't it work? It should, theoretically. Some services have a hard time with multiple layers of NAT but most stuff works fine. The fact that yours didn't implies one of your devices was doing something wrong almost certainly the Asus since switching that to AP mode fixed it. Handing out the wrong gateway, incorrect subnet mask, bad route, it could be many things. Running it in access point mode is much better though. @hayedid: I really need to be able to see and login to my modem and router.  If they are in bridge mode, I lose that ability. You can still access the Asus in access point mode. Often you can still access an upstream router in 'modem' or bridge mode by using an additional IP on the WAN. See: https://doc.pfsense.org/index.php/Accessing_modem_from_inside_firewall @hayedid: Incidentally, I did turn 'Block Private Networks' off since my modem is not setup in bridge mode.  Does this open me up to any additional hacking? No. Everything from WAN is blocked by default anyway. That settings only serves as an additional block if you have a public IP on WAN. You should never see private IPs on the WAN in that situation so anything that arrives from a private address must be bogus and should be rejected even if you have port forwards set up. Steve

Check this out https://forum.pfsense.org/index.php?topic=87280.0

Yeah, at the very least tell use what NICs you have so we can point you at some appropriate tweaks. Steve

@stephenw10: Good call. Be aware that you can easily make a mistake hand editing the file though.  ;) Trying to restore a complete config file that references packages onto an install that doesn't can have interesting results. I've tried that and it resolved itself OK but there were worrying looking errors. Whilst you can choose to restore individual areas on the config file there's no option to restore everything except packages. So you can restore each area individually but that's not a good idea if the config file version doesn't match the install. You can load the packages you had before. You can edit out the packages section. You can make a backup of the config file without the packages section but that requires some forethought! Steve Actually I didn't notice the checkbox for backing up without package information. That will work perfectly. Plus I can do two, one with and one without and see if there's anything specific I'd want to save.

NO, as Steve pointed, only x86 HW is currently supported

After resetting the BIOS to the default settings twice, I got PFSense to boot correctly. Tomorrow I will go back into the BIOS and disable the non-essentials and hope for the same results. Thanks everyone for helping me out with this. Hopefully I won't run into any more issues.