OK Thanks for the reply. I will take a look at doing some benchmarks. I did some more research and I guess the kernel can choose to use the Software RNG if the hardware one is busy. Seems logical I guess, but since the software one is not as "random" as the hardware RNG, you would think the developers would opt to wait for the hardware to be available again. I also read that there are some ipsec-tools that can be installed which help determine what's going on under the hood, but I'm not looking to modify my pfsense install at this point. I'm sure 2.0, which is based on FreeBSD 8, will have a newer version of the glxsb driver and all that, so perhaps that will utilize the glxsb more. I do use Rijndael for the IPSec tunnel to my colo. I was just hoping that there was some sort of easy way to verify that IPSec or opencrypto is actually bound to the glxsb device. One other thing that worries me is that since glxsb is loaded as a module, it's actually loaded after the ipsec support for the kernel is. I just hope that it sees that the new hardware is available after it has been initialized. another interesting tidbit: [1.2.3-RELEASE] [root@router]/var/log(23): sysctl -a | grep crypto <118>(cryptodev) BSD cryptodev engine <118>engine "cryptodev" set. <118>openssl speed -evp aes-128-cbc -elapsed -engine cryptodev <118>cryptosoft0: <software crypto="">on motherboard <118>pci0: <encrypt decrypt,="" entertainment="" crypto="">at device 1.2 (no driver attached) <118><118>(cryptodev) BSD cryptodev engine <118><118>engine "cryptodev" set. <118><118>openssl speed -evp aes-128-cbc -elapsed -engine cryptodev <118><118>cryptosoft0: <software crypto="">on motherboard <118><118>pci0: <encrypt decrypt,="" entertainment="" crypto="">at device 1.2 (no driver attached) <118>kern.cryptodevallowsoft: 0 <118>kern.userasymcrypto: 1 <118>net.inet.ipsec.crypto_support: 50331648 <118>debug.crypto_timing: 0 <118>dev.cryptosoft.0.%desc: software crypto <118>dev.cryptosoft.0.%driver: cryptosoft <118>dev.cryptosoft.0.%parent: nexus0 <118>cryptosoft0: <software crypto="">on motherboard <118>pci0: <encrypt decrypt,="" entertainment="" crypto="">at device 1.2 (no driver attached)vr0: <via 10="" vt6105m="" rhine="" iii="" 100basetx="">0 <118>(cryptodev) BSD cryptodev engine *kern.cryptodevallowsoft: 0 kern.userasymcrypto: 1 net.inet.ipsec.crypto_support: 50331648 debug.crypto_timing: 0 dev.cryptosoft.0.%desc: software crypto dev.cryptosoft.0.%driver: cryptosoft dev.cryptosoft.0.%parent: nexus0 It seems like software crypto is specifically turned off in the sysctl controls. Anyway, just some stuff to tinker with :P</via></encrypt></software></encrypt></software></encrypt></software>

A simple search for 82576 yields fantastic answers. http://forum.pfsense.org/index.php/topic,22986.0.html http://forum.pfsense.org/index.php/topic,23550.0.html http://forum.pfsense.org/index.php/topic,20009.0.html

nevermind, I just got my answer: http://forum.pfsense.org/index.php/topic,21981.msg123595.html#msg123595

Look at this thread and see if there is anything useful in there: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=17112&postdays=0&postorder=asc&start=0

No replay… UP

This is my config.  Does it look right to you? type static mac 11:22:…. mtu blank bridge with none ip addr 192.168.10.1 /24  (my lan is 192.168.1.1 /24) gateway blank ftp helper unchecked standard 802.11g mode access point 802.11g ofdm protection mode off ssid myssid 802.11g only unchecked allow intra-BSS unchecked enable wme checked enable hide ssid unchecked transmit power 99 channel 3  (on this version of pfsense I had to pick a channel to get it to work) distance setting blank wep unchecked wpa checked wpa mode wpa2 wpa key management pre shared key authentication open system authentication wpa pairwise both key rotation 60 master key regeneration 3600 strict key regeneration unchecked enable IEEE802.1x unchecked

