Watchguard Firebox 2 Firebox 3 Front LED Panel Daemon

[fmertz]

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.

[dotdash]

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.

[fmertz]

@dotdash:

I ran the program and was greeted with:
S[.**…..] L[*….] T[…..] 3[…..]
Anyway it appears to work, I can run some more tests if needed

Great, 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.

[dotdash]

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…

[fmertz]

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>

[fmertz]

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…

[stephenw10]

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

[fmertz]

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.

[dotdash]

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 input

mountroot></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)

[fmertz]

@dotdash:

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…

[ipsec]

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.

[stephenw10]

Is it not on github?
The led driving version looks like it's there:
https://github.com/fmertz/fbled/downloads#download_100802

Steve

[ipsec]

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.

[fmertz]

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.html

And 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>

[ipsec]

fbled-bsd is working.

My interface assigned dc0-WAN, dc1-LAN, dc2-OPT1. 'LOAD' led getting full and 'TRAFFIC" getting 80% to 100% led light up when I start download from OPT1. CPU idle is 0 from 'top'. I thinking it is full of loading there.

The left and top triangle are blinking sometime.

[fmertz]

Great, glad this is working out. Thanks for helping out in the testing.

Not sure I fully grasped your post: is LOAD working right? It should be 1 LED for 0.15 of load, and 1 more LED each time it doubles (.15->1 LED, .30->2, .60->3, 1.2->4…). As you said, you can use 'top' to get the load number. Easiest to load is: 'openssl speed &' multiple times.

For TRAFFIC, it is the sum total of the number of packets per second on all 3 dc <n>interfaces. Kind of harder to really compute as there is a time factor to it, but a WAN download at 1MBps should give you a few LEDs. Again, it is packets per second, not bits/bytes per second.

For STATUS, SYS A should be on, and ARMED should blink.

For the tips, run 'ifconfig' to confirm there is a pflog0 device. Also, run 'pfctl -s rules' to list the firewall rules, and check if any of them have "log" in them. Every time a packet hits that rule, a blip occurs if it involves one of the dc<n>.

PS: I have a Firebox III, and this all works for me under Linux. I know for a fact that Firebox II's have a slightly different implementation for the control register to the LEDs, so I have not completely ruled out LED bugs just yet. Thanks for letting me know if your box behaves exactly as described above.</n></n>

[ipsec]

The LEDs worked as you described. Only one led of SYS A or STATUS was turned on (I can't remember which one, will test it again later). ARMED was blinking correctly. 2 blip occurred on triangle.

I tested it from a Celeron 1.2MHz PC client and made 3 BT sessions download. The TRAFFIC and LOAD LEDs were ascending from one LED to full. It was almost over kill FBII (running at AMD K6-2 400 with 256MB), 'top' at putty ssh stopped to refresh anymore and BT download speed at about 1.5MB/s max on 100Mbp WAN link ( ISP claimed).

I will check ifconfig to cheek pflog0 device and pfctl rule log.

PS: I will test the performance when compare with Fortigate 100 for interest.

[ipsec]

Hi again,

There was not STATUS LED on my FBII box (duno others model). ARMED was blinking and SYS A stayed. More TRAFFIC and LOAD LEDs lit up while packets flowed and cpu became busy.

I captured ifconfig and a few lines of 'pfctl -s rules'.

lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
        options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        nd6 options=3 <performnud,accept_rtadv>pflog0: flags=100 <promisc>metric 0 mtu 33200
enc0: flags=0<> metric 0 mtu 1536

pass in quick on dc1 inet proto udp from 192.168.10.0/24 to 192.168.10.254 port = domain keep state label "USER_RULE: Allow DNS"
pass in quick on dc1 inet proto tcp from 192.168.10.0/24 to 192.168.10.254 port = ntp flags S/SA keep state label "USER_RULE: NTPd service"
pass in quick on dc1 inet proto udp from 192.168.10.0/24 to 192.168.10.254 port = ntp keep state label "USER_RULE: NTPd service"
pass in quick on dc1 inet proto tcp from 192.168.10.0/24 to any port = http flags S/SA keep state label "USER_RULE"
pass in quick on dc1 inet proto tcp from 192.168.10.0/24 to any port = https flags S/SA keep state label "USER_RULE"</promisc></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast>

[fmertz]

@ipsec:

There was not STATUS LED on my FBII box (duno others model).
ARMED was blinking and SYS A stayed.
pflog0: flags=100 <promisc>metric 0 mtu 33200</promisc>

By STATUS, I meant the stack with SYS A, SYS B, ARMED, DISARMED, so it seems all good.
There definitely seems to be a pflog0 device, so that part seems right.
Without necessarily disclosing your firewall rules, are there any rules with "log" in them? ("pfctl -s rules | grep log")
These rules, when hit, would cause the tips to blink for a bit.

Thanks again for the additional research and testing. At this point, it seems to be working well enough to release the code again. I'll do some minor housekeeping and update github.

FWIW, I have not seen this program come up in top with anything in terms of cpu utilization. I have tried to keep it as low load as possible from a code perspective, so I am hoping it is not the cause of the box's high cpu. Under Linux, I even tried and look at slowing down the refresh rate of the LEDs under high load, but the "worker" procedures were running quicker than precision of the clock function I was using. I then figured it was not really worth it. Got to love C code…

[fmertz]

I updated the source on github:

https://github.com/fmertz/fbled