[As Good As Solved!] Watchguard Firebox Arm/Disarm LED
-
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
-
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.
-
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
-
On the Firebox X core series, the option is in the bios, yes. There are about 6 different modes that can be set.
-
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
-
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. -
-
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. -
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 13And back to red:
[2.0-BETA5][root@pfSense.localdomain]/root(49): ./writeio 0x48f 0x0b Setting 48f to bAnd to make it green flash:
[2.0-BETA5][root@pfSense.localdomain]/root(51): ./writeio 0x49b 0x10 Setting 49b to 10Anf to make red flash:
[2.0-BETA5][root@pfSense.localdomain]/root(54): ./writeio 0x49b 0x08 Setting 49b to 8To stop flashing:
[2.0-BETA5][root@pfSense.localdomain]/root(53): ./writeio 0x49b 0x00 Setting 49b to 0Note 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. :(
-
wow you've made a huge step! very awesome!
-
Very interesting indeed, I'm going to give this a shot this weekend.
-
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
-
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, offAgain this is, currently, only relevant to the Xe Firebox.
Steve
-
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.
-
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
-
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 ;-)
-
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! -
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 dAnd for green:
[2.0-BETA4][root@pfSense.localdomain]/var/tmp(63): ./writeio 0x4b9 0e Setting 4b9 to eUnfortunately 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.
-
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? -
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 :81Except 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.
