pfSense Forum

pfSense English Support => Hardware => Topic started by: stephenw10 on January 08, 2011, 09:16:07 am

Title: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 08, 2011, 09:16:07 am
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 (http://forum.pfsense.org/index.php/topic,7920.msg107882.html#msg107882).
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: StuartW on January 08, 2011, 10:28:01 am
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...
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 08, 2011, 11:12:25 am
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 09, 2011, 07:15:54 am
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:
Code: [Select]
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: jimp on January 10, 2011, 09:33:33 am
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.
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 10, 2011, 09:54:40 am
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: tehtrk on January 20, 2011, 10:22:02 pm
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.
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 21, 2011, 03:45:37 am
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: tehtrk on January 21, 2011, 01:25:32 pm
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: tehtrk on January 26, 2011, 05:19:02 pm
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.
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 27, 2011, 06:32:26 am
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: tehtrk on January 27, 2011, 10:30:46 am
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.
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 27, 2011, 10:57:49 am
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: tehtrk on January 27, 2011, 11:01:13 am
On the Firebox X core series, the option is in the bios, yes. There are about 6 different modes that can be set.
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 27, 2011, 08:05:50 pm
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
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 28, 2011, 07:04:45 pm
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.
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: iFloris on January 29, 2011, 05:03:27 am
Hmmmm.

This is pretty neat stuff that you are exploring!
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 29, 2011, 09:59:05 am
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.
Title: Re: Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 01, 2011, 04:53:37 pm
Haha! Victory is mine!  ;D
After way too much time trying this has been quite an education but...
(http://lh5.ggpht.com/_oumixD6JTjo/TUiH9FQA98I/AAAAAAAAAIc/lzFPXIxohto/s144/wgled.JPG)

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 (https://sites.google.com/site/pfsensefirebox/home/writeio?attredirects=0&d=1).
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:
Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(50): ./writeio 0x48f 0x13
Setting 48f to 13
And back to red:
Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(49): ./writeio 0x48f 0x0b
Setting 48f to b
And to make it green flash:
Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(51): ./writeio 0x49b 0x10
Setting 49b to 10
Anf to make red flash:
Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(54): ./writeio 0x49b 0x08
Setting 49b to 8
To stop flashing:
Code: [Select]
[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.  :(


Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: jdetmold on February 03, 2011, 12:12:00 pm
wow you've made a huge step! very awesome!
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 04, 2011, 04:18:07 am
Very interesting indeed, I'm going to give this a shot this weekend.
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 04, 2011, 05:49:27 am
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
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 04, 2011, 04:11:29 pm
I have a much nicer newer program here (https://sites.google.com/site/pfsensefirebox/home/WGXe?attredirects=0&d=1).
This does fan speed query and setting as well as led changing.
Code: [Select]
[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
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: jimp on February 07, 2011, 11:15:38 am
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.
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 07, 2011, 11:37:11 am
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
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: jimp on February 07, 2011, 12:15:01 pm
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 ;-)
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 07, 2011, 12:17:41 pm
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!
Title: Re: [Partially Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 09, 2011, 08:24:15 am
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:
Code: [Select]
[2.0-BETA4][root@pfSense.localdomain]/var/tmp(62): ./writeio 0x4b9 0d
Setting 4b9 to d
And for green:
Code: [Select]
[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 (https://sites.google.com/site/pfsensefirebox/home/WGXep?attredirects=0&d=1) is a newer version of the program that can control both the Xe and X-Peak boxes.
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 09, 2011, 09:52:52 am
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?
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 09, 2011, 10:24:47 am
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 (http://download.intel.com/design/chipsets/datashts/29065503.pdf). 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 (https://sites.google.com/site/pfsensefirebox/home/).
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:
Code: [Select]
[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.
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 10, 2011, 03:45:04 am
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.
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 10, 2011, 04:43:49 am
Hmm, Ok.
You issued each inquiry separately like so:
Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(5): ./readio 0x480
Reading 480 :81
[2.0-BETA5][root@pfSense.localdomain]/root(6): ./readio 0x481
Reading 481 :31
[2.0-BETA5][root@pfSense.localdomain]/root(7): ./readio 0x482
Reading 482 :a8

Also ff is not what I'd expect from 0x480, default value are 60 or E0 for 82801AA/AB. Is that the chip that's fitted?
It could be that they changed the base address or that the default base address is different.

Steve


Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 10, 2011, 04:49:36 am
You issued each inquiry separately like so:
Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(5): ./readio 0x480
Reading 480 :81
Also ff is not what I'd expect from 0x480, default value are 60 or E0 for 82801AA/AB. Is that the chip that's fitted?
It could be that they changed the base address or that the default base address is different.

Yes, I ran each command separately, on both the x500 and x700 (some small differences between the two machines despite being supposedly the same), and every answer was the same, for instance:
Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(6): ./readio 0x482
Reading 482 :ff
And on the other machine:
Code: [Select]
[2.0-BETA5][admin@firebox2.domain]/etc/rc.d(8): ./readio 0x485
Reading 485 :ff
Also, no matter what command I issue, the answer is always the same:
Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(11): ./readio 0x2488
Reading 2488 :ff

I'm not sure what chip is inside, is there a way to find out other than opening up the case?

edit: copy paste errors
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 10, 2011, 05:10:08 am
Ok, well that implies we are looking in completely the wrong place!
You should be able to see the chip number in dmesg.

Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(6): dmesg|grep ICH
uhci0: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A> port 0xeb00-0xeb1f irq 23 at device 29.0 on pci0
usbus0: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A> on uhci0
uhci1: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B> port 0xed00-0xed1f irq 19 at device 29.1 on pci0
usbus1: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B> on uhci1
uhci2: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C> port 0xe800-0xe81f irq 18 at device 29.2 on pci0
usbus2: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C> on uhci2
uhci3: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D> port 0xe900-0xe91f irq 16 at device 29.3 on pci0
usbus3: <Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D> on uhci3
ehci0: <Intel 82801FB (ICH6) USB 2.0 controller> mem 0xd05c0000-0xd05c03ff irq 23 at device 29.7 on pci0
usbus4: <Intel 82801FB (ICH6) USB 2.0 controller> on ehci0
atapci0: <Intel ICH6 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0
If isn't an ich device you might try grepping for Intel or something!

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 10, 2011, 05:50:52 am
Allright, I ran dmesg on firebox1 (previously x500) and got the following:

Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/root(1): dmesg|grep ICHatapci0: <Intel ICH2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0
atapci0: <Intel ICH2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0

Then I grepped for Intel, which got me the following:

Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/root(2): dmesg | grep Intel
CPU: Intel(R) Celeron(TM) CPU                1200MHz (1202.73-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6b4  Family = 6  Model = b  Stepping = 4
pcib0: <Intel 82815 (i815 GMCH) Host To Hub bridge> pcibus 0 on motherboard
atapci0: <Intel ICH2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0
CPU: Intel(R) Celeron(TM) CPU                1200MHz (1202.73-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6b4  Family = 6  Model = b  Stepping = 4
pcib0: <Intel 82815 (i815 GMCH) Host To Hub bridge> pcibus 0 on motherboard
atapci0: <Intel ICH2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0

And I still don't see what we were looking for so I ran dmesg without grep, which resulted in a rather odd output as you can see here:

Code: [Select]
[2.0-BETA5][admin@firebox1.virtualflo.com]/root(3): dmesg
re2: link state changed to DOWN
re3: link state changed to DOWN
re4: link state changed to DOWN
re5: link state changed to DOWN
pid 6206 (nice), uid 0: exited on signal 11 (core dumped)
pid 6446 (pfctl), uid 0: exited on signal 11 (core dumped)
pflog0: promiscuous mode disabled
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 done
All buffers synced.
Uptime: 13h38m4s
Rebooting...
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.1-RELEASE-p2 #1: Tue Feb  8 17:40:15 EST 2011
    sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Celeron(TM) CPU                1200MHz (1202.73-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6b4  Family = 6  Model = b  Stepping = 4
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 268435456 (256 MB)
avail memory = 243433472 (232 MB)
wlan: mac acl policy registered
ipw_bss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0700bd0, 0) error 1
ipw_ibss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc0700c70, 0) error 1
wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/.
wpi: If you agree with the license, set legal.intel_wpi.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (wpi_fw, 0xc0873920, 0) error 1
ipw_monitor: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
ipw_monitor: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0700d10, 0) error 1
ACPI Error: A valid RSDP was not found (20100331/tbxfroot-309)
ACPI: Table initialisation failed: AE_NOT_FOUND
ACPI: Try disabling either ACPI or apic support.
cryptosoft0: <software crypto> on motherboard
padlock0: No ACE support.
pcib0: <Intel 82815 (i815 GMCH) Host To Hub bridge> pcibus 0 on motherboard
pir0: <PCI Interrupt Routing Table: 11 Entries> on motherboard
$PIR: Using invalid BIOS IRQ 9 from 2.13.INTA for link 0x63
pci0: <PCI bus> on pcib0
pcib1: <PCIBIOS PCI-PCI bridge> at device 30.0 on pci0
pci2: <PCI bus> on pcib1
safe0 mem 0xefbfe000-0xefbfffff irq 3 at device 6.0 on pci2
safe0: [ITHREAD]
safe0: SafeNet SafeXcel-1141 rng des/3des aes md5 sha1 null
re0: <RealTek 8139C+ 10/100BaseTX> port 0xd500-0xd5ff mem 0xefefa000-0xefefa1ff irq 10 at device 9.0 on pci2
re0: Chip rev. 0x74800000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rlphy0: <RealTek internal media interface> PHY 0 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: [FILTER]
re1: <RealTek 8139C+ 10/100BaseTX> port 0xd600-0xd6ff mem 0xefefb000-0xefefb1ff irq 5 at device 10.0 on pci2
re1: Chip rev. 0x74800000
re1: MAC rev. 0x00000000
miibus1: <MII bus> on re1
rlphy1: <RealTek internal media interface> PHY 0 on miibus1
rlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re1: [FILTER]
re2: <RealTek 8139C+ 10/100BaseTX> port 0xd900-0xd9ff mem 0xefefc000-0xefefc1ff irq 11 at device 11.0 on pci2
re2: Chip rev. 0x74800000
re2: MAC rev. 0x00000000
miibus2: <MII bus> on re2
rlphy2: <RealTek internal media interface> PHY 0 on miibus2
rlphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re2: [FILTER]
re3: <RealTek 8139C+ 10/100BaseTX> port 0xda00-0xdaff mem 0xefefd000-0xefefd1ff irq 12 at device 12.0 on pci2
re3: Chip rev. 0x74800000
re3: MAC rev. 0x00000000
miibus3: <MII bus> on re3
rlphy3: <RealTek internal media interface> PHY 0 on miibus3
rlphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re3: [FILTER]
re4: <RealTek 8139C+ 10/100BaseTX> port 0xdd00-0xddff mem 0xefefe000-0xefefe1ff irq 9 at device 13.0 on pci2
re4: Chip rev. 0x74800000
re4: MAC rev. 0x00000000
miibus4: <MII bus> on re4
rlphy4: <RealTek internal media interface> PHY 0 on miibus4
rlphy4:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re4: [FILTER]
re5: <RealTek 8139C+ 10/100BaseTX> port 0xde00-0xdeff mem 0xefeff000-0xefeff1ff irq 6 at device 14.0 on pci2
re5: Chip rev. 0x74800000
re5: MAC rev. 0x00000000
miibus5: <MII bus> on re5
rlphy5: <RealTek internal media interface> PHY 0 on miibus5
rlphy5:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re5: [FILTER]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
cpu0 on motherboard
unknown: <PNP0c01> can't assign resources (memory)
atrtc0: <AT realtime clock> at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0
uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0
uart0: [FILTER]
uart0: console (9600,n,8,1)
ppc0: <ECP parallel printer port> at port 0x378-0x37f,0x778-0x77a irq 7 drq 3 pnpid PNP0401 on isa0
ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
ppi0: <Parallel I/O> on ppbus0
orm0: <ISA Option ROM> at iomem 0xe0000-0xe0fff pnpid ORM0000 on isa0
unknown: <PNP0c01> can't assign resources (memory)
RTC BIOS diagnostic error 20<config_unit>
Timecounter "TSC" frequency 1202731522 Hz quality 800
Timecounters tick every 10.000 msec
IPsec: Initialized Security Association Processing.
ata1: DMA limited to UDMA33, controller found non-ATA66 cable
ad2: 5729MB <TOSHIBA MK6014MAP N2.10 A> at ata1-master UDMA33
GEOM: ad2s1: geometry does not match label (255h,63s != 15h,63s).
Trying to mount root from ufs:/dev/ad2s1a
pflog0: promiscuous mode enabled
ovpns1: link state changed to UP
re1: link state changed to UP
pid 7510 (rrdtool), uid 0: exited on signal 11 (core dumped)
re2: link state changed to DOWN
re3: link state changed to DOWN
re4: link state changed to DOWN
re5: link state changed to DOWN
pflog0: promiscuous mode disabled
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 done
All buffers synced.
Uptime: 1d3h28m51s
Rebooting...
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.1-RELEASE-p2 #1: Wed Feb  9 15:55:23 EST 2011
    sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Celeron(TM) CPU                1200MHz (1202.73-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6b4  Family = 6  Model = b  Stepping = 4
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 268435456 (256 MB)
avail memory = 243433472 (232 MB)
wlan: mac acl policy registered
ipw_bss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0700be0, 0) error 1
ipw_ibss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc0700c80, 0) error 1
wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/.
wpi: If you agree with the license, set legal.intel_wpi.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (wpi_fw, 0xc0873930, 0) error 1
ipw_monitor: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/.
ipw_monitor: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf.
module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0700d20, 0) error 1
ACPI Error: A valid RSDP was not found (20100331/tbxfroot-309)
ACPI: Table initialisation failed: AE_NOT_FOUND
ACPI: Try disabling either ACPI or apic support.
cryptosoft0: <software crypto> on motherboard
padlock0: No ACE support.
pcib0: <Intel 82815 (i815 GMCH) Host To Hub bridge> pcibus 0 on motherboard
pir0: <PCI Interrupt Routing Table: 11 Entries> on motherboard
$PIR: Using invalid BIOS IRQ 9 from 2.13.INTA for link 0x63
pci0: <PCI bus> on pcib0
pcib1: <PCIBIOS PCI-PCI bridge> at device 30.0 on pci0
pci2: <PCI bus> on pcib1
safe0 mem 0xefbfe000-0xefbfffff irq 3 at device 6.0 on pci2
safe0: [ITHREAD]
safe0: SafeNet SafeXcel-1141 rng des/3des aes md5 sha1 null
re0: <RealTek 8139C+ 10/100BaseTX> port 0xd500-0xd5ff mem 0xefefa000-0xefefa1ff irq 10 at device 9.0 on pci2
re0: Chip rev. 0x74800000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rlphy0: <RealTek internal media interface> PHY 0 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: [FILTER]
re1: <RealTek 8139C+ 10/100BaseTX> port 0xd600-0xd6ff mem 0xefefb000-0xefefb1ff irq 5 at device 10.0 on pci2
re1: Chip rev. 0x74800000
re1: MAC rev. 0x00000000
miibus1: <MII bus> on re1
rlphy1: <RealTek internal media interface> PHY 0 on miibus1
rlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re1: [FILTER]
re2: <RealTek 8139C+ 10/100BaseTX> port 0xd900-0xd9ff mem 0xefefc000-0xefefc1ff irq 11 at device 11.0 on pci2
re2: Chip rev. 0x74800000
re2: MAC rev. 0x00000000
miibus2: <MII bus> on re2
rlphy2: <RealTek internal media interface> PHY 0 on miibus2
rlphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re2: [FILTER]
re3: <RealTek 8139C+ 10/100BaseTX> port 0xda00-0xdaff mem 0xefefd000-0xefefd1ff irq 12 at device 12.0 on pci2
re3: Chip rev. 0x74800000
re3: MAC rev. 0x00000000
miibus3: <MII bus> on re3
rlphy3: <RealTek internal media interface> PHY 0 on miibus3
rlphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re3: [FILTER]
re4: <RealTek 8139C+ 10/100BaseTX> port 0xdd00-0xddff mem 0xefefe000-0xefefe1ff irq 9 at device 13.0 on pci2
re4: Chip rev. 0x74800000
re4: MAC rev. 0x00000000
miibus4: <MII bus> on re4
rlphy4: <RealTek internal media interface> PHY 0 on miibus4
rlphy4:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re4: [FILTER]
re5: <RealTek 8139C+ 10/100BaseTX> port 0xde00-0xdeff mem 0xefeff000-0xefeff1ff irq 6 at device 14.0 on pci2
re5: Chip rev. 0x74800000
re5: MAC rev. 0x00000000
miibus5: <MII bus> on re5
rlphy5: <RealTek internal media interface> PHY 0 on miibus5
rlphy5:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re5: [FILTER]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
cpu0 on motherboard
unknown: <PNP0c01> can't assign resources (memory)
atrtc0: <AT realtime clock> at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0
uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0
uart0: [FILTER]
uart0: console (9600,n,8,1)
ppc0: <ECP parallel printer port> at port 0x378-0x37f,0x778-0x77a irq 7 drq 3 pnpid PNP0401 on isa0
ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
ppi0: <Parallel I/O> on ppbus0
orm0: <ISA Option ROM> at iomem 0xe0000-0xe0fff pnpid ORM0000 on isa0
unknown: <PNP0c01> can't assign resources (memory)
RTC BIOS diagnostic error 20<config_unit>
Timecounter "TSC" frequency 1202731472 Hz quality 800
Timecounters tick every 10.000 msec
IPsec: Initialized Security Association Processing.
ata1: DMA limited to UDMA33, controller found non-ATA66 cable
ad2: 5729MB <TOSHIBA MK6014MAP N2.10 A> at ata1-master UDMA33
GEOM: ad2s1: geometry does not match label (255h,63s != 15h,63s).
Trying to mount root from ufs:/dev/ad2s1a
pflog0: promiscuous mode enabled
ovpns1: link state changed to UP
re1: link state changed to UP
re2: link state changed to DOWN
re3: link state changed to DOWN
re4: link state changed to DOWN
re5: link state changed to DOWN

I don't quite understand why dmesg would be filled with parts of the boot log and why it would even state uptime.
The output of dmesg on my macs looks a lot different, though they are of course running darwin.

This probably doesn't help at all, does it?
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 10, 2011, 07:05:50 am
Agreed, strange output.
I certainly does help. It looks like you've got ICH2 so that's a different datasheet (http://www.intel.com/Assets/PDF/datasheet/290687.pdf) for starters.
If you do a:
Code: [Select]
pciconf -lbYou should see the PCI device and vendor IDs to confirm the chip.
Look for chip=0x24408086 or chip=0x244C8086. That's the LPC-PCI brigbe used to configure the GPIOs.
That command should give you the base pci address and from that you can read the gpio base address and then test the gpios. However on my box it doesn't!  :(

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 10, 2011, 07:15:03 am
Luckily, pciconf -lb does work here.

0x244C8086 shows up as:
Code: [Select]
isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x24408086 rev=0x05 hdr=0x00
atapci0@pci0:0:31:1: class=0x010180 card=0x24408086 chip=0x244b8086 rev=0x05 hdr=0x00
    bar   [20] = type I/O Port, range 32, base 0xff00, size 16, enabled

0x244C8086 isn't in the output.

The full output is as follows:
Code: [Select]
hostb0@pci0:0:0:0: class=0x060000 card=0x11308086 chip=0x11308086 rev=0x04 hdr=0x00
pcib1@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x05 hdr=0x01
isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x24408086 rev=0x05 hdr=0x00
atapci0@pci0:0:31:1: class=0x010180 card=0x24408086 chip=0x244b8086 rev=0x05 hdr=0x00
    bar   [20] = type I/O Port, range 32, base 0xff00, size 16, enabled
safe0@pci0:2:6:0: class=0xff0000 card=0x00010001 chip=0x114116ae rev=0x01 hdr=0x00
    bar   [10] = type Prefetchable Memory, range 32, base 0xefbfe000, size 8192, enabled
re0@pci0:2:9:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
    bar   [10] = type I/O Port, range 32, base 0xd500, size 256, enabled
    bar   [14] = type Memory, range 32, base 0xefefa000, size 512, enabled
re1@pci0:2:10:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
    bar   [10] = type I/O Port, range 32, base 0xd600, size 256, enabled
    bar   [14] = type Memory, range 32, base 0xefefb000, size 512, enabled
re2@pci0:2:11:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
    bar   [10] = type I/O Port, range 32, base 0xd900, size 256, enabled
    bar   [14] = type Memory, range 32, base 0xefefc000, size 512, enabled
re3@pci0:2:12:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
    bar   [10] = type I/O Port, range 32, base 0xda00, size 256, enabled
    bar   [14] = type Memory, range 32, base 0xefefd000, size 512, enabled
re4@pci0:2:13:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
    bar   [10] = type I/O Port, range 32, base 0xdd00, size 256, enabled
    bar   [14] = type Memory, range 32, base 0xefefe000, size 512, enabled
re5@pci0:2:14:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x20 hdr=0x00
    bar   [10] = type I/O Port, range 32, base 0xde00, size 256, enabled
    bar   [14] = type Memory, range 32, base 0xefeff000, size 512, enabled

However, I don't know how to interpret 0xff00 as the base.
Running ./readio gives me the following:
Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(5): ./readio 0xff00
Reading ff00 :0
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 10, 2011, 07:22:00 am
2440 is the ICH2 chip,82801BA, 244C is ICH2-M, 82801BAM. You have the former.
Unfortunately your output is like mine. The base address we need is that of the isab0 device, not listed.
Still this is all interesting stuff!   :D

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 10, 2011, 07:29:13 am
And there I was thinking it did work for me!

So, is there another way of finding out what the base address for lsab0 is?

And I agree that this is all very interesting, though it does go slightly over my head.
Still, it must be said that you are good at explaining what I need to to and what to expect!
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 11, 2011, 06:03:38 am
I have to say I'm learning as I go here.
There must be another way since it's an integral part of the os. I have a feeling it's probably passed to the os by the bios. Certainly the bios code sets up the chipset initially so if it moved the gpiobase thats where it would be stored.
Intel provide a helpful application note for doing just this. Here (http://download.intel.com/embedded/chipsets/appnote/322174.pdf).
They explain how it's all setup and how the registers relate to one another. They even provide example code for finding the gpiobase and the LPC base and it's written for FreeBSD. Unfortunately it's only sample functions and not something that could be compiled.  :(
I don't really want to start messing about trying to write a program to do this. I sure there's FreeBSD package that can do this already I just don't know what it is.

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 11, 2011, 08:30:16 pm
Edit: Don't do this! Perhaps it makes interesting reading for someone. See my post a few below here after Wallabybob pointed out my failure to understand pciconf.  ::)


Here's something that seems to work, if you're feeling brave!  :P I spent ages trying to compile a very simple program but gave up after more compile errors than I could count. Anyway the basic functionality is included in the pciutils package. First install the package:

Code: [Select]
/etc/rc.conf_mount_rw

pkg_add -r pciutils

/etc/rc.conf_mount_ro

rehash

This is a port of the Linux lspci utility with some extra bits.
Fire it up and see what you have:
Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(34): lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04)
00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 04)
00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04)
01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)
05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
05:01.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
05:02.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
05:03.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
05:04.0 Network and computing encryption device: Cavium Networks Nitrox XL N1 Lite

This is my Xe box. You can see the ICH LPC bridge listed has PCI address 00:1f.0 (obviously change this to your address).
So now we can get lspci to spit out the configuration data. This function comes with a danger warning but works fine here:

Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(35): lspci -s 00:1f.0 -xxx
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
00: 86 80 41 26 07 01 00 02 04 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 41 26
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 04 00 00 80 00 00 00 81 04 00 00 10 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 0b 0c 05 0a d0 00 00 00 0b 80 80 09 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 10 00 0f 34 81 00 00 00 91 02 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 20 02 00 00 00 00 00 00 00 00 00 00 00 03 00 00
b0: 00 00 00 00 00 00 00 00 55 55 55 55 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 33 22 11 00 67 45 00 00 c0 c0 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 01 c0 d1 fe 00 00 00 00 80 0f 04 00 00 00 00 00

So now we have the important part of the configuration table. Looking at the datasheet for the ICH6 the GPIO base address is stored in registers 0x48-0x4b. You have to read it in reverse: 00 00 04 81. i.e 0x481 Except that reading the datasheet more closely we see that "bit 0 is hardwired to 1 to indicate I/O space" for some reason.  ::) So the actual address is 0x480. Which we know to be true.

This procedure should work fine for you except that in the ICH2 the gpio base address is at 0x58-5B instead.

Steve

Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: wallabybob on February 11, 2011, 09:31:39 pm
The FreeBSD utility pciconf can also be used to get this information. There is a man page at http://www.freebsd.org/cgi/man.cgi?query=pciconf&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html (http://www.freebsd.org/cgi/man.cgi?query=pciconf&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html)
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 12, 2011, 05:47:15 am
The FreeBSD utility pciconf can also be used to get this information.

Doh!  :-[
It was like three in the morning by the time I wrote that.

The same result can be had with:

Code: [Select]
[2.0-BETA5][root@pfSense.localdomain]/root(10): pciconf -r pci0:0:31:0: 0x48
00000481

On the X-core box with the ICH2 you need to look at 0x58 but the LPC device is in the same place so:

Code: [Select]
pciconf -r pci0:0:31:0: 0x58

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 12, 2011, 07:03:15 am
On the X-core box with the ICH2 you need to look at 0x58 but the LPC device is in the same place so:

Code: [Select]
pciconf -r pci0:0:31:0: 0x58

Steve

Progress! That is to say, the command gives me a response on my firebox.
The response is as follows:
Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/root(1): pciconf -r pci0:0:31:0: 0x58
00004081

I'm not sure what this means though!
What is the next step?
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 12, 2011, 07:11:53 am
Aha! That's disappointingly similar to 480, open to confusion but it looks as though the GPIObase address is 0x4080.
The next setp is to re-try the instructions from here (http://forum.pfsense.org/index.php/topic,32013.msg171474.html#msg171474) but using 0x4080 in place of 0x480.
Hopefully you should get something other than all ff or 0.

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 12, 2011, 07:18:35 am
The next setp is to re-try the instructions from here (http://forum.pfsense.org/index.php/topic,32013.msg171474.html#msg171474) but using 0x4080 in place of 0x480.
Hopefully you should get something other than all ff or 0.

Steve

Indeed, the numbers are so alike that I first thought I had gotten the same response as you did.

And now, with your help, readio has given me an answer other than ff!
Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(4): ./readio 0x4080
Reading 4080 :80
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(5): ./readio 0x4081
Reading 4081 :31
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(6): ./readio 0x4082
Reading 4082 :20
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(7): ./readio 0x4083
Reading 4083 :1a
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(8): ./readio 0x4084
Reading 4084 :ff
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(9): ./readio 0x4085
Reading 4085 :ff
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(10): ./readio 0x4086
Reading 4086 :0
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(11): ./readio 0x4087
Reading 4087 :0
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(12): ./readio 0x408c
Reading 408c :0
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(13): ./readio 0x408d
Reading 408d :0
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(14): ./readio 0x408e
Reading 408e :bf
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(15): ./readio 0x408f
Reading 408f :9
Unfortunately, some of the responses are still 0 or ff.
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 12, 2011, 07:46:06 am
Unfortunately, some of the responses are still 0 or ff.

Not a problem, they should be.
So:

Code: [Select]
Experimental findings of ICH2 IO space;  

0x4080-0x4083 Set pins as gpio or native fuctions. 1=gpio
Default 1a003180                0001 1010 0000 0000
Found  1a203180       0001 1010 0010 0000

0x4084-0x4087 Set gpios as input or output. 1=Input
Default 0000ffff
Found 0000ffff bit 1 is input. Possible outputs are 0000 0000 0000 0000 1111 1111 1111 1111

  1 1 1    1  (set as gpio & set as output)

0x408c-0x408f GPIO Levels
Default 1f1f0000
Found 09bf0000          0000 1001 1011 1111

Hmm, doesn't really line up properly on the forum but.. Edit: Better

Only four pins are both enabled as GPIO and set as ouput and only two of those are set to 1. So try seting either of those to 0.

Code: [Select]
./writeio 0x408f 0x01
Return it to it's original value after or things get confusing! Or:

Code: [Select]
./writeio 0x408e 0x9f
One of those should switch off the red led.

Once we know that we can work on green and flashing!

Steve



Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 15, 2011, 04:59:29 am

Only four pins are both enabled as GPIO and set as ouput and only two of those are set to 1. So try seting either of those to 0.

Code: [Select]
./writeio 0x408f 0x01
Return it to it's original value after or things get confusing! Or:

Code: [Select]
./writeio 0x408e 0x9f
One of those should switch off the red led.


Thanks, I've been meaning to try this.
However, when you write 'Return it to it's original value after or things get confusing!', how do I know what the original value was?
0x408e gave me a response of bf, so would that be 0xbf?
Or am I being nonsensical?
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 15, 2011, 06:11:31 am
Yes, bf is 0xbf. I never really expected anyone else to be using the program so didn't spend much time sanitising the output, sorry.  :P  (in fact I don't think it matters if you include the 0x or not)
When you change 408e from 0xBF to 0x9F what you are actually doing is changing only 1 bit (B=1011 and 9=1001). I say to change it back since if you change more than one thing at a time it's hard to know what change had what effect.
The fact is that we don't know what, if anything, the other gpios are connected to. It's better to return them to their original state. On the boxes I have here none of the random number setting I have done had any ill effects and it all gets reset by the bios at boot so don't worry.
Good luck!

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 15, 2011, 08:39:37 am
After trying both ./writeio 0x408f 0x01 and ./writeio 0x408e 0x9f, I found the following:
The first command (0x01) makes the red led blink red / off (looks like it blinks synchronised to re0, but I'm not sure).
The second command (0x9f) does nothing (seemingly).

Afterwards, I reset 0x0408f to 0x09 and 0x408e to 0xbf.
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 15, 2011, 10:18:51 am
Hmmm, interesting. Well it's something at least. It proves that the led is driven by the gpios i some way.
So it doesn't blink regularly, like once a second?

Anyway it seems that 0x408f bit 3 is red on.
To find green leave red off (or blink in this case) and try turning on bits 1 or 4 i.e.

./writeio 0x408f 0x11 or 0x03.

Normally the blinking action is set by the blink register which for you should be at 0x409b, to correspond with the ouputs at 0x408f. Try reading 0x409b, by default it is 00.

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 15, 2011, 03:04:10 pm
I've tried both settings.

./writeio 0x408f 0x11 turns the led green and blinks at fast but irregular intervals.
./writeio 0x408f 0x03 does the same, but turns the led back to red.

I've reset to 0x11 now, so at least the arm led is green!
This is awesome.

Edit: actually, the blinking is regular. About four blinks per second.
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 15, 2011, 05:11:15 pm
Hmm, even more interesting.
So 0x408f set to 03 is the same as 01 yes?
The built in blink function is definitely 1Hz so if it's blinking at around 4Hz then something else is doing it. Still worth checking the blink registers at 0x409A and 0x409B.
It's likely only two pins actually do anything giving only 4 possible states. It appears to be 0x408F bits 3 and 4. We have tried:
01 which is default, solid red
00 red flashing
10 green flashing
11 haven't tried that yet.

Try ./writeio 0x408f 19

As I said there are four possible gpio pins so 16 possible states. Since there is some confusion I think we may just have to work through them.

Steve

Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 16, 2011, 02:02:10 am
Good guess!  ./writeio 0x408f 19 turns the led green without blinking.

Edit: Seeing as you now know how to turn the led green on both the x peak and x core devices, perhaps someone can help you with building a package for everyone using a flavor of the firebox?
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 16, 2011, 04:12:26 am
Edit: Seeing as you now know how to turn the led green on both the x peak and x core devices, perhaps someone can help you with building a package for everyone using a flavor of the firebox?

That's the long term plan. Hopefully we can also include the lcd driver so we can have a single package for Firebox users that doesn't get broken every time you update.

It seems like we're missing something here though. The control is very different to the other two boxes.
Can you tell me what the out outs of these are:

./readio 0x409a
./readio 0x409b

Do you have bios access to your box? You can set the initial led status in the bios on the X-core. I can't remember what you could set it to but it was a load of different settings. We should be able to get, at least, all of those.

Anyway it seems like we are mostly victorious!  ;D

Steve
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 16, 2011, 04:15:41 am
Nice, but strange that the control is so very different.
Output for the commands is:
Code: [Select]
[2.0-BEAT5][admin@firebox1.domain]/etc/rc.d(3): ./readio 0x409a
Reading 409a :4
[2.0-BEAT5][admin@firebox1.domain]/etc/rc.d(4): ./readio 0x409b
Reading 409b :0

And no, I don't have access to the bios.
It has been at least ten years since I touched a pci video card..
Title: Re: [More Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 16, 2011, 04:39:24 am
Clearing out some stuff over the weekend I found an ISA video card!  Couldn't bring myself to dispose of an antique like that.  ::)

Hmm, 00 04 indicates that none of the gpios are set to flash, yet they are flashing....

./writeio 0x408f 0x03 does the same, but turns the led back to red.

When you said that did you mean just fast flashing red or did you mean flashing red then green?

With the led set to green solid (0x408f = 0x19) try setting 0x409B to 0x10. It should make the led flash slowly (about 1Hz) but it may be between green and (some other state!).

Steve
Title: Re: [Almost Completely Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 16, 2011, 07:33:23 am
When you said that did you mean just fast flashing red or did you mean flashing red then green?
With the led set to green solid (0x408f = 0x19) try setting 0x409B to 0x10. It should make the led flash slowly (about 1Hz) but it may be between green and (some other state!).
OT: ISA, amazing! I think the only time I ever had anything to do with ISA was when I tried to upgrade my (then modern!) 386.

But I digress. What I meant by the same but ted was that the led flashed as fast as when it was green, but that it was the red led that was flashing.
So just red flashing.

./writeio 0x409B 0x10 results in slow (1 second/Hz) flashing, alternating between red and green (as you thought it might).

To iterate what we've found so far:

./writeio 0x408f 0x11    - turns the led green and blinks (fast)
./writeio 0x408f 0x03    - turns the led red and blinks (fast)
./writeio 0x408f 19       - turns the led green without blinking
./writeio 0x409B 0x10   - turns the led green and blinks (slowly)
./writeio 0x0408f 0x09  - turns the led red without blinking

Is that correct?
And does this give us the means to control the led completely, or is there something else that we need to test?
Title: Re: [Almost Completely Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 16, 2011, 08:00:15 am
That looks correct.
Since 0x03 and 0x01 are the same it appears the other two gpios do not have any function for the led.

One weird thing is that there's no 'off'. As I said in an earlier post I think that Watchguard probably used a software method to flash the leds since they have fast and slow flash on all the boxes. However to do this you would need an off state to switch to.

I can certainly plug those numbers in my program and we will then have control via an easy to use command line.
Something tells me we're missing something though. This is definitely different to the other boxes where the gpios control the led directly, here we seem to be talking to some intermediate piece of hardware.

Steve
Title: Re: [Almost Completely Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 16, 2011, 07:55:38 pm
Here is the new program incorporating all the new values for the X-Core.
Obviously rename it WGXepc (remove the .png extension). Copy it to your box and chmod it to 0755. Run it!  ;D

Because the new memory locations were quite high I felt it would be dangerous to simply write all the values on every box, which is what the previous programs did. This new one tries to find out which Firebox model it's running on by reading the gpio_sel register and comparing it with known values. It works fine for me here on the three boxes I've tested it on but I don't have an X-Core and I can imagine that a different bios version might cause detection problems. Deal with that if it happens. Hopefully this might stop people randomly installing it on any box and messing with some important setting!  ::)

It seems to run fine on 1.2.3 and 2.0Beta5.

Steve

Edit: Now tested as working on the X-core boxes and under 2.0RC2
Title: Re: [Almost Completely Solved!] Watchguard Firebox Arm/Disarm LED
Post by: jimp on February 16, 2011, 08:02:19 pm
For bonus points, convert it to an led(4) driver :-)

http://www.freebsd.org/cgi/man.cgi?query=led&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/led/

See also: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/geode.c
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: fastcon68 on February 17, 2011, 04:26:42 pm
will this work on the embedded version 1.2.3?
RC
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 17, 2011, 05:07:11 pm
It should work fine with any install type.
I've tested it with NanoBSD installs of 1.2.3-release and 2.0Beta.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: brcisna on February 17, 2011, 05:21:42 pm
stephenw10.

I been trying to follow this thread as of late. I am a bit confused on WG FB hardware versioning? Will your proggy work on an x550 WG FB?
If so,Ill give it a spin in a couple days and post a report.

Thanks,
Barry

Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 17, 2011, 06:59:16 pm
I'm assuming you mean the X550e right?
If so then yes it should work fine. I used the X750e to test it and that's the same box but with a 4 port add on card.
You get all the functions on that box.

Steve

Edit: Just to add, if you have an unusual Firebox then it probably won't be detected as a Firebox and the program will just exit. Even if it happens to have the gpio_sel register set in such a way that it is detected as a Firebox the likely result is that nothing will happen. Even if, in a bizarre coincidence, there is something present at the gpio being altered it all gets reset by the bios at boot time so you can just turn it off and on again.  ;D
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: iFloris on February 19, 2011, 11:24:38 am
Sorry for the delay.

I've tried the program and it seems to work!

Code: [Select]
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(15): chmod 0755 WGXepc
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(16): ./WGXepc
Found Firebox X-Core
WGXepc Version 0.3 17:2:2011
WGXepc 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
Not all functions are supported by all models
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(17): ./WGXepc -l green
Found Firebox X-Core
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(18): ./WGXepc -l red
Found Firebox X-Core
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(19): ./WGXepc -l red_flash
Found Firebox X-Core
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(20): ./WGXepc -l green_flash
Found Firebox X-Core
[2.0-BETA5][admin@firebox1.domain]/etc/rc.d(21): ./WGXepc -l green
Found Firebox X-Core

The commands do what they are supposed to, and response is immediate.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 19, 2011, 12:40:38 pm
Excellent!  ;D
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: brcisna on February 20, 2011, 05:51:29 pm
stephen,

I will have to look at my WG FB. I am thinking mine is not the 'e' suffix? Doesn't the 'e' suffixed WG FB's have the gigE ethernet?
Mine only has 10/100 nics in it. I should know what the model is too?:(.
Won't know for a couple days,when I get back to work. I'll give your prog a spin regardless and report.
I guess,I'm not real clear. Does your prog do the 'native' green to red routine at bootup,when everything is up, ,or is it simply capable of you manually toggling the led to do whatever you want it to?

thanks,
Barry


Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 20, 2011, 07:29:28 pm
Hmm, x550 no e?
Be interesting to see if it detects it.
At the moment the program is 'manual' only.
It's easy to put a bash script in /usr/local/etc/rc.d to make it go green at the end of boot.

Steve

Edit:
I can't find any mention of the x550 on Watchguard's website, but a lot of the good information is hidden away. The models I haven't yet any gpio information on are:
X-Peak-E; almost certainly the same as the X-Core-E but with more ram, faster CPU and vpn card.
SSL-100 (http://www.watchguard.com/help/docs/ssl/3/WatchGuard_SSL_100_Hardware_Guide.pdf); looks like an X550E with different software, maybe an encryption card, 2GB ram!
SSL-500/1000 (http://www.watchguard.com/help/docs/ssl/2/v2wgssl_hardwareguide.pdf); also same as X550E.
SSL-Core (http://www.watchguard.com/help/docs/FireboxSSL_CoreHardwareGuide.pdf); looks like an X-Core but has different software using the harddisk bay!

All the other newer models are still way too valuable to show up on Ebay!  ::)

Edit: X-Peak-E confirmed working. Same board as the X-Core-E.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: brcisna on February 21, 2011, 08:34:57 am
stephenw10,

I miscombobulated on the model number. My FB is x500 ( no 'e').
I believe this is/was the first generation 1u cased FB. It has the 1.2GHZ celeron cpu,FYI.
I would guess the mobo is significantly different than the board you were testing on.
The second gen 1u cased FB's were numbered x550e,x750e,etc,I believe the 'e' designates gigE nics?
In three-four days ill down your code and try it on this box and file a report,,,:)
FWIW. This simple box does handle two 3mb up/down connections with about 350 pc's and 1000 users,(possible)
Using squid,squidGuard,Lightsquid, load balance,failover.

Take Care,
Barry

Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 21, 2011, 09:32:25 am
X500 (all the X-Core boxes) have been confirmed working. No off mode for the led for some reason.

Steve
Title: Re: [Almost Completely Solved!] Watchguard Firebox Arm/Disarm LED
Post by: hmeister on May 03, 2011, 08:44:13 am
Here is the new program incorporating all the new values for the X-Core.
Obviously rename it WGXepc (remove the .png extension). Copy it to your box and chmod it to 0755. Run it!  ;D

Because the new memory locations were quite high I felt it would be dangerous to simply write all the values on every box, which what the previous programs did. This new one tries to find out which Firebox model it's running on by reading the gpio_sel register and comparing it with known values. It works fine for me here on the three boxes I've tested it on but I don't have an X-Core and I can imagine that a different bios version might cause detection problems. Deal with that if it happens. Hopefully this might stop people randomly installing it on any box and messing with some important setting!  ::)

It seems to run fine on 1.2.3 and 2.0Beta5.

Steve
Steve - what syntax do I use when I copy this to the /tmp dir. to run this? (yes-will rename it first!)
thx
H.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on May 03, 2011, 09:18:58 am
You can use the upload feature in the web gui to copy it /tmp. However /tmp only exists in memory so you have to move it somewhere else if you want it to survive a reboot.
It's up to you where you put it but /usr/local/bin seems good. Since you are running a full install you shouldn't have any problems with a read-only filesystem.
You can use WinSCP (if you're running Windows) to copy the file directly to /usr/local/bin.

Then you can put a script in /usr/local/etc/rc.d that runs on startup.
Here's mine, called WGXepc.sh
Code: [Select]
#!/bin/sh
#
/usr/local/bin/WGXepc -l green

Steve

Edit: And make sure the file permissions are set to 0755 or it won't run. You can do this from WinSCP or from the command line:
Code: [Select]
chmod 0755 /usr/local/bin/WGXepc
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: hmeister on May 03, 2011, 09:31:43 am
Steve...
Thanks - will set this up now...
H.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: hmeister on May 03, 2011, 11:40:00 am
You can use the upload feature in the web gui to copy it /tmp. However /tmp only exists in memory so you have to move it somewhere else if you want it to survive a reboot.
It's up to you where you put it but /usr/local/bin seems good. Since you are running a full install you shouldn't have any problems with a read-only filesystem.
You can use WinSCP (if you're running Windows) to copy the file directly to /usr/local/bin.

Then you can put a script in /usr/local/etc/rc.d that runs on startup.
Here's mine, called WGXepc.sh
Code: [Select]
#!/bin/sh
#
/usr/local/bin/WGXepc -l green

Steve

Edit: And make sure the file permissions are set to 0755 or it won't run. You can do this from WinSCP or from the command line:
Code: [Select]
chmod 0755 /usr/local/bin/WGXepc

Steve - working great!
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on May 03, 2011, 04:09:16 pm
Good to hear.   ;D

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: fastcon68 on May 28, 2011, 10:15:48 pm
I added you LED package and it works perfectly.  I got both your LCD package and your ARM/Disarm light package running and they are working great.

Since the lcd backlight is not working correctly, I was wondering if I could open the case up and take a USB light and add it internally so you could see the display.  How do you think it would be to do that.
RC
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: woc38 on July 14, 2011, 02:55:08 pm
Steve, just to let you know: your arm/disarm LED script is working fine on my Core X700! Thanks!

pfSense 2.0-RC3 (i386) built on Thu Jul 14 02:02:34 EDT 2011 (nanobsd 4g) running on a 4GB Hitachi microdrive.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on July 15, 2011, 05:12:35 pm
Thanks for the feedback.  ;D

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: dmitche on September 13, 2011, 02:55:44 pm
For those who are complete noobs at this like me, I thought I would add two pointers to help you out.

Don't forget the following post to display different settings:
http://forum.pfsense.org/index.php/topic,7920.msg135626.html#msg135626 (http://forum.pfsense.org/index.php/topic,7920.msg135626.html#msg135626)

Thanks stephenw10!
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on September 13, 2011, 03:08:33 pm
In Windows, to use WinSCP, your login should be root, admin never worked for me. root will allow you to change file permissions.

Good point, I've become too used to logging in as root. A bad habit.
The reason is that the admin account always shows the menu when you log in via ssh, root does not have to.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on December 07, 2011, 11:15:32 am
Hmm I seem to omitted to attach the source for this.  :-[
Not very open.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: bryansxviper on January 30, 2012, 09:03:01 pm
Yep!

I am a new pfsense user and also have a firebox x700. Just did the led fix and its working great. Running 4GB CF card with pfsense 2.0.1-Release.

Thanks.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on January 31, 2012, 04:54:09 am
Another firebox resurrected.  ;D
With any luck we might be able to get this included with the lcd driver soon. Stuck on some bugs at the moment though. I'll post here when things are closer to working.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 01, 2012, 04:34:15 am
Another firebox resurrected.  ;D
With any luck we might be able to get this included with the lcd driver soon. Stuck on some bugs at the moment though. I'll post here when things are closer to working.

Steve

So there are bugs....  ;D  Good to know, because my Light will not turn/change color no mater what i do, by script or by manual running the prog, its a no go.

When it did not work, i just ignored it and accepted that it would not work.
But now that you mention that there might be bugs in it i want to give it a go and see if i can get it to work.
So any pointer would be helpful to where to start looking....

I am running pfSense-2.0.1-RELEASE-2g-i386-nanobsd.img.gz and the program runs like it should, no errors or feedback when i run it and nothing happens.

So if you think this could be a "bug" let me know and i will give you all the info you need..  ;)
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 01, 2012, 06:23:43 am
The bugs I mentioned are in the LCD driver/package not WGXepc. Since lcdproc includes code for associated leds we hoped to eventually have the leds controllable through the lcd driver.
WGXepc should be working for any firebox however there are some models that are untested.
Which box is not working? What happens when you run the program?

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 01, 2012, 06:59:05 am
it is a x500 and when i run it, it looks like it run's it and just goes to next line like this:

#WGXepc -green
#

No error no nothing, and the LED stays red, have tried the blink also but same result, and have checked that the permissions are correct too  ???
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 01, 2012, 07:15:43 am
Hmm, interesting.
The code is absolutely terrible!  :D I'm embarrased to release the source. So I could have easily overlooked some input condition that could causer that. However it should either operate correctly or spit out a message showing the correct syntax. Then it tries to recognise which box you have and either sets the led colour or displays a message saying 'you have an unknown box' or something similar.
Anyway the correct syntax is:

Code: [Select]
WGXepc -l green
Try that.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 01, 2012, 07:28:56 am
i am pretty sure i did use -l when trying to get it to work but will check my script/manual tonight when done at work..
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 01, 2012, 02:20:15 pm
Hi Steve

as you can see from pic attached, that the app does run, gives no error.
And also you can see if i run it without any argument it does show the options, and this shows that the premissions are ok on the app...

So you can see the enigma i have ...  ::)

Could it be hardware problems?? I could pop in a 1.2.3 card and see if it work there...  :)
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 01, 2012, 03:22:18 pm
Hmmm. Interesting.
Let me look through the code again....
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: fmertz on February 02, 2012, 10:52:26 am
it is a x500
I am working on including the LED support in the LCD driver. Can you start by answering this:

http://forum.pfsense.org/index.php/topic,44034.msg239376.html#msg239376 (http://forum.pfsense.org/index.php/topic,44034.msg239376.html#msg239376)
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 02, 2012, 04:07:42 pm
it is a x500
I am working on including the LED support in the LCD driver. Can you start by answering this:

http://forum.pfsense.org/index.php/topic,44034.msg239376.html#msg239376 (http://forum.pfsense.org/index.php/topic,44034.msg239376.html#msg239376)

Not sure what u want an answer too...
Do you want me to run this: lcdproc? if so what do you want me to look for?
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 02, 2012, 04:35:56 pm
Nope. We need the output of this command:
Code: [Select]
pciconf -r pci0:31:0 0:256
Run it at the console. We need it to develop the code that determines which model you have.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 03, 2012, 02:44:11 am
Nope. We need the output of this command:
Code: [Select]
pciconf -r pci0:31:0 0:256
Run it at the console. We need it to develop the code that determines which model you have.

Steve

AHA, here is the result, hope it helps:
[2.0.1-RELEASE][root@Host.name]/root(1): pciconf -r pci0:31:0 0:256
24408086 0280000f 06010005 00800000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00004001 00000010 00000000 00000000
00000000 00000000 00004081 00000010
09060b0c 000000d0 0a058080 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00005475 00000000 00000000 00000000
00000200 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00004004 00000000 00000000
00002002 00001f02 00000004 00000000
c0000010 14050000 00112233 45670291
017c000f 00000000 00000f47 00000200
ffffffff
[2.0.1-RELEASE][root@root@Host.name]/root(2):
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 03, 2012, 05:12:05 am
Thanks for that!  :)
Interesting looking at that and comparing it with Tix's from his X700, here (http://forum.pfsense.org/index.php/topic,44034.msg239800.html#msg239800).
They are almost identical but there is a difference.
Do you have any extra hardware in your box?
Hmm....

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 03, 2012, 05:21:42 am
Thanks for that!  :)
Interesting looking at that and comparing it with Tix's from his X700, here (http://forum.pfsense.org/index.php/topic,44034.msg239800.html#msg239800).
They are almost identical but there is a difference.
Do you have any extra hardware in your box?
Hmm....

Steve

Can not remember that i did see anything special in it when i had it open last time, compared to the first x500 i had that the LED prog did work on.
But i will crack it open again and have a look if needed...
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 03, 2012, 05:46:26 am
Aha!
The correct output should be:
Code: [Select]
[2.0.1-RELEASE][root@pfsense.fire.box]/bin(20): WGXepc
Found Firebox X-Peak
WGXepc Version 0.3 17:2:2011
WGXepc 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
Not all functions are supported by all models

I suspect that you somehow have an old version of the program. Either that or it's been corrupted or your box isn't outputing some text! (unlikely).
Try downloading it again.

Steve

Edit: In fact looking again you can see in the usage text is says 'WGXe' which is the first version of the program I wrote and only worked with the Xe box. You must have renamed it WGXepc without realising.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 03, 2012, 06:02:41 am
Aha!
The correct output should be:
Code: [Select]
[2.0.1-RELEASE][root@pfsense.fire.box]/bin(20): WGXepc
Found Firebox X-Peak
WGXepc Version 0.3 17:2:2011
WGXepc 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
Not all functions are supported by all models

I suspect that you somehow have an old version of the program. Either that or it's been corrupted or your box isn't outputing some text! (unlikely).
Try downloading it again.

Steve

Edit: In fact looking again you can see in the usage text is says 'WGXe' which is the first version of the program I wrote and only worked with the Xe box. You must have renamed it WGXepc without realising.

Well done spotting that one, i will get find the newest version and test it and let u know. But not sure how i managed to rename the old version...
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 03, 2012, 06:23:01 am
Perhaps someone else has uploaded a renamed copy.  :-\

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 03, 2012, 06:29:30 am
I took the file that you attached on your reply #59 in this thread and now the output looks alot better.
I am not physical close to it now so can not check bet still output looks promising:


[2.0.1-RELEASE][root@host.box]/usr/local/bin(11): ./WGXepc2
Found Firebox X-Core
WGXepc Version 0.3 17:2:2011
WGXepc 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
Not all functions are supported by all models
[2.0.1-RELEASE][root@host.box]/usr/local/bin(12): ./WGXepc2 -l green
Found Firebox X-Core
[2.0.1-RELEASE][root@host.box]]/usr/local/bin(13):

 ;D
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: fmertz on February 03, 2012, 12:28:37 pm
2440 8086
Normal 82801BA for X-Core, Device 2440 ICH2, Vendor 8086 Intel.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Unubtanium on February 07, 2012, 06:18:54 am
I took the file that you attached on your reply #59 in this thread and now the output looks alot better.
I am not physical close to it now so can not check bet still output looks promising:


[2.0.1-RELEASE][root@host.box]/usr/local/bin(11): ./WGXepc2
Found Firebox X-Core
WGXepc Version 0.3 17:2:2011
WGXepc 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
Not all functions are supported by all models
[2.0.1-RELEASE][root@host.box]/usr/local/bin(12): ./WGXepc2 -l green
Found Firebox X-Core
[2.0.1-RELEASE][root@host.box]]/usr/local/bin(13):

 ;D

This did work... for future reference..

Just my bubu renaming an old version, still do NOT know how that happened, but again thank U Steve for all your help..
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 12, 2012, 01:41:35 pm
I have managed to resurrect my X-Core box after bending the chassis straight(er) and sticking bits back on with tape.
Since it's now up and running I decided to further investigate the LED states since it is possible to set it to 'dark' in the bios.
So carrying on from where we left off I investigated the remaining possible GPIO states:
Code: [Select]
Experimental findings of ICH2 IO space; 

0x4080-0x4083 Set pins as gpio or native functions. 1=gpio
Default 1a003180                 0001 1010 0000 0000 0011 0001 1000 0000
Found  1a203180      0001 1010 0010 0000 0011 0001 1000 0000

0x4084-0x4087 Set gpios as input or output. 1=Input
Default 0000ffff
Found 0000ffff bit 1 is input. Possible outputs are 0000 0000 0000 0000 1111 1111 1111 1111

   1 1 1    1  (set as gpio & set as output)

0x408c-0x408f GPIO Levels
Default 1f1f0000
Found 09bf0000             0000 1001 1011 1111

Therefore we have 4 possible bits with 16 possible states LED state
   1 1 1    1
Address:    408f     408e
Value: 019f 0000 0001 1001 1111 Red fast flash *
01bf 0000 0001 1011 1111 Red fast flash *
039f 0000 0011 1001 1111 Red fast flash *
03bf 0000 0011 1011 1111 Red fast flash *
099f 0000 1001 1001 1111 Red Steady *
09bf 0000 1001 1011 1111 Red Steady *
0b9f 0000 1011 1001 1111 Red Steady *
0bbf 0000 1011 1011 1111 Red Steady *
119f 0001 0001 1001 1111 Green flash fast *
11bf 0001 0001 1011 1111 Green flash fast *
139f 0001 0011 1001 1111 Green flash fast *
13bf 0001 0011 1011 1111 Green flash fast *
199f 0001 1001 1001 1111 Green Steady *
19bf 0001 1001 1011 1111 Green Steady *
1b9f 0001 1011 1001 1111 Green Steady *
1bbf 0001 1011 1011 1111 Green Steady *

It's clear from those results that some of the GPIO bits we had previously identified as being set to both GPIO mode and to output are not doing anything useful. Also I failed to find OFF.
With nothing to loose I entered some large sweeping numbers and found a different bit that plays a part but should not!
I am at a loss to explain why this is so but can report some new results. I imagine I have suffered a logic failure some where but I cannot see it.
Anyway:
Code: [Select]
Actual observed relevant bits are in fact different. Therefore 3 bits giving 8 possible states.
                LED state
   1 1    1
Address:    408f     408e
Value: 013f 0000 0001 0011 1111 Off *
01bf 0000 0001 1011 1111 Red fast flash *
093f 0000 1001 0011 1111 Red slow flash *
09bf 0000 1001 1011 1111 Red steady *
113f 0001 0001 0011 1111 Off *
11bf 0001 0001 1011 1111 Green fast flash *
193f 0001 1001 0011 1111 Green slow flash *
19bf 0001 1001 1011 1111 Green steady *

So we have all states. It's clear that, on the X-Core at least, there is some other bit of electronics between the GPIO pins and the LED. It makes me wonder about the other boxes, perhaps I stopped testing too soon.  ::)

Whilst fmertz is working to include LED support in the LCD driver I have included this new data into the WGXepc program. Find it attached along with the source. As before remove the .png extension and set the permissions. Any feedback welcome.  :)

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: fmertz on February 13, 2012, 01:40:58 pm
Thanks for the hard work. At this point, in terms of integrating this LED code into the main LCD driver, I am facing this dilemma:


I guess I am leaning towards a basic software implementation for blinking using just the GPIO pins to turn the LEDs on or off, and give up on hardware blinking.

Thoughts welcome.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 13, 2012, 01:56:21 pm
I agree, now we have red, green and off for all the boxes it would be best to do anything else in software.
I think for most people simply having the LED go green at boot time will be sufficient. Anything else can be done with a separate lcdproc client that only controls the led.

Another completely different idea would be to follow JimP's suggestion (http://forum.pfsense.org/index.php/topic,32013.msg172982.html#msg172982) and have a separate FreeBSD led driver. This allows for all sorts of interesting possibilities, you can send data to /dev/led directly and have it flash a message in morse code for example.  :) It's how the LEDs on the ALIX box are handled.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: fmertz on February 13, 2012, 02:09:34 pm
Anything else can be done with a separate lcdproc client that only controls the led.

separate FreeBSD led driver.
Maybe we can talk mdima into adding calls to output()  in the existing php client. That client captures a range of things as it is.

Going down the driver path throws portability out the window. The code becomes FreeBSD only, and a completely separate implementation would be required for Linux. I have done neither, but, in the end, the purpose is to learn.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 14, 2012, 11:48:39 am
I hadn't considered portability.
Looking at the geode led driver they use the oem_bios function to indentify the different models. I guess this might be FreeBSD only.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on June 21, 2012, 08:17:31 pm
Just realised I posted the most recent version of this in the X700 thread and forgot to include it here.
Same as previous versions but includes an option to switch the LCD backlight if you aren't running LCDproc with the firebox driver.
Find it attached with the source.

Code: [Select]
[2.0.1-RELEASE][root@pfsense.fire.box]/conf(8): ./WGXepc
Found Firebox X-Peak
WGXepc Version 0.5 13:2:2012 stephenw10
WGXepc 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 led state to the second argument:
    red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off
 -b (backlight) will set the lcd backlight to the second argument:
    on or off. Do not use with LCD driver.
Not all functions are supported by all models

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: mike56 on June 22, 2012, 06:54:50 am
More good work.  What is anyone using for a fan speed setting?  I have upgraded to the SL7EG CPU, run powerd and still have the original fans in my X750E.

Thanks!
Mike
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on June 22, 2012, 08:04:56 am
I'm using 64. However my test box is rarely loaded at all and it's sat on my desk not in a hot rack.
I have run them at 16 with no problems and barely any detectable temperature rise.
You can test it with cpuburn and mbmon.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on May 16, 2013, 06:12:29 pm
There is a new version of WGXepc.
Find it attached to this thread along with the source code.
As before remove the .png extension and chmod it 0755 once it's on the box.

It now supports the XTM5 series boxes with LED and fan control (of sorts!).
I have tested it on all the known boxes with 2.0.x and 2.1beta but my testing is limited, let me know if it misbehaves.

Code: [Select]
[2.0.3-RELEASE][root@pfsense.fire.box]/root(7): /conf/WGXepc
Found Firebox X-Peak
WGXepc Version 0.8 14/5/2013 stephenw10
WGXepc can accept two arguments:
 -f (fan) will return the current and minimum fan speed or if followed
    by a number in hex, 00-FF, will set it.
 -l (led) will set the arm/disarm led state to the second argument:
    red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off
 -b (backlight) will set the lcd backlight to the second argument:
    on or off. Do not use with LCD driver.
Not all functions are supported by all models

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on June 28, 2013, 08:46:20 pm
I added an option to read the cpu temperature sensor on the X-e box since it was trivial to do and mbmon seemed to giving some errors.

Code: [Select]
[2.1-RC0][root@pfsense.localdomain]/conf(3): ./WGXepc
Found Firebox XTM5
WGXepc Version 0.9 28/6/2013 stephenw10
WGXepc can accept two arguments:
 -f (fan) will return the current and minimum fan speed or if followed
    by a number in hex, 00-FF, will set it.
 -l (led) will set the arm/disarm led state to the second argument:
    red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off
 -b (backlight) will set the lcd backlight to the second argument:
    on or off. Do not use with LCD driver.
 -t (temperature) shows the current CPU temperature reported by the
    SuperIO chip. X-e box only.
Not all functions are supported by all models

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: rhombus on July 05, 2013, 12:30:07 am
I added an option to read the cpu temperature sensor on the X-e box since it was trivial to do and mbmon seemed to giving some errors.

Code: [Select]
[2.1-RC0][root@pfsense.localdomain]/conf(3): ./WGXepc
Found Firebox XTM5
WGXepc Version 0.9 28/6/2013 stephenw10
WGXepc can accept two arguments:
 -f (fan) will return the current and minimum fan speed or if followed
    by a number in hex, 00-FF, will set it.
 -l (led) will set the arm/disarm led state to the second argument:
    red, green, red_flash, green_flash, red_flash_fast, green_flash_fast, off
 -b (backlight) will set the lcd backlight to the second argument:
    on or off. Do not use with LCD driver.
 -t (temperature) shows the current CPU temperature reported by the
    SuperIO chip. X-e box only.
Not all functions are supported by all models

Steve

I used your latest Ver 0.9 and edited the /usr/local/www/includes/functions.inc.php file (find and modify these entries in the file):

function has_temp() {

   /* no known temp monitors available at present */
   
   /* should only reach here if there is no hardware monitor */
   /* return false; */
        return true;
}


function get_temp() {

$temp_out = "";
   exec("/conf/WGXepc -t | /usr/bin/awk 'NR==3{print;exit}'", $dfout);
        $temp_out = trim($dfout[0]);

        return $temp_out;
}

Now the temp displays on the Dashboard pulling from WGXepc.

Tested on Firebox X550e

(http://share.rhombusllc.com/x550e-temp-mod.jpg)
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on July 05, 2013, 05:02:54 am
Nice.  :)
Let me know if it seems stable. It should be identical to mbmon but like I said another user found mbmon giving bad numbers after several days. Also mbmon has 0.5C accuracy but I didn't both reading that register so it's only 1C accurate.  ::)

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: browntown on July 05, 2013, 12:26:57 pm
Sweet, thanks for the code, it worked like a charm, appears within 2 degrees of mbmon at any one point.  Looks like I need to throw some arctic silver on the heatsink.  This is fan at 32

(https://dl.dropboxusercontent.com/s/l1esaxu3h04b8rh/temp.jpg?token_hash=AAGCwfbhMjmNbXZL4Lp_fTb_NmY1tX_7ZuvtxZTvFcZsug&dl=1)
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: rhombus on July 05, 2013, 02:37:48 pm
Sweet, thanks for the code, it worked like a charm, appears within 2 degrees of mbmon at any one point.  Looks like I need to throw some arctic silver on the heatsink.  This is fan at 32

(https://dl.dropboxusercontent.com/s/l1esaxu3h04b8rh/temp.jpg?token_hash=AAGCwfbhMjmNbXZL4Lp_fTb_NmY1tX_7ZuvtxZTvFcZsug&dl=1)


I had my fan set at 52 on a Pentium M 735 and at 37C. On high load, it will come up to 50. Im not worried about the $7 processor so much as having the system lock up when I am away. lol
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: Gabri.91 on July 06, 2013, 06:31:55 am
Very nice, many thanks!
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: browntown on July 11, 2013, 02:07:40 am
I'm building my wgxepc script for reboot.  Can I pass two parameters in one command?
/usr/local/bin/WGXepc -l green -f 30

or do I pass each argument on its own line?
#!/bin/sh
#
/usr/local/bin/WGXepc -l green
/usr/local/bin/WGXepc -f 30
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on July 11, 2013, 05:03:13 am
Only one parameter at a time. My coding skills very limited.  ;)
I use the shellcmd package instead of an RC script. It is stored in configuration file so it survives a firmware update.

Steve
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: rhombus on July 12, 2013, 11:15:14 am
Nice.  :)
Let me know if it seems stable. It should be identical to mbmon but like I said another user found mbmon giving bad numbers after several days. Also mbmon has 0.5C accuracy but I didn't both reading that register so it's only 1C accurate.  ::)

Steve

7 days of uptime and still displaying the correct temp. So far everything appears stable.
Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: pyroblast on February 16, 2014, 09:32:17 am
Hello,

just installed it and runs fine.

Does anyone need the output of
Code: [Select]
pciconf -r pci0:31:0 0:256 ?

Title: Re: [As Good As Solved!] Watchguard Firebox Arm/Disarm LED
Post by: stephenw10 on February 16, 2014, 11:49:49 am
Does anyone need the output of
Code: [Select]
pciconf -r pci0:31:0 0:256

Thanks for offering but the X1250e is identical to the other boxes we have tested already. So unless you have some odd variant we already have the info. Since the program recognises your box already it seems it's using the same board.  :)

Steve