Watchguard Firebox 2 Firebox 3 Front LED Panel Daemon
-
I am sharing some code to drive the front panel LEDs for older Watchguard Firebox II and Firebox III (Stickers with Firebox 750 and Firebox 1000 are common). This router is PC-based (x86), and simply boots just about anything off of CompactFlash, provided a 44-pin IDE/CF adapter is plugged in. It has a PCI bus, and a VGA card needs to be temporarily installed to get in the BIOS and change the usual disk settings. There is a ps/2 keyboard header on the mother board. It has a couple of hidden goodies, like a pair of USB ports and a second serial port on the mother board, but they don't make it out of the case.
Now, for the interesting part: there is a front panel with a number of LEDs for LOAD, TRAFFIC, STATUS (separate LEDS with various labels) and a TRIANGLE with tips and arrows. This panel was found to be interfaced to the board via I/O ports, similar to the good old parallel port.
In the spirit of giving something back, I have decided to write and share a daemon that reads live values from the system and updates the LEDs.
Code on github: https://github.com/fmertz/fbled
If this is of any use to anybody, let me know. Thoughts, feedback, suggestions, all welcome.
-
Project Status:
FreeBSD:
The STATUS, LOAD, TRAFFIC and TRIANGLE TIPS work in FreeBSD 8.2
There are 2 versions:
fbled-bsd gets the statistics from the OS, and updates the LEDs of the firebox II and III. Meant to be run in the background ("./fbled &").
fbled-bsddbg gets the statistics from the OS, and updates a line of text on the command line of any FreeBSD host. Meant to be run on the command line ("./fbled").The code is available here:
https://github.com/downloads/fmertz/fbled/fbled-bsd
https://github.com/downloads/fmertz/fbled/fbled-bsddbgThe source is available here:
https://github.com/fmertz/fbledTo test: Bring the code in as root and make it executable. Run the code as root, and then, from another session, generate some load (maybe "openssl speed") and some traffic (wget <url of="" a="" big="" file="">). For the firewall, have pf log some packets. fbled will capture the log device pflog0, and blip the LEDs if packets involve one of the base Ethernet devices "dc<n>".</n></url>
-
Good stuff! :)
I assume you've seen the Watchguard II info here on the forum and on the monowall forum?
I see you're already active on the dd-wrt forum.
Steve
-
Good stuff! :)
I assume you've seen the Watchguard II info here on the forum and on the monowall forum?
I see you're already active on the dd-wrt forum.
Steve
Thanks, I am trying to provide a minor contribution to a great community. With these boxes being basically PCs, I figured a number of router OSes can be installed, and it would be an interesting challenge to provide a small LED utility program out of one code base for Linux and FreeBSD. Turns out Linux can use at least a couple of C libraries, so I am up to 3 separate builds: Linux/glibc (Vyatta. Debian), Linux/uClibc (DD-WRT, OpenWRT) and now FreeBSD (pfSense). The BSD code is just being worked on, though, no build is ready, yet. Could use a tester later…
PS: I also wanted to publicly thank you for your sharing of the Firebox x750e revitalization effort. Even if pfSense was not my destination, your BIOS patching was great stuff and helped me install my router OS of choice.
-
Thanks. ;D
I don't have a Firebox II. I was looking at getting one when I found you could get the X-core relatively cheaply and went for that instead.
However I'm sure there would be some willing testers here.Steve
-
I have a couple of FB 500's running m0n0 1.2. Haven't messed with them lately, but when I tried FreeBSD did not like the IDE controller. m0n0 was possible due to someone coming up with a patch for FreeBSD 4.x.
-
All,
I updated the second post with the new status of this small project. We have FreeBSD code available for a test run. This code runs at the command line and displays pretend LEDs, as they would update the real ones. The code reads the load and traffic from FreeBSD. Just generate load and traffic and see if it updates. If it does, I can switch the code to update the LEDs.
-
Being fond of St. Jude, I dug out the box of obscure parts and the modified FB 500.
Technically a F2064N, It has the cheesy version of the LED with no traffic or load bars.
I loaded a laptop IDE with a 2.0RC2 snap on another machine. I prepared the box with a pci extender and a vga card, it already has a keyboard connector hacked in. I used a mini-ide cable from an ancient mini-desktop to connect the hdd. I switched the jumper to set the on-board flash memory (now loaded with m0n0 1.236) as slave. Failed on boot at first, but I changed the BIOS from physical to LBA for the drive and it booted. The box dumped when it queried ad1 (the on-board flash), but it didn't lock up and I was able to manually complete the booting. I ran the program and was greeted with:
S[.**…..] L[*….] T[…..] 3[…..]
kind of stuff. Not sure what I'm looking for, but the first * was turning on and off. The box is just sitting there, which probably doesn't help. Anyway it appears to work, I can run some more tests if needed. -
I ran the program and was greeted with:
S[.**…..] L[*….] T[…..] 3[…..]
Anyway it appears to work, I can run some more tests if neededGreat, it runs! Seriously, [….....] simulates each LED, and the letters stand for Status, Load, Traffic and (3)Triangle.
To test it, load up the CPU (maybe with openssl speed, or even several sessions openssl speed &). Check the actual number with the top command. There should be 1 LED for each .15 (.15->[…....], .30->[…...], .60->[…..], 1.2->[****….],…). For Traffic, download a big file with wget. The Traffic is in packets per second (not bytes), each LED is 64 packets per second. I got nothing for triangle for now.
If this works, it means it reads the BSD values ok, and normalizes them. Next step is to try the real LEDs. I have the code, I need to make it available.Thanks for the hard work setting this up. Not sure how the LEDs map in this older model, though. I hope the Status and Triangle map the same.
-
Well, it's decided to page fault today. I'll have to play with it another time. If it's not actually trying to write to the LEDs, maybe the initial testing could be done on something less temperamental than the FB 500…
-
Sorry to hear of your troubles. At this point, the code works under Linux, as well as a "full" FreeBSD 8.2 in a virtual machine on a PC, so we should not be too far off. This is for the data collection part, obviously not the LEDs. I am getting ready to release a version with the LED update code, so maybe someone else can volunteer time and test this out.
PS: If you get a chance, can you confirm that the Ethernet devices are em0, em1 and em2? My (superficial) understanding of the BSD OS is that the applicable driver gets to name the device (as opposed to Linux that tends to consistently name the Ethernet device as eth<n>). My virtual machine is configured with an (emulated) Intel device, and comes up with em0. The applicable Linux driver for the Firebox is the tulip driver. The code tries and count traffic only on the base interfaces, not the software interfaces (like VLAN, bonding, pseudo Ethernet, tunnels,…) to avoid double counting, and the interface name is hard coded for now. Thanks.</n>
-
I released a LED version of the code:
https://github.com/downloads/fmertz/fbled/fbled-bsd
This assumes the Ethernet devices are em0, em1 and em2. Load, Traffic and Status should work. Let me know…
-
The em(4) driver is for Intel Gigabit NICs. Admittedly I've never actually looked into one myself but I can't can't believe any of the Firebox II or III models had gigabit.
The Firebox III appears to have Macronix NICs that come up as dc0, dc1 and dc2. See here.
Steve
-
Thanks for that. I replaced the version on github with Ethernet device as dc0, dc1, dc2.
https://github.com/downloads/fmertz/fbled/fbled-bsd
PS: If someone is still playing around with the code to generate mac addresses (as in the link above), my suggestion is to stick with the Watchguard OUI (the first 3 bytes of the MAC): Template: <00:90:7F:xx:xx:xx>.
Feedback welcome.
-
Yeah, the interfaces are dc's. The 2.0RC will auto-generate macs automatically so you can use the interfaces. BSD has always had trouble with the IDE controller. Mine dumps here:
_ad1: FAILURE - SETFEATURES SET TRANSFER MODE status=51 <ready,dsc,error>error=4 <aborted>ad1: 7MB < VER4.64> at ata0-slave PIO2
GEOM: ad1: geometry does not match label (64h,32s != 2h,32s).
GEOM: ad1: media size does not match label.
Loader variables:
vfs.root.mountfrom=
vfs.root.mountfrom.options=Manual root filesystem specification:
<fstype>:<device> Mount <device>using filesystem <fstype>eg. ufs:/dev/da0s1a
eg. cd9660:/dev/acd0
This is equivalent to: mount -t cd9660 /dev/acd0 /? List valid disk boot devices
<empty line=""> Abort manual inputmountroot></empty></fstype></device></device></fstype></aborted></ready,dsc,error>_
I used to be able to manually continue, but now it faults, I'll have to try starting clean again.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc05c5be2
stack pointer = 0x28:0xd3ff6c44
frame pointer = 0x28:0xd3ff6c74
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq14: ata0) -
ad1: 7MB < VER4.64> at ata0-slave PIO2
GEOM: ad1: geometry does not match label (64h,32s != 2h,32s).
GEOM: ad1: media size does not match label.I am probably stating the obvious, but it looks like the headache is with the internal flash. Have you tried disabling it in the BIOS, or setting it LBA, PHYSICAL, or even the same as reported in the "label" (either 64 heads 32 sectors or 2 heads 32 sectors)? I guess the point is to set it aside so it can boot off of a proper disk…
-
Its great stuff & Thanks ;D
I download fbled-bsd and fbled-bsddbg. They are running in my test box Firebox II (pfSense 2.0 RC nanobsd) from a CF showing
S[.**…..] L[….....] T[….....] 3[….....].
I think both of them are running in debug stage. Would you please update your download page of fbled-bsd to LED version and upload the source code also.Thanks again for your contribution.
-
Is it not on github?
The led driving version looks like it's there:
https://github.com/fmertz/fbled/downloads#download_100802Steve
-
yes, I download from there.
BTW, I have modified fbled version 0.1.1.0 (for DD-WRT) source C code before and made it worked on FBII pfsense 2.0 RC. It initiate the LEDs one by one properly and 'System' LED light up finally. For me, it is hard to extract FreeBSD OS data to post the 'Traffic' and 'Load' LED because I am not a C guy.
-
I updated the second post with the status. At this point, we have an extra feature supported: the triangle tips. The idea is to have users configure the firewall to log whatever packet they want. When pf logs these packets, they are sent to the pflog0 device by default, and fbled can capture them from there. If the packets being logged happen to involve dc<n>, the corresponding LED is blinked.
Under FreeBSD, i followed this:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.htmlAnd then: http://www.openbsd.org/faq/pf/logging.html
PS: At this point, the source code is getting ready to be released. I am trying to complete the port of my original Linux code to FreeBSD the "proper" way, using autoconf and automake. I am not quite at a point where the source just compiles under all combinations, but it is not too far off.
Let me know of any progress. I would love for this project to eventually result in a proper package so folks can just use it in pfSense without headache. A word of caution: this has been made and tested under FreeBSD 8.2, I have not quite managed to test it under pfSense, or on the real hardware.</n>