[As Good As Solved!] Watchguard Firebox Arm/Disarm LED

[stephenw10]

Hi All,
This is a pretty trivial in the grand scheme of things but it's annoying me and I'm sure many others.

All the Watchguard Firebox platforms have a front panel LED labeled Arm/Disarm. Under the original Fireware OS this is supposed to indicate when the firewall has started firewalling by changing from red to green. Under pfsense, of course, it doesn't and just stays red (Disarmed). It would be very nice to have it turn green!  ;D
I'm sure this is just a matter of writing a 1 to the correct address but how would one go about this?
There was some talk of this in the Firebox LCD thread where jjgoessens mentioned it should be possible but didn't have a free box to experiment with. Here.
I have a spare box to play with. It's the X750e so maybe not quite the same. I also have an X6000 but it's currently running, I could swap it out though.

Any thoughts?

Steve

[StuartW]

Purely cosmetic, but this can be done in the bios. You can have red,green & even flashing if that's your thing ;)

This is on an x700…

[stephenw10]

Unfortunately not on the X-peak or X-Core-E platforms.  :(
It would be nice to have it turn green at the right time.

Steve

[stephenw10]

I thought I'd poke around in the Watchguard firmware for clues.
It seems that the arm/disarm led is the only one that is software controlled.
It is done like so:

echo green > /proc/wg/frontpanel/led_color
echo fast > /proc/wg/frontpanel/led_blinking

Those devices are setup, under linux, by the frontpanel.o kernel module. Unfortunately I think all the hardware addresses are hardcoded into the binary.  :(
Anyone got a good decompiler?

Steve

[jimp]

If you're lucky, FreeBSD might see them as /dev/led*

At least that's where the standard location is, and where the LEDs for ALIX/Soekris and friends show up.

[stephenw10]

No, I'm not nearly that lucky!
I think the only way of doing this trial and error.
When he added keyboard support to the lcd driver jjgoessens wrote a program to monitor the i/os while pressing the buttons. It turned out to be on the parallel port. On the X-core and X0peak platforms the front panel, including the leds, is connected via a single cable to the main board. It wouldn't surprise me to find that the led is also on the parallel port. It unlikely to damage anything either just randomly switching the parallel port lines.
Thanks for the reply though.  :)

Steve

[tehtrk]

It would be cool, but I don't know what I would use it for. I guess you could make a daemon that made it stay green until a firewall block, then flash red for a second or two.

My first firewall that I put together ran RedWall, and I had it scripted that on block the pc speaker would beep. It was like having a radar detector in my office lol.

[stephenw10]

Hmm, interesting idea. I guess it would depend how much traffic you were filtering as to how much use this would be. Personally I'm just fed up with it showing 'disarmed' all the time!  ;D
I guess you could have it flash green on a firewall hit or when there's a notice/alert in the gui.
I don't have the skills though.
It's impossible to get to real linux prompt in the Watchguard OS otherwise I'd try scanning the I/O space while changing to led status.

Steve

[tehtrk]

I like the idea of having it flash when there's a notice in the gui, and that's easy to do too. The hardest part will be figuring out how we could control it. I've never written a driver and wouldn't even know where to begin.

Edit: spelling

[tehtrk]

@stephenw10:

Hmm, interesting idea. I guess it would depend how much traffic you were filtering as to how much use this would be. Personally I'm just fed up with it showing 'disarmed' all the time!  ;D
I guess you could have it flash green on a firewall hit or when there's a notice/alert in the gui.
I don't have the skills though.
It's impossible to get to real linux prompt in the Watchguard OS otherwise I'd try scanning the I/O space while changing to led status.

Steve

Sorry for the double-post, but could you not chroot into it from a linux livecd? I have not looked at the filesystem on my watchguard CF card, so I don't know how different it is from some of the common linux distros.

[stephenw10]

I'm not entirely sure what you intended.
There are several problems.
In order to test the led at all we have to running on the firebox itself but neither of the boxes I have have video out so it has to be a headless distro/install.
We have the watchguard kernel module but it's a compiled binary built against the watchguard os which is kernel 2.4.26.
The Watchguard OS itself is heavily locked down. As it should be for a security appliance.

I've never tried chrooting into a filesystem but I would assume it has to be the same kernel version?

I'm open to suggestions. I started off running OpenWRT on the box and trying to setup a toolchain to compile for it on another box. The current OpenrWRT is 2.6 kernel though. Might be worth checking out older versions though. Hmm.
I spent a long while trying to get a real prompt on the Watchguard OS but after hours of trying I realised that even if I did I'd need to write a program to scan the IO ports while switching the LED and I can't compile for their custom kernel. It's basically Red Hat by the way.
The best solution I have come up with is simply compiling for pFSense on a FreeBSD box which works great. Playing around with the work of others (see the DD-WRT Firebox II thread) and modifying the code for FreeBSD I have soem basic code for reading and writing to address space. It works well for basic stuff like switching the back light on the LCD (parallel port strobe line, 0x379 bit 1). Not found the arm led on the parallel port though, would be too easy!  ::)

