Pfsense, Watchguard Firebox II and the LED Panel on the Front
-
Sorry, but controlling the LEDs on the firebox looks totally different.
Afaik, there's no way of sending anything to the firebox leds without using a programming language.
Perhaps if anyone is smart enough to re-code my source to a device driver that acts as /dev/led or something like that, but I don't think thats a good way of controlling the firebox LEDs. What I have is code written in C, that opens control to specific hardware ports and then writes codes to the ports to control the LEDs. Although part of these ports are like the parallelport, it's not possible to handle it as a parallelport (like /dev/lp..) because it involves more that just that port and because the bitpatterns that define which LED to light is not very easy (and certainly not like an ASCII table or so).The Firebox LEDs are much more than the LEDs on the WRAP board.
But what do you mean by having tried 6.3 and 7.1?
I believe every version of FreeBSD (and OpenBSD) can run on the Firebox III, as long as you know what to change to th files that control the diskcontroller and the network interfaces. What I mean is that you have to build your own modified kernel from the *BSD sources with some modifications to the .c files before compiling it. -
Just referenced that as a code example. But even something that could run via a shell script could be used for simple things.
I've been trying stock FreeBSD on my firebox. I managed a 4.11 custom kernel to get m0n0 running, but the 4.x ata patch I found did not look easily transferable to 6.x or 7.x. I've just been periodically re-testing with new versions to see if some other ata related changes would fix the lockup when initializing the onboard flash. -
Agree, any way to get something from the system "my" the LED panel program will do.
It now compiles to a program that accepts a few parameters through which the LEDs can be controlled.
So I you just want to set something like the ARMED LED during/after booting, it can be done now from a shell script.About the disk controller…
I've been working with two other guys to make the freebsd 4.11 patch work under openbsd 4.4. After a lot of work I discovered that the original 4.11 patch is a bit too much.
In fact, all that was needed (at least for OpenBSD 4.4) was a disable_intr() and enable_intr() around the wdc_output_bytes() call. The ad_vlb_sync() function in the original patch was not needed. We think (but have not tested) that this is also true for freebsd4.11.
A few days ago, I booted a selfmade m0n0wall with FreeBSD 6.4 on my Firebox III without having to modify anything for the diskcontroller.About the network interfaces...
The patch for freebsd 4.11 also works for OpenBSD 4.4 and FreeBSD 6.4.
Since no big changes were made to the if_dc.c file between 4.11 and 6.4, I imagine the patch will also work for other 6.x (and 7.x?) FreeBSD versions.
Under OpenBSD if_dc.c needs the same change as in the freebsd patch.
My Firebox had correct MAC addresses after the patch with FreeBSD 6.4. -
Interesting. A stock 6.4 still hangs at:
ad1: FAILURE - SETFEATURES SET TRANSFER MODE status=51 <ready,dsc,error>error=4 <aborted>ad1: 7 MB < VER4.64> at ata0-slave BIOSPIO</aborted></ready,dsc,error> -
I've seen messages from other people with boxes failing at the 8Mb onboard flash chip.
The FBIII has an 8Mb onboard flash and a 32Mb flashdisk connected to a laptop-ide connector along the side of the motherboard. I haven't has managed to get the 8Mb chip working, you may need to focus on the 32Mb flashdisk (or another CF card with a CF-converter).There are two things you can try:
1. Set both disks to MASTER: there's a jumper with "slave/mstr", set it to mstr (this makes the onboard chip master). Then set your 32Mb flashdisk (or CF card) also to Master. That way, the onboard flashdisk is overruled by the flashdisk/CF and will not be visible anymore.
2. Format the onboard flashdisk: Close the FMT JMPR, turn on the box, wait a while.
Now the onboard flashdisk is empty so BSD won't try to mount it anymore.It this moment I am in the process of rebuilding, so it's going to take a few moments before I can continue testing FreeBSD 6.4 again on my box(es).
-
In addition to my previous message, my freebsd 6.4 bootlog says:
atapci0: <acerlabs m5229="" udma33="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0
x376,0xf400-0xf40f irq 15 at device 15.0 on pci0
ata0: <ata 0="" channel="">on atapci0
ata1: <ata 1="" channel="">on atapci0
…
ad0: 61MB <sandisk sdcfb-64="" vdi="" 1.24="">at ata0-master PIO4
Trying to mount root from ufs:/dev/md0
Found configuration on ad0.I use a 64Mb CF card with a CF converter, set to Master.
I have the SLAVE/MSTR jumper set to MSTR and used the FMT once (a while ago).The box seems to boot just fine.
The NICs say:
dc0: <macronix 10="" 98715aec-c="" 100basetx="">port 0xf000-0xf0ff mem 0xc0001000-0xc000
10ff irq 11 at device 16.0 on pci0
miibus0: <mii bus="">on dc0
dcphy0: <intel 21143="" nway="" media="" interface="">on miibus0
dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: Ethernet address: ff:ff:ff:ff:ff:ffThe ff:ff:ff:ff:ff:ff can be fixed with one small change to the /sys/pci/if_dc.c file (and rebuild the kernel).
With just the old patch, commenting out one line, it now says:
dc0: Ethernet address: 00:90:7f:20:5a:c2So now I'm very curious if your box can boot with only setting the jumpers.
And, ofcourse, I'm still looking for somebody to help me getting the missing parts for the LEDs!</intel></mii></macronix></sandisk></ata></ata></acerlabs>
-
I'm testing with an old laptop HDD. The box hangs on boot if the jumper is set to master and the HDD is set to master or cable select. I have m0n0 1.235 (with a custom kernel) on the flash chip. I just realized that 6.4 will boot in safe mode- it gets the error, but continues instead of hanging.
Back on topic RE: the LEDs- My 700 looks to have the full set of LEDs but the traffic and load bars have an opaque label instead of having clear holes for the LEDs. -
If you look behind the plastic part that 'transfers' the light, you will see that there are no leds on the pcb for the Network- and CPU load. ::)
I think you will have to format the onboard flash so bsd won't hang on scanning it…
Currently I have a brand-new m0n0wall image with freebsd 6.4 and it still boots fine.
As said, I have the jumper set to MSTR and the CF card converter as Master too.Oh, another though just came up:
Before formatting, you could reset the bios to default. It's now configured with fixed parameters for drive0, so if some other disk becomes Master it might not boot properly. After a bios-reset it will be set to some auto-detect.
Bios reset jumper is close to the battery. Box off, jumper to CLR, box on, wait a while, box off, jumper back...To be sure, you might try my fresh freebsd 6.4 mono-image? (almost 7Mb file)
-
If you look behind the plastic part that 'transfers' the light, you will see that there are no leds on the pcb for the Network- and CPU load. ::)
Yeah, you're right. I unscrewed the board and there are no LEDs soldered on. Looks to be missing a couple of chips too.
I did some more testing- while I can get 6.4 to boot in safe mode, 7.2 locks up even in safe mode. Disappointing, as I'd like to get pfSense running on the thing. I may try to isolate what it is about safe mode that is allowing it to boot. I'd guess it's the conservative ATA settings in safe mode. -
I just thought of something else that could cause boot problems.
The BIOS is really old. I've seen it by plugging in a PCI VGA card and connecting a keyboard (yes, the board has a keyboard connector hidden as 4 pins). The BIOS cannot handle "Large" disks. I guess the limit is somewhere around 4Gb or so. You said you use a laptop harddisk, that might be to large for the BIOS.
Don't you have the original flashdisk?About the missing LEDs and chips. Yes, both pcb's (the motherboard and the LED panel) are generic. They saved some money by leaving out some parts. E.g. on the motherboard, the cheaper models (500 and 700) are missing the VPN accelerator and some memory for that chip.
Some boards, either model, have a USB connector (but most don't). But I haven't been able to use that.I'm currently focussing on m0n0wall, since that will fit on the original 32Mb flashdisk.
And also because I've managed to build it with the patches in the kernel. I don't know if I can build my own pfsense.Do you have some webspace or a (large enough) mailaccount where I can send you a working m0n0wall image? The image is roughly 7Mb.
BTW, can you give me a bootlog from the lockup?
-
I've got a ps/2 keyboard connector hacked on to my firebox and use a pci riser card to stick a VGA card in while tinkering. The bios boots fine off an old 12GB laptop drive. I have a drive with 4.11 on it I used while working on getting m0n0wall 1.2 on it. Mine came with the OS loaded on the onboard 8MB flash. I now have m0n0wall there and it works fine. I'd like to get pfSense running on a HDD or flash drive plugged into the IDE connector. I found 6.4 boots (umm, most of the time) with the generic kernel if acpi is disabled. Mine has USB (but I'll have to cut a hole in the case to use it…) I remember it panic'd under 4.11, but I can get an old USB1 network dongle (rue) to be recognized under 6.4. (MB out of the case...)
The log doesn't show anything interesting when it locks. It just stops responding after ad1. I tried fiddling with the bios ide settings without much luck. You should be able to send the file to the email in my profile. -
The image is sent.
You may not see anything in your bootlog about the lockup, but I might see a difference with mine…
Can you send the bootlog to me?
And perhaps also the freebsd image you use (if not to big), so we can see if my box also hangs on it...
