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

stephenw10

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

Unubtanium

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 ???

stephenw10

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:

WGXepc -l green

Try that.

Steve

Unubtanium

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..

Unubtanium

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... :)

led.jpg_thumb

stephenw10

Hmmm. Interesting.
Let me look through the code again….

fmertz

@Unubtanium:

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

Unubtanium

@fmertz:

@Unubtanium:

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

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?

stephenw10

Nope. We need the output of this command:

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

Unubtanium

@stephenw10:

Nope. We need the output of this command:
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):

stephenw10

Thanks for that! :)
Interesting looking at that and comparing it with Tix's from his X700, here.
They are almost identical but there is a difference.
Do you have any extra hardware in your box?
Hmm….

Steve

Unubtanium

@stephenw10:

Thanks for that! :)
Interesting looking at that and comparing it with Tix's from his X700, here.
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…

stephenw10

Aha!
The correct output should be:


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

Unubtanium

@stephenw10:

Aha!
The correct output should be:
[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…

stephenw10

Perhaps someone else has uploaded a renamed copy. :-\

Steve

Unubtanium

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

fmertz

@Unubtanium:

2440 8086

Normal 82801BA for X-Core, Device 2440 ICH2, Vendor 8086 Intel.

Unubtanium

@Unubtanium:

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..

stephenw10

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:


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:


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

WGXepc.c.png
WGXepc.png

fmertz

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:

For ease of use from a client perspective, the driver needs to provide a unified set of capabilities so all Fireboxes export the same capabilities.
Some boxes support just LED on or off, some do blink, some fast blink.
If we want to support blink and fast blink, we need to provide a software implementation for boxes that do not have it in hardware.
In addition, what about blinking red and green together, like R-R-G-R-R-G, etc?

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.