k cool ill check that out cheers.

Unfortunately there doesn't seem to be a marvel driver available that doesn't have the one or the other issue. Scott already tried hard to get it working and tested every available driver to no success. Atm marvel chipsets and pfSense don't seem to be a good combination.  :(

You can manually assign macadresses through hidden config.xml flags (though I was pretty sure we have some code in place that does that automatically for invalid macs as this is a prolem with nokia IP330 boxes as well). Have a look at http://faq.pfsense.com/index.php?action=artikel&cat=10&id=38&artlang=en&highlight=hidden how to do this.

Regarding the Marvel chipsets, the drivers seem to have lots of problems. Scott did a lot of testing to get a nexcom with marvels to work but there doesn't seem to exist any marvel driver that dioesn't have the one or the other issue atm.

dipswitches haven't been bad either  ;D

The netgear stuff is pretty cheap. I personally never had issues with them but I also haven't used them in stacked configs yet. HP shouldn't be too expensive either.

This is not a pfSense issue, but rather a Freebsd issue. Post on their forums to see if support for that hardware is planned.

Only i386 versions of pfSense exists currently.

No, there is no plans to support sparc.

Oh, and if anyone knows of any other makes of "USB modules" like this (that can be plugged into the motherboard), some pointers would be great.

I guess, in the end, all I really want is to get something compatible that I can house inside the case and will accept a pigtail antenna.

1. Yep, regular usb1.1 ports

2. Could but haven't found a decent use for it

3. Why not make your own?…..takes about 20 minutes with a soldering iron

4. Yes they are but since you can still manage vi the RS232 port this is more for convienence

5. I've used a k6-2 380 oc'd to 400 w/out a problem

6. Good luck with the bios flashing, didn't find anything decent

7. Yep

8. Some of the dip switches set the RS232 configuration while other sequences offer a similar function to holding certain keys on a keyboard down while it boots to reset the device's configuration while it is running the OS from Nortel.

BTW, this has been discussed awhile ago on the FAQ's: http://faq.pfsense.org/index.php?action=artikel&cat=2&id=27&artlang=en&highlight=contivity

Also, if you look around online there's a thread somewhere if you lookup the motherboard model you'll find some more information that has come across over the years.

My only gripe with the series is that there is no real mention between the different models.....ie the "contivity 100" has been around for over 10 years with many different hardware configurations but yet they still keep the same model number....the only key for use with pfsense is any of the original "Bay Networks" variants are too old for use as they had a soldered on AMD 486 series CPU. I haven't seen any 1st generation Nortel branded ones but from what I have seen the hardware seems to work pretty well for at home or in a small office....in a larger setup the CPU tends to be the limiting factor when you want to setup site-to-site VPN links.

Your best bet for bios flashing would be to extract the current bios and see what features are disabled on the current bios and then attempt to reload it later.

YEAH i get it to work:

Mini HowTo which works on the WRAP System with Microdrive and Package Mode:

1.) Install the Live-CD 1.0.1 on the Microdrive ! Use the Format Tool and Partion Mode.
2.) DO NOT USE THE Bootloader on the Microdrive !
3.) After Installation reboot…
4.) Get the Image from the Embedded Mode on an USB Stick or other medium
5.) Boot the live cd again, use the Shell number 8 or something..
6.) Mount the Microdrive (/dev/ad4s1a) in my Examble to /tmp/ata
7.) Mount the Image :
gunzip pfSense-Embedded.img.gz
mdconfig -a -t vnode -f pfSense-Embedded.img
mkdir /tmp/mnt/embedded
mount /dev/md8a /tmp/mnt/embedded
8.) Delete the old Boot on the microdrive (/tmp/ata/boot)
If you can't delete all move the /tmp/ata/boot to boot.old..
9.)Copy the hole Boot to the microdrive (cp -R /tmp/mnt/embedded/boot to /tmp/ata/)
10.) copy the files from etc to the microdrive
cp /tmp/mnt/embedded/etc/ttys /tmp/ata/etc/ttys
look in the /tmp/ata/etc/platfrom file (It must containt the word pfSense
11.)last change the config.xml in /tmp/ata/cf/conf/config.xml
vi /tmp/ata/cf/conf/config.xml
search for sis0 change it to the IP you want to use at the beginning.
<interfaces><lan><if>sis0</if>
<ipaddr>10.106.0.1</ipaddr>
<subnet>24</subnet>
12.) type sync
13) type sync
shutdown -h now
Remove microdrive but into Wrap boot and now you can configure the other thinks over web gui (http://10.106.0.1) in my Example ....

HAVE FUN...

Mfg
PsYcHo012</lan></interfaces>

OK, tried to locate a default config.xml with hidden features from the FAQs link.
The link in there (http://pfsense.com/cgi-bin/cvsweb.cgi/pfSense/conf.default/config.xml?rev=1.19;content-type=text%2Fplain) is broken and I am not smart enough to locate it on my own.  :-\

From searching the forum I read that there were RRD issues in the recent past. Have they been solved so far? Most posts were affecting a pingable ISPs WAN gateway and not using the extra XML flag.

I have found hints on <use_rrd_gateway>and inserted it as follows:

@config.xml:

<pfsense><version>2.8</version>
<lastchange><theme>corporate</theme>
<system><use_rrd_gateway>217.5.100.222</use_rrd_gateway>
<optimization>normal</optimization>
…</system></lastchange></pfsense>

but still my WAN quality RRD graph shows 100% packet loss.
This might be due to the fact that -even after a couple of changes & reboots- the shell script updaterrd.sh still references my not pingable ISP's WAN gateway which is set dynamically by PPPoE on each connect:

@updaterrd.sh:

…
get_quality_stats_wan () {
packetloss_wan=100
roundtrip_wan=0
local out_wan
out_wan=ping -c 5 -q 217.5.98.186
if [ $? -eq 0 ]; then
…

Any ideas on why <use_rrd_gateway>217.5.100.222</use_rrd_gateway> is not used?
Before experimenting with the config.xml I upgraded to: pfSense-Full-Update-1.0.1-SNAPSHOT-02-09-2007.tgz

Thanks for your input (and this great software, of course!)</use_rrd_gateway>

The linitx is a very nice platform (I have 2 in service at customerlocations) and powerful enough to produce high LAN to LAN throughput. It's also powerful enough to handle much more than the required 5 mbit/s. Once pfSense fully supports the via padlock technology that the in this device used cpu offers vpn encryption will be done "on the fly" without causing much processorload. I rather would go a linitx fx5620.

Atheros chipsets should usually work.

You should do some real life benches on this box. Hard to say what it will push. Not only the throughput but also pps rate will decide how much this system will be able to push. However as you are using some good nics and a good pci bus you should see quite some throughput on auch a box I think.

And those are not supported anyway as they only have 64 mb RAM.

Either.

You could always try puting the NIC in a windows box, downloading the setup utilities, and hard setting the uplink settings in firmware.

If your cards lights are cycling every 2-3 seconds that seems to me like either the bus is resetting the card, or the card itself is resetting. You might try manually assigning different IRQ's to the card and insuring that the PCI slot you are using is not shared by anything else like a COM IO chip or Sound chip or the like. Most desktop grade boards share 3/4 of their PCI slots with on board hardware. Dual/Quad nic's DO NOT LIKE this at all.

If you notice, most DUAL/QUAD nic's will not run on PCI splitters installed on single PCI 1U servers. They have warnings in the manual about this. So if the PCI slot you have the card in is split with anything else, this may be leading to the behavior you're experiencing.

I would turn off everything in the bios that's not completely necessary including com ports, parallel etc, freeing up IRQ's. Then make sure your card gets IRQ's that are not used by anything else. Also avoid IRQ 11/12 if you can. 12 being the PS2 port. Older boards favored IRQ 10 for the video card. IRQ3,4,5,7.9 should be free if you turn everything off.

You'll never see PCI ADSL modem support for 90 percent of the hardware out there. It's all soft-modem HSP/DSP type hardware that requires the driver to do the brunt of the work. Each time the driver loads it has to 'program' the firmware into the card soft loading instructions. By themselves the ADSL PCI cards are completely dumn. Some of the external USB modems are a bit smarter and just require the right generic usb driver and instructions sent via the usb data connection. That's probably why there's one working for m0n0wall.

But if you're expecting winmodems to work in a freebsd firewall, you're probably wishing for something that will never come. Well I say never, but Connexant could start writing freebsd drivers for their cheap, neutered, and otherwise dumn hardware some day. You never know…

The only reason Lucent DSP modem hardware worked in linux is because lucent released some framework for their soft modems for use in linux.

That's my 10 cents and change. It's much the same as the wireless hardware out there. None of it will run very well without very specific firmware based drivers.

My recommendation would be to toss that nvidia piece of garbage out the nearest airlock and get a real platform to work with. First step is to get real nic's like intel 1000BT desktop nic's. My second recommendation would be to toss the motherboard and get an intel chipset or amd chipset board to work with. When you're working with linux/freebsd/unix any deficiency in hardware design like weak nic's, buggy acpi, broken bios, becomes blatantly obvious. Every piece of nvidia (read non video) hardware I've touched has been broken someway some how. And when I say broken, I mean completely broken hardware design that will never be fixed because linux/freebsd folk don't tend to fix broken hardware issues in software unless it's a fix provided by the vendor (nvidia) and that's not happening.

The old nforce2's used to randomly lockup when you copied files between two hard drives and played an mp3 in linux and freebsd because the bus timer's were seriously broken. You'd get irq locking issues. They fixed this in software in the windows driver but the hardware stayed eternally broken. The nforce3's had crazy ACPI issues and the nforce4's would just randomly lockup due to mysterious NIC/bus issues.

My recommendation would be to stay far far away from any nvidia chipset unless it's a windows only box. And even then, make triple backups of your data because the built in nvidia raid has a tendency to trash your data faster than you can install windows at times. (yes more defective junky nvidia board design). Basically, I've never seen an nvidia board work properly with linux/unix without something on it being broken. I would just find another platform to work with.