I have been using a XG41 for half a year now both on 2.0.1 and lately the 2.1 (due to my IPv6 experimentation) and it has worked OK. Please see my posts in the following thread: http://forum.pfsense.org/index.php/topic,41742.0.html and onward See especially the following post. http://forum.pfsense.org/index.php/topic,41742.msg217644.html#msg217644 Some people had problems with certain MAC revisions of 8111E chipset but I managed to get Shuttle techies to test and they included the screenshots that these chipset in the XG41 was safe for FreeBSD 8.1. The one not working was "re0: Chip rev. 0x2c800000" XG41 is (at least in mine) reporting "re0: Chip rev. 0x2c000000" which should work. And I have not experienced any timeouts or connection-loss. When I last rebooted my XG41 after upgrade to 2.1 it had an up-time of 114 days. Best regards Dan Lundqvist Stockholm, Sweden.

Processor - Atom or the 3rd generation low power i3 processor (Just 35 TDP (W) launching in a couple of days most likely). I highly recommend the i3 3rd generation. Check out the leaked specs http://news.softpedia.com/newsImage/Intel-Core-i3-Ivy-Bridge-CPU-Specs-Leaked-Lack-PCI-Express-3-0-4.jpg/ Mobo - Mini-ITX compatible with above 1155 i3 processor. Maybe Micro-ATX if you like. Mini-ITX would consume less power (I suppose). If you are going with Atom then most likely it will be a processor mobo combo. RAM - 4GB RAM. I recommend 4GB+ if you are going to install resource intensive packages like Snort..etc HDD - SSD would be better for fast Squid caching. Size depends on your needs. My recommendation.. start with 80GB to 128GB

No problem, glad you got it working.  :) The rehash command causes FreeBSD to rebuild the list of files reachable in the path. After installing new files via a package you need to do this FreeBSD knows where they are or you can use the absolute path when calling the command. Steve

Thank you very much.

did you try eBay?  ;)

@robi: NanoBSD it's all in the RAM running, the storage is read-only. Power fail no problem. This.

Some type of NIC aggregation might be appropriate here too. Enough of these will saturate your FSB, even though they are PCIx cards: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=251084127667

There exists a driver for lcdproc 0.4, here. It requires some rewriting for 0.5x as there were some changes made to lcdproc at that time. However: @Joris: If you rewrite it for 0.5 (which is not difficult), it can become part of the distro (0.4.4 is frozen). Some differences for 0.5: It uses a pointer that functions as a 'this' or 'self' pointer for the driver data. See other drivers and the docs (I thought this was documented already ?). Allocate a private data struct for driver variables so you can run multiple instances of the driver. You should not use the driver arguments anymore. Instead use the configfile functions. Some driver functions have been removed. Some functions have a fall-back alternative. This means that if you don't define them, LCDd will provide the functionality. Keystuff works with names instead of letters. Therefore the getkey function is now called get_key. Usually the keynames to use are read from the config file. You could try to install lcdproc 0.44 to test the driver. You would first need to compile it which might be tricky against 0.44. Steve

No, sorry.  ;) The Safenet safeXcell 1141 that came in the X-Core boxes (X500, X700 etc) should be supported. There are drivers in FreeBSD for it and it is recognised at boot but for some reason it does not work, or at least no-one has been able to make it work. That is a mini-PCI card and the X550e doesn't have a mini-PCI slot anyway. The X550e, and all the other X-Core-e models, have encryption hardware on the board in the form of a Cavium Nitrox lite chip. Unfortunately there are no drivers easily available for it. It requires propriatary binary modules to work under Linux. The X-Peak-e models had a large PCI-e VPN card with various encryption chips on it known as the 'tacoma module' that too is unsupported.  ::) Steve

Exactly. Though the console is still available for basic tasks (and for much more complex stuff!). Steve

without managment is working

Thanks, its a FESTOOL Oberfräse OF 1010 EBQ-Plus :) Thanks so much for your reply Steve! Traffic going through interfaces requires CPU usage, gotcha. If i go VLAN, it would seem all traffic go through pfSense, as I would be firewalling various subnets., gotcha. The trouble is there are so many variables that hard figures can be misleading. There are a lot of variables but then there are a lot of pfSense users. Mashing a few 10,000 tables of data together would show some commonalities i would have thought. Shame I lack statistical analytic skills, would be fun and beneficial to the community. Thanks so much again, gunna go grab some hardware! Michael

Working perfectly with all 5 Intel NICs here too!

Thats great :) Thank you… Emre.

Cool, thanks.  Was not sure if that meant hardware interrupts or no interrupts.

Very interested. I too am currently virtualizing my pfsense box but might be tempted to move to raspberry pi in an effort to reduce costs. I can't see that you'd need to have more than one network interface although it would be a nice to have. My virtual machine currently has 3 virtual nics but just one physical nic.

Exactly. Try it and see. You should be able to get your other connection working without replacing the cable by setting both ends to 100Mbps full duplex. Steve