@reboot-me: Yesterday I tried a "StarTech ST1000BT32 Gigabit Ethernet Card 10/100/1000Mbps PCI 1 x RJ45" http://www.newegg.ca/Product/Product.aspx?Item=N82E16833114004CVF and it did not worked either. In what way did it not work? Considering the trouble you have already had I am reluctant to make any further suggestions until I know why the card didn't work. If the slot is broken changing cards won't help.

@craveness: could a USB to ethernet adapter help here? The FreeBSD man page for the axe driver (see http://www.freebsd.org/cgi/man.cgi?query=axe&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html) lists some adapters which look as if they should be capable of sustained Ethernet operation at 100Mbps. pfSense should already include the axe driver. My only experience with USB Ethernet adapters and pfSense was with devices supported by the udav driver and they were limited by USB speed of 12Mbps. They weren't entirely satisfactory because the devices would sometimes not be recognised during system startup and pfSense would consequently report a missing interface and wait for user input which is not useful if you want the box to run unattended. I suggest you search the pfSense forums for reports on the chipsets supported by the axe driver. You might find a report or two that will help you make a decision. An alternative approach is to use a VLAN capable switch as a "port multiplier". If you search the pfSense forums for vlan "port multiplier" you should turn up a few posts explaining the idea in more detail. Maybe a bigger case would also be a satisfactory solution. The MiniBox (M200?) I bought a few years ago has the height and cutout  to allow a standard PCI card to be mounted parallel to the motherboard (using a riser card) and above the I/O shield. This possibility doesn't seem to be mentioned  on MiniBox web site so maybe it isn't a feature of current M200 boxes or maybe I have forgotten the model number of the box I have. I have no idea if your card and CPU cooler would be fighting to occupy the same space. Out of the options I have discussed I expect the VLAN port multiplier would be the least troublesome.

Thank you for your reply! Using a baud rate of "115200" works. It hangs after trying AT multiple times though. Also both devices return OK for the AT command. Only one of the devices however gives a output of BOOT and some numbers (repeated again and again). Just wondering, isn't it somehow possible to map the output of "usbconfig list" to the /dev/dua* devices?

Repurposed notebook that includes everything needed.  Console display, keyboard, built-in UPS, onboard NIC (vlan the WAN etc.). With lid/display closed it can even sit comfortably in a rack space. Even old stuff from way back in 2003 era like DELL Inspiron 5100 works well.

You were right ! He is nice ! He offers me to buy an LPC module (<5$) http://pcengines.ch/lpc1a.htm or to send it as an RMA, which I choose (I had enough problems!)

My watchguard box will be coming soon, once in place I will crack open my Sonicwall.

It would be more likely that an overhaul of est(4) would actually remove the hardcoded values. They only seem to be there as work around for a bad bios coding. The way this is supposed to work is the bios passes infomation to the OS via ACPI. The bios should contain the information for all the CPUs it supports. The other possibility would be to add the values to the module yourself and recompile it. This probably isn't that difficult but would require some time studying the code. I had thought about doing that myself a few times but the performance increase just isn't worth it IMHO.  ;) Steve

Thanks all! Curiosity killed the cat. But you know what? Satisfaction brought him back! The LiveCD worked fine. It's just that there were so many versions, I wanted to be sure I was using the correct one. Happy New Year all!

thanks for the input….i figured out the problem i think...i was trying to install live-cd 2.0.2 i386 via usb-dvd drive with the iso burnt to a dvd...pfsense would not install even when i chose option 2....i then remembered i had a cd with version 1.2 laying around; this install without any issue with option 2....i dont know if it was the version i was trying to install or the install media that was causing the issue....now i will trying to install version 2.0.2 using a cd tomorrow

Check http://redmine.pfsense.org/issues/2704 You could trying adding the "reject" directive (until a fix is included in base pfSense)

Thanks.  I think I figured as much.  Maybe I'll try and find a spare netbook and get a USB ethernet dongle to play around with some of the other features and still keeping a low energy footprint. LoboTiger

ya it was some sort of glitch. i did a factory default reset and now it works fine. thank you all.

@cmb: That disables MSI in the NIC driver, which I guess either the driver or the hardware has problems with. MSI is: http://en.wikipedia.org/wiki/Message_Signaled_Interrupts Thank you both for your time and help. As of this post it's still up and running without issue.

