[As Good As Solved!] Watchguard Firebox Arm/Disarm LED
-
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.
-
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
-
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
-
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.
-
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 ;-)