I was considering whether or not the arm/disarm led is likely to be at the same location across the range of models? Certainly not the same place as the Firebox II/III. However those models were from before Watchguard bought out Rapidstream.

Steve

[tehtrk]

For the non-headless mode, this is what I do:
It is a bit cumbersome, but I usually get around the video problem by removing all screws but those on the power supply side. I loosen those screws enough to allow me to tilt the motherboard up while still being grounded well to the chassis. I then place a book or something else non-conductive under the PCI slot of the motherboard and install a pci video card. I believe you can get keyboard ps2 adapters for the strange keyboard header on the motherboard. I hacked up a keyboard and usb motherboard connector for the same purpose.

As for chrooting, it has to be the same architecture (obviously) but I don't believe kernel versions have to be exactly the same. I do seem to remember chrooting across kernel versions. The closer the better, though. I am not sure what you mean by locked down. Is the filesystem encrypted? It's been my experience that unless you are dealing with an encrypted filesystem, chrooting allows you to change the root password, shells, and basically do what you want to the system. Even in cases of encrypted filesystem, there are sometimes ways (beyond my understanding) of getting around it.

You would need to hook up a cdrom to the ide header to be able to do this as well. I will have to try this myself when I pull our old watchguard out of the rack. My curiosity is getting the better of me here.

[stephenw10]

Unfortunately the X-peak and Xe boxes (the two I have) do not have a pci slot. Xe has onboard graphics but a non standard header. It has a pci-e x4 slot but I don't have a suitable graphics card.
Isn't an encrypted filesystem but, for example, is doesn't support single user mode or any other run levels. And I expect to get a bash prompt when logging in as root instead of Watchguards restricted environment. I don't think thats the way to go anyway as we'd have to compile any test programs to run on the WG OS. The only thing we have is a kernel module. It will probably only insmod into WG's kernel.

On the X-core box you can set the led in the bios, yes? And you can set it to flashing independently of the OS. This seems to me to indicate we are dealing with something more than just a gpio pin or parallel port interface. More likely a device on the i2c bus?

Steve

[tehtrk]

On the Firebox X core series, the option is in the bios, yes. There are about 6 different modes that can be set.

[stephenw10]

Here's my latest thinking. Looking at all the chips on the board I think the led (actually two leds) is driven by the Winbond I/O chip. On the Xe box it's a W83627HG (HF on the X-peak but mostly the same) is this chip on the X-core?
It conveniently has two on board led outputs both of which can be set to on, off, flashing at 1Hz or flashing at 0.25Hz. Some work has been done controlling this chip but mostly for OpenBSD and Dragonfly.

As a side note I played around with the SMBus but couldn't scan it correctly. The smbmsg utility isn't included in pFSense for some reason?

Steve

[stephenw10]

Well I've spent far too many hours battling the led and so far it's winning!  ::)