@Darkk: Will this Linksys / Cisco WUSB600N ever be supported in PfSense 2.0.2 or later? There are apparently two different chipsets in the WUSB600N. v1 reportedly uses a chipset supported by the run driver. v2 uses a chipset that doesn't appear to be supported. @Darkk: If not what is a good wireless-N USB stick I can use that works well? Have a read through recent entries in the pfSense Wireless forum.

The battery is by my guess at least 7 years old. I tested the battery and it was dead, so I pulled it. I have a large UPS under my desk, so it isn't much of an issue.

If you can, disable DHCP and NAT from the TP Link box so that you are not doing double NAT.

Unfortunately it doesn't reboot from Linux / BSD directly either.  Have had a search around and found many instances of the same problem (several years ago) but with no apparent solution. Unless anyone can suggest a way to emulate a windows reboot I think I am out of possibilities. It is a shame as I have two of these old Compaqs that were sitting on a shelf for years - and pfs seemed the ideal tool to make them useful again. They are very small and almost silent - plus they take full height NICs, unlike most SFF PCs that need higher priced low profile. As I don't have any other spare units lying around I will continue to use them for now - living with the reboot issue.  Hopefully they remain stable so that the reboot problem is effectively irrelevant. Thanks for the suggestions - will hope that someone comes up with a novel solution!! …................. Just come across this as a possible solution elsewhere: I get this problem unless I boot with reboot=pci in my kernel args. Not sure if this relates to building the kernel - or something that could be loaded?  (Way out of my comfort zone!)  Any thoughts?

Thanks wallabybob! I now have the following under /dev [2.1-BETA1][admin@pfsense.localdomain]/root(6): ls /dev/cu* /dev/cuaU0      /dev/cuaU0.lock /dev/cuaU1.init /dev/cuaU2      /dev/cuaU2.lock /dev/cuaU0.init /dev/cuaU1      /dev/cuaU1.lock /dev/cuaU2.init … and have setup PPP interfaces, which actually go as far as to show me dBm and signal % values ... but under status>system logs the following is showing ... ppp: [opt1_link0] CHAT: +CGDCONT=1,"IP","internet" ppp: [opt1_link0] CHAT: Detected Hayes compatible modem. ppp: [opt1_link0] CHAT: The modem responded with "ERROR" to the command "AT&F&C1&D2E0S0=0M1" at ModemCmd: label. ppp: [opt1_link0] MODEM: chat script failed ppp: [opt1_link0] Link: DOWN event ppp: [opt1_link0] LCP: Down event … also ... [2.1-BETA1][admin@pfsense.localdomain]/root(8): usbconfig -d 1.2 dump_device_desc show_ifdrv ugen1.2: <huawei mobile="" huawei="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2.0: umodem0: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.1: umodem1: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.2: umodem2: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.3: umass0: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">ugen1.2.4: umass1: <huawei 0="" 2="" huawei="" mobile,="" class="" 0,="" rev="" 2.00="" 1.02,="" addr="">bLength = 0x0012   bDescriptorType = 0x0001   bcdUSB = 0x0200   bDeviceClass = 0x0000   bDeviceSubClass = 0x0000   bDeviceProtocol = 0x0000   bMaxPacketSize0 = 0x0040   idVendor = 0x12d1   idProduct = 0x1c05   bcdDevice = 0x0102   iManufacturer = 0x0002  <huawei>iProduct = 0x0001  <huawei mobile="">iSerialNumber = 0x0000  <no string="">bNumConfigurations = 0x0001 … should umodem* not be u3g* in the above? Thanks again for the help, it at least feels like I'm getting somewhere.</no></huawei></huawei></huawei></huawei></huawei></huawei></huawei></huawei>

Yes, I have tested on 2.1. It's working well.

Just saw this thread. My recommendation would had been an i3 no matter what.. Steve knows that :-) Atom processor just doesn't cut it for me. Plus you have a good hardware that you can switch to a full blown PC if required at a later time. $$ difference between Atom and i3 is not that much. For a very low end straight simple firewall system Atom is fine but it's has long lost the speed battle with i3 as you need the power once you start putting in resource intensive packages like Snort. And I highly recommend you add Snort to the firewall. Squid and others are just matter of personal preference and needs but Snort is something the firewall really needs to shield you from attackers.