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

[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!

[iFloris]

Very interesting indeed, I'm going to give this a shot this weekend.

[stephenw10]

Having tried this on my X6000 (X-peak) box it definitely doesn't work. Having said that it didn't do any harm either so if you want to try it on any of the Fireboxes I think it's safe enough.
I think this information is only relevant to the Xe (X550e, X750e etc) boxes.
You'd have thought that Watchguard would have wanted a consistent interface across their models but that doesn't appear to be the case.

Steve

[stephenw10]

I have a much nicer newer program here.
This does fan speed query and setting as well as led changing.

[2.0-BETA5][root@pfSense.localdomain]/var/tmp(54): ./WGXe
WGXe can accept two arguments:
 -f (fan) will return the current fan speed or if followed
    by a number in hex, 00-FF, will set it.
 -l (led) will set the arm/disarm to the second argument:
    red, green, red_flash, green_flash, off

Again this is, currently, only relevant to the Xe Firebox.

Steve

[jimp]

That's still very promising.

You could write a little GUI for it (feel free to look at/steal the code from the blinkled files in the packages repo) and we could put up a package for controlling the LED there. Having it work for one model is better than for none. If nothing else you could just have a setting for which color to make the LED at bootup, and then when the package sync's it could set the LED color.

You could even make a little dashboard widget (they're super simple to write) that shows the fan speed.

[stephenw10]

Thanks for that. It makes me smile every time seeing that LED turn green.  ;D

At the moment I have a bash script in /usr/local/etc/rc.d that sets the fan speed changes the led colour.
Unfortunately the speed returned by the -f switch is only the current setting not the actual speed so I think a dashboard widget might be a bit boring! This is due to the fans only being three wire causing the PWM speed control to confuse the speed sensor output.

The Firebox LCD 'package' hasn't made it into a real package yet. Perhaps we could create a single package for Firebox users? I'm not sure how Watchguard might feel about that though?  ::)

Steve

[jimp]

Yeah there could be a package, either for that model specifically or for them in general. Though a more general package may be a little tougher to get right if you have to pick and choose the model as well as the features supported by that model.

…and as far as what watchguard thinks, it's a community-contributed package. Though even if it wasn't, there probably isn't much they can do. You could just rename it if they whine about the use of their name. It could just be a SmatchBlard BireFox package ;-)

[iFloris]

This is great, hope both the firebox (x core) lcd and this new (Xe) LED / fanspeed make it into packages.
Once again, neat work stephenw10!

[stephenw10]

Some more progress.  :)
I have found the control for the arm/disarm led on the X-Peak box. It's connected to the gpios on the ICH5 southbridge chip, like the Xe, however on the 6300ESB in the x-peak it's controlled by gpio40 (red) and gpio41 (green). The 6300ESB has four special gpios capable of driving leds directly (40-43) which is why I think they are using these instead of the same as the Xe. Anyway these are controlled by the 0x4B9 register on bits 0 and 1. E.g. for red:

[2.0-BETA4][root@pfSense.localdomain]/var/tmp(62): ./writeio 0x4b9 0d
Setting 4b9 to d

And for green:

[2.0-BETA4][root@pfSense.localdomain]/var/tmp(63): ./writeio 0x4b9 0e
Setting 4b9 to e

Unfortunately there is no 'built in' flashing capability for these gpios.  :(
I think watchguard had software flashing as they had fast and slow ability as well.

This new result leads me to believe that the X-core is almost certainly on a southbridge gpio also but I don't have an X-core to hand to test (yet!).

Steve

Edit: Here is a newer version of the program that can control both the Xe and X-Peak boxes.

[iFloris]

Stephenw10, I have two fireboxes that once were a x700 and an x500, only one of which is in 'production' at any given moment.
Is there something I can help test for you?

[stephenw10]

Yep. It's a pretty simple test procedure.
I'm not sure what the southbridge is in the X-core. I had in my mind that it's the ICH0 but now I can't find where I might have read that. Anyway first check your bootup dmesg for the chip. I'm pretty sure it's a 82801ab in which case get the data sheet here. Now the idea is to probe the register addresses and check the result against the defaults listed on the data sheet. Look for what has been changed. On that data sheet the section you are looking for is 8.10.1 GPIO Register I/O Address Map.
Download the two programs I wrote,readio and writeio, from here.
Copy them to your box and change the permissions to 0755 so you can run them.
Then read the address with readio followed by a hex value.
The base address of the gpio is almost certainly 0x480 (but might not be!) so to read the first register:

[2.0-BETA5][root@pfSense.localdomain]/root(22): ./readio 0x480
Reading 480 :81

Except it won't be 81 on your box.
You need to read;
0x480-0x483. GPIO use select
0x484-0x487. GPIO input or output select
0x48c-0x48f. Actual GPIO values.
The numbers you'll get come out in reverse order, 0x480 is the least significant byte of that register.
Although you start out with 32 possible gpios you'll see that only a few are contenders. They need to be set as gpio in use select (1) and set as outout in I/O select (0).
Then use writeio (register, value) to change the numbers and see if the led goes out.
Write everything down!

Steve

Edit: And if none of that works there's a second set of registers as I found out for the X-peak.

[iFloris]

Thanks for all that info, very interesting stuff!

I copied your read and write programs to /etc/rd.d, chmod 0755 and ran the 0x48* commands.
Every answer is the same; Reading 480 :ff.
I'm probably doing something wrong.