I just reset the resource configs, still cant see my network card :-(
PS: yea I know I have to instal freeradius on my own, that is not that hard, but sometimes SQL functionality freaks me out…. never installs as it should, although on RedHat installs are easy
OK - to answer my own question…
Based on this post [ http://m0n0.ch/wall/list/showmsg.php?id=73/62 ], I edited the /boot/loader.rc file on the ISO and added the following 2 lines to the very top:
Then burned the ISO and booted - pfSense now loaded in PIO mode and everything worked fine. The setting was retained during the install.
Question for the developers - Will the pfSense update process lose these changes or am I now good until I need to do a new full install?
For reference I used a trial of a program called UltraISO to edit the file. You need to extract the file out of the iso, edit it, then paste it back in and save your new ISO. http://www.ezbsystems.com/ultraiso/index.html
With "only" 40 mbit/s you won't push this device that hard that you'll notice a difference I think. Realteks put more load on the CPU than Intels but that shouldn't be noticable in your scenario and your bandwidth. You even should be able to go 100 mbit/s with this device (at least between 2 interfaces). I get full wirespeed with my C3 1 GHz with 2 Via Rhine nics.
Ah, so in order to do this, I'd have to have 4 nics in each server, 2 frontside, 2 backside. Plus, those nics would have to support team failover on whatever OS they're using (mostly MacOS X Servers, and now I'm adding in about 10-11 FreeBSD servers).
Yay…that's a lot of nics. Some of these boxes don't even have that many pci slots. I know for fact that several of the on-board gigabit ports are supposed to replace the need for pci slots, so they only have 1-2 slots available.
Switch failover may be a lost cause in my environment. I may just have to be ready with the swappable switch sitting there as a just-in-case measure. :(
Actually, upgrading to latest snapshot didn't solve the issue.
But i found a fix!
Basicaly these xseries spare an internal adaptec controller and a pci board with the ServeRAID controller.
That internal controller has no devices attached to it in my server.
Disabling the internal adaptec controller seem to chase that bad timeout..
Boot isn't delayed anymore after finding ipsd0 logical volume.
Well to answer my own question.
I was reading around on the freebsd mailing list and found that the message is the result of a known, but harmless, bug in dc(4). Since its not a show stopper I'll let it slide.
The 4805 should work fine with the iso image, embedded has had a lot of stuff removed lately.
If it's not supported in our kernel build i'm sure we can add the correct "device blah" line to the kernel.
You can find the current kernel config here http://pfsense.com/cgi-bin/cvsweb.cgi/tools/builder_scripts/conf/pfSense.6?rev=1.14;content-type=text%2Fplain
The kernel in the latest builds has been "trimmed" quite a lot lately. I think you will find that the newest builds are much faster due to several improvements (like APC, smaller kernel for faster boot, a few tweaks here and there).
you can use the embedded or regular version of pfsense with the box. All you need to do is to load either image onto the compact flash or hard drive. After loading it on the boot device of your choice the video card doesn't help much other than to post check as there is no keyboard interface. Also, you don't need to have a pci video card as there is onboard video(trident chipset).
I have yet to get the serial port working properly with pfsense nor the leds on the front of the chassis.
When booted up all i normally see is the spinning thing.
So far, I've seen this error only because of an IRQ-Problem with an ACPI System, running pfsense on. It seems to me, that the realtek-driver is not able to share IRQ's under some circumstances with other drivers…
So, you might probably put the card in another pci-slot, and check, if the error occurs further on. Second, it may help to disable unneeded onboard components, as USB or LPT or a soundcard.
The CARP IPs can be handed over from one firewall to the other. What happens in the background is that the failover node grabs the macadress of the CARP IP after the master has died, so nobody in the network will notece that actually another machine took over. same IP, same MAC. The LAN CARP IP that is used as the gateway will act the same.
The price for the nexcom is right. It has some benefits like serial redirection (you even can access the bios at com1) and a rather short 19" 1U case (many switches are even deeper). I configured a 1U mini ITX system with 4 nics and a via C3 1GHz cpu but ended up around the price of the nexcom, at least when using non crappy hardware. And the nexcom comes completely assembled even with serial cable. Add RAM, a cf-card or a hdd and you are ready to roll.
Just a note if you have to hard code your ethernet speeds to check out:
You can hard-code the speeds into the config.xml file but we do not provide a GUI knob for this due to the incredible amount of times this simple thing gets messed up resulting in any os being blamed :)
Retried over and over. Finally ISP's modem failed to respond under any gven OS on my side. They must love me. I never ever use anything "standard" in my ventures and I usualy ask nasty questions noone knows an answer to.
I know I can get it to pull the gateway from config.xml for the inernet connection test. Should I add an entry in config.xml for the external site or just leave it yahoo? I guess a DNS server would also work.
I only have my WRAP for a few days this week before it's shipped off to a client. Having a lot of fun with it though. :)