Well, I did confirm the unit is booting as I was able to pull and IP and log in to the web UI.  I also confirmed that the serial settings are set to 115200 but my console doesn't advance past the screen in my previous post. I've also tried different emulator software too. Any input is appreciated.

Looking at the source code for the 9287 driver, I've noticed this: /* Don't support Kiwi < 1.2; those are pre-release chips */ if (! AR_SREV_KIWI_12_OR_LATER(ah)) { ath_hal_printf(ah, "[ath]: Kiwi < 1.2 is not supported\n"); ecode = HAL_EIO; goto bad; } Looks like I probably go a device manufactured from non-production components (possibly even sample devices). :( Also Kiwi seems to just refer to the family name of the device, i.e. much like celeron, pentium, etc. Hope this helps someone else. -Wynand

!!!!Need more info or screen shots!!

After installing the version 2.2.6 the problem has gone! Thank you for the great product! Happy new year, yarick123

I have tested both again, in both combinations, now instead of using CF cards, I'm using equal SSDs, Kingston S200/30GB. No changes in the results. Both devices present higher temperature and lower performance on 64 bit, than on 32 bit.

Note that in 2.3 the factory defaults processing will automagically select from a range of physical interface combinations when first booting, avoiding the need to do interface assignment on the console for hardware like Alix, APU and SG-series devices… https://github.com/pfsense/pfsense/commit/b49e6c0113f107f5a9ff61fe8e8798de8cca0953 That should be working now in 2.3-ALPHA images.

^ that. Try a different serial speed (like 9600)

Just a FYI. I was trying to connect using one of my failover IPs on my dedi server from online.net. anyway, I manage to get it sorted. I knew what to do (almost)  I had to add a route, but didnt realise that the last bit was important, I kept trying dev eth0  when I should have been using -iface em0  once I added the route correctly, pfsense connected to internet. Thank you for providing this software.. Once my testing is done, If I keep pfsense, I`ll think about getting a gold sub. Del

There are relatively few changes between 2.2.5 and 2.2.6, so reinstalling packages in that scenario would have been more a precautionary step than anything else. If everything seems to be working, I'd leave well alone.

I wanted to update this post to reflect a method to correct this should anyone else run into a similar issue. I visited over at the QNAP forums and posted a similar message to a thread which already talked about running pfSense in a VM. mbender71 over at QNAP forums had a similar issue. Here is what was done; EXCELLENT question as I fought this battle a number of times. The issue is that pfSense is not able to get an IP address via DHCP and I believe it has something to do with the MAC address of the pfSense VM versus the MAC address of the physical adapter on the NAS. I found only one solution and here is how it goes : attach a desktop/laptop to your cable modem (that's in bridge mode already) and get that working. For me I used my MacBook Pro with a thunderbolt to ethernet adapter. The point of this exercise is to get your ISP to recognize the MAC address behind your cable modem and lock it in (my ISP only allows one DHCP at a time). PLEASE make sure though that you have your firewall turned on your desktop/laptop and perform this operation quick. Leaving a computer jacked to the net directly is dangerous! once you've confirmed your ISP has given you your IP address (i.e. you get get to the net) go ahead and disconnect your computer (for safety reasons). what you have now is a very special MAC address. Record the MAC address of the adapter you just used to connect your desktop/laptop to your cable modem since that is "golden" with your ISP. open the configuration of your pfSense VM in Virtual Station and begin to edit. What you need to edit is the MAC address of the virtual adapter that you will be using for the WAN in your pfSense VM. Copy the registered MAC you just found in the previous step into the configuration for the adapter you'll be using in the pfSense VM. For the record, I use the Virtual Ethernet IO (vmnet) for both of my pfSense network adapters. connect your cable modem to the designated virtual switch that you have your pfSense WAN network adapter configured to (the virtual switch for the WAN connection SHOULD BE configured as EXTERNAL ONLY). fire up your pfSense VM and open the console to watch it boot up. It might ask to configure the WAN/LAN in the CLI, but this time pfSense won't hang while it's initializing the WAN as it SHOULD receive its IP during the DHCP portion of it initialization. NUTSHELL -> Take a working MAC address that was connected to the cable modem and copy that MAC address (spoofing) in the pfSense network adapter that is being used to connect to your cable modem (WAN). This is what has worked for me and it's pretty solid. Only once have I had to repeat this crappy procedure when my ISP had a major outage for about 6 hours. I DO hope this works for you as I've had one other instance where a local friend had the same problem and after giving this solution it worked for him. Good luck! Thanks, Michael Hope this helps anyone else in a case where they are unable to get their WAN to detect.

@RonpfS: I disable Suricata, pfBlockerNG and FW Rules using pfBlockerNG before doing an upgrade. Yes - I probably should have done that too but I'd had no problems with another pfSense upgrade at work earlier and I just hit the upgrade button at home without thinking.  The NanoBSD system has less resources and has given me occasional glitches like this in the past - caveat emptor.

Which provider BTW? TM Unifi (Malaysia) Great. It works. Assigned as suggested and added Rules as follow: Action : Pass Interface : WAN TCP/IP : IPv4 Protocol : TCP Source : any Destination : any

Configured Pfsense router as DMZ , working perfect  , i noticed issues with double nating is issue with VPN and portforwarding  . but since my ISP NAT again i cant use VPN or other , (previous ISP used to provided public IP dynamically , but current provide high speed by 172.30.x.x private ip range which is NATed , so no issue with double NATing thank you

After the Upgrade to 2.2.6 i have the same Problem, but this is strange because I never used the Traffic Shaper. There were error(s) loading the rules: /tmp/rules.debug:52: errors in queue definition - The line in question reads [52]:  queue qInternet on re2 bandwidth 150000Kb hfsc (  ecn  , linkshare 150000Kb  , upperlimit 150000Kb  )  {  qACK,  qP2P,  qVoIP  } There were error(s) loading the rules: /tmp/rules.debug:52: errors in queue definition - The line in question reads [52]:  queue qInternet on re0 bandwidth 150000Kb hfsc (  ecn  , linkshare 150000Kb  , upperlimit 150000Kb  )  {  qACK,  qP2P,  qVoIP  } Because this Error occur i am back again on v2.2.5.

Ok my issues are now fixed. I thought it was the network card/s but ISP fixed phone line as it was playing up and now works again. I just find it strange that when connected to the modem direct I got normal speed but as soon as I added the Pfsense box in the speed dropped I dunno what the go is with that but its all good again. Thanks for the help.

just re-assign and use the auto-detect features in the menu (as stated by @robi)

@phil.davis: Note for reference: https://forum.pfsense.org/index.php?topic=87364.msg583303#msg583303 No luck with the FW-525B on latest pfSense 2.3-ALPHA that follows FreeBSD 10 development. It seems that the problem will be solved in FreeBSD 11: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199495

@cmb: That's confirmed fixed in the newer lighttpd in 2.2.6, so likely the next update will work for you there. Thanks cmb, I can confirm that in the 2.2.6 release the upload of the release file through the webgui works fine! While the 2.2.5 release gives the reported problem. So we can put this issue on solved: workaround on 2.2.5 through ssh - option 13. solved in 2.2.6