@bmwkeith: I just got a Jetway J74K1G5S-LF with dual Realtek Lan ports running 1.2.3 and had trouble with the firewall becoming non responsive at random intervals, the symptoms being no internet access and could not log on to the firewall via the web GUI. I resolved the issue by disabling Hardware Checksum Unloading on the Advanced functions web GUI page near the bottom of the page. This has resolved the issue and now everything works fine Thanks for the tip "Hardware Checksum Unloading" sounds a lot like the padlock feature! I'm planning to upgrade my J7F4K1G2ES machine from 1.2.1 to 1.2.3 next week and I'll definitely try to disable that feature if the machine starts locking up.

The only reason why I wanted to post about the up/downGrade was because it runs so cool. My Server is a 1U system, so the CPU cooler was really loud to keep that hot proc cooled. I am now throttling the CPU cooler at 4000 RPM and the Proc won't go a single degree over 48C! I'm loving it and if someone is building a system then the 430 is for you. 1.8 Ghz single core is enough trust me.

Thank you very much Eddie I think I will keep with a more normal setup for now, and study this possibility later. I am still reading the docs… I will look to see if it is possible to install ataidle later too. Thanks for the insight!

I'm not sure exactly, but it may just be the driver. I don't think any of the Intel cards can do hostap on FreeBSD though so it may really be the card, too.

Are there any wireless cards with a Mini-PCIe interface that uses the USB part of this interface?

@ScottNJ: I'm not so sure about that. I built a Pentium 4 PC back in '04, the MSI motherboard came with an onboard Realtek Gigabit NIC. I had lots of problems getting it to work at 1000mb. I tried various driver versions and tried 3 different branded gigabit switches. I gave up and stuck an INTEL card in the box. Cleared up everything. There's a difference between a 6 year old chip (and 6 year old drivers, too) than what is coming out new today. Given a choice, Intel is generally better, but they have their fair share of issues too for some. A search on the freebsd-stable list turns up plenty of problems (checksum issues, tso issues, vlan hardware tagging issues, altq broken in 8.0-release, etc, etc)

Thanks for that, didnt think a simple pkg_add would resolve the issue.  ;D

Ok, It took me quite a long time but thanks to the Internet and the post by indexofire I was able to find a reliable solution: I think this will be of interest to all persons wishing to deploy an Alix box with an IDE drive. 1. The IDE drive was identified as da0 on the install machine and considered as ad0 for Alix…  ==> Edit and modify the /etc/fstab to change da0 to ad0 (this one was easy)! 2. The "READ_DMA UDMA" problem… this one is much more tricky: ==> Install pfSense with the live CD on an IDE drive. ==> Boot or mount your newly formated HD  with the computer you have used for the install ==> Mount your partition: mount -o rw /dev/da0s1a /root/tmp ==> Create a file in /etc: /etc/rc.early and insert #!/bin/sh /sbin/atacontrol mode ad0 UDMA2" ==> Edit boot file: /boot/loader.conf and add this line: hw.ata.ata_dma = 0 ==> Reboot ! And now everything is up and running!! Thanks to indexofire on this thread, http://forums.freebsd.org/showthread.php?t=4486 …You will soon be able to buy Alix box with IDE drive on my site www.osnet.eu

I just came across such an interesting problem; :)

Has there been any progress on this? I have a VIA box and noticed an unexpected reboot today, after upgrading earlier this week.

It might not really matter which you use on that card.  They are probably labeled 0, 1, and 2 and I would probably end up connecting it to 0 and 1 if I had one of those.  My 5416 only has two connectors, though, which are 0 and 2.  It has a space labeled 1, but there is no connector soldered there.

Valnar: I agree the Gigabit adapters won't be be pushed to anything like line speed if all the traffic is between LAN and WAN. BUT there is nothing in the description that says there won't be traffic routed between those 15-20 VLANs on the LAN interface nor does the description say there won't be traffic routed between LAN and those servers on one of the other NICs. There might not be any advantage in those Intel gigabit adapters if the system behaves wierdly because the Gigabit NICs saturate the PCI bus for extended periods.