I have fully explored the Winbond chip. It should be supported by the lm(4) driver but although a lot of work has been done it doesn't seem to have made it over to FreeBSD yet.
Using some really horrible programming skills and a lot copy and paste along with many cups of coffee I wrote a few programs to test the chip. No luck with the arm/disarm led I'm afraid. I was sure that would be it. I did manage to control all the internal testings LEDs in the Xe as well as adjusting the fan speed via pwm. Much quieter.  :) Also it opens the possibility of automatic fan control. Perhaps I missed something.
The arm/disarm led comes on at exactly the same moment the bios switches the fan PWM. I seems like it should be on the Winbond chip. Hmmmm.

[iFloris]

@stephenw10:

Hmmmm.

This is pretty neat stuff that you are exploring!

[stephenw10]

It's keeping me entertained and frustrated in equal measures!  ::)
It's definately not the PowerLED and SuspendLED outputs on the Winbond chip as these aren't connected to anything.

[stephenw10]

Haha! Victory is mine!  ;D
After way too much time trying this has been quite an education but…

Very long story short. On the X-Core-E box (an X750E) that I'm using for testing the arm/disarm led is driven by a pair of gpio pins on the ICH6 Southbridge chip. Specifically:
GPIO27 = Red/Disarmed LED
GPIO28 = Green/Armed LED
The led itself is a bi-colour led (obviously) but it is the two pin type so no orange is possible.  :(
The leds can be flashed by setting the appropriate 'blink' register in the ich6.

It seemed incredibly hard to pin down all the information to get this working and even now I'm pretty sure I was lucky.
I'm not yet sure if any of this applies to other Fireboxes but it will be fine on all the Xe type as they all have the same hardware.
The GPIO pins are accessed by writing to the appropriate IO space. That is defined as GPIObase address + offset to gpio level register. I'm not sure how you're supposed to be able to find the base address so I guessed based on other documentation. It seems to be usually at 0x480and it is in the firebox.
The bios sets up the correct registers to enable the GPIO pins and set them as outputs so all you have to do is change the values:
GP27 equates to 0x48f, bit3
GP28 equates to 0x48f, bit4
You need to set one or other to 1 as if both are high the led has +v on both ends.
I wrote a little program, mostly by copy and pasting, here.
I don't seem to have done any damage to my box setting any of the bits at 0x48f so I think it's fairly safe however the original value was 0x0B so in order to change the LED to green:

[2.0-BETA5][root@pfSense.localdomain]/root(50): ./writeio 0x48f 0x13
Setting 48f to 13

And back to red:

[2.0-BETA5][root@pfSense.localdomain]/root(49): ./writeio 0x48f 0x0b
Setting 48f to b

And to make it green flash:

[2.0-BETA5][root@pfSense.localdomain]/root(51): ./writeio 0x49b 0x10
Setting 49b to 10

Anf to make red flash:

[2.0-BETA5][root@pfSense.localdomain]/root(54): ./writeio 0x49b 0x08
Setting 49b to 8

To stop flashing:

[2.0-BETA5][root@pfSense.localdomain]/root(53): ./writeio 0x49b 0x00
Setting 49b to 0

Note that if you set either red or green to flash then it will appear that both red and green are flashing as the steady signal will be flashed by a switching one at the other end of the led.
The original Watchguard firmware has two flashing speeds but I've not found anyway to do that at a hardware level.
The program has no error checking or sanity checking so it's likely you could cause all kinds of damage by entering random figures!  :P
Let me know if this works for you.

Steve

Edit: I've not found how the expansion led is controlled yet, possibly some other means all together.

Edit2: Perhaps only partial victory is mine.  ::) The southbridge in the X-peak hardware is ICH5 which has the same set of GPIOs in the same memory location however they do not control the arm/disarm led on that box. I'm forced to conclude that all the boxes are different and will require more study.  :(

[jdetmold]

wow you've made a huge step! very awesome!