LCDproc and Arduino to control Watchguard FireBox leds
-
Not really. :( There's talk of an API. You can query it with various tools, there's a package for Zabbix. If I was doing this I would start by looking at fmertz's code to see how he did it. Assuming you want to replicate the function of the LEDs as driven by the Watchguard OS which I believe is what fmertz was also doing.
Steve
-
On the face of it, there seem to be several ways to go:
If you are more comfortable with hardware, you might want to check the parallel port option again. I realize your mother board might not offer the DB25 port outright, but I am not sure it rules it out entirely. Steve can chime in, but the chipset probably has it (check the BIOS), and it may be a matter of giving a hard look at the motherboard. In the best case, the voltage levels will be compatible with the LED board. When you think of it, it is not like the original LED hardware plugged into a parallel port either. It was somehow interfaced at the hardware level so that it responded to parallel port software output. The plus side is that the fbled code could be used as-is and give you basic control immediately. We could then enhance it as we see fit going forward.
Another option would be to take a harder look at LCDproc. LCDproc is clearly not a perfect fit for this application, but could be useful nonetheless. As part of the LCDproc API, there is and "output" command. It is meant for LEDs, and the details are left for the driver to implement. The idea would be to come up with a driver that outputs commands over a serial interface (I believe several drivers already do this), and somehow code something in the API call for "output". A special client would have to be coded: it would gather details like CPU load and issue the proper "output" commands to the server. There are several of these clients available already, including the original lcdproc client of the LCDproc project, as well as the PHP client part of the pfSense LCDproc package.
-
Another thought:
There is an "emulator" built into fbled. It is a compile-time option that displays the equivalent of the LEDs on the screen (with * and .), and is used for development away from the hardware. It is really a software stand-in for the "out" function, so it is very low level. I guess it could be changed a bit so it sends information more suited for the Arduino.
Once those commands seem to work ok on screen, it might be as simple as doing a redirection to pipe them over to the Arduino:
fbled > /dev/cuaU0 -
Or reprogram the arduino to listen for the existing output. Either seems a lot less work than trying to involve lcdproc. :)
Steve
-
There is an "emulator" built into fbled. It is a compile-time option that displays the equivalent of the LEDs on the screen (with * and .), and is used for development away from the hardware. It is really a software stand-in for the "out" function, so it is very low level. I guess it could be changed a bit so it sends information more suited for the Arduino.
Once those commands seem to work ok on screen, it might be as simple as doing a redirection to pipe them over to the Arduino:
I was thinking the same thing, I'm trying to setup a dev environment FreeBSD on a virtual machine right now ;) Thanx !
-
I'm trying to setup a dev environment FreeBSD on a virtual machine right now ;) Thanx !
Check this for the right version:
https://doc.pfsense.org/index.php/PfSense_and_FreeBSD_Versions
-
Yeah I got it setup … after a whole lotta $#!+, but well, as long as we’re learning right ;)
Here is where I am now; got FreeBSD 8.3 installed, all the packages I need, set all the env variables …
autoconf installed, ran it on fbled, it gave me a configure file, nice.But when I run ./configure I get
./configure: 2157: Syntax error: word unexpected (expecting “)”) -
Can you attach the configure file?
Steve
-
2157 AM_INIT_AUTOMAKE(fbled, 0.1.3.2) 2158 ac_config_headers="$ac_config_headers config.h" -
Ah, apparently I had to run the autogen script. I can compile now.
-
Mm, this one I can’t seem to figure out.
I compiled the fbled code on my dev machine and copied the whole folder to my pfSense machine.
When I run ./fbled, I get this error:/libexec/ld-elf.so.1: /home/fbled/fbled: Shared object has no run-time symbol tableI’ve been searching every nook and cranny of the web, but I haven’t found a solution besides a few conflicting explanations of what could cause this error.
Ranging from “…need to recompile the application” to “… need to recompile the whole OS” or “there’s a corrupt library”.
But I tried this on different machines, with fresh installs of pfSense (and different versions; 2.1.3 - 2.1.5) and I’m getting the same error.Anyone got an idea ?
(btw, it runs on my FreeBSD 8.3 dev machine, just not on any pfSense installs)
-
Turn off debugging perhaps. :-\
https://forums.freebsd.org/threads/unable-to-build-virtualbox-ose.34939/
Steve
-
nah, doesn't work, I build while disabling debugging but I still get the same error.
(I removed [-g] parameter for CFLAGS in Makefile and for AM_CFLAGS in Makefile.am)What's strange is that my compiled file fbled (the emulator version) is 11kB and the one on fmertz"s page is 21kB (that works fine btw)
-
Not sure what could be wrong:
-
Check the 32/64 "bitness" between the dev machine and pfSense
-
Check the files are actually the same (sha1, md5) as text FTP through a Windows machine can mess things up
-
See what file has to say, i.e. "file fbled"
-
You can build with debug, and remove the symbols later with strip, i.e. "strip fbled"
-
-
I just checked as you suggested fmertz, and it works now !
I used <file>to check the difference. And the binary on the build machine was 'not-stripped' and once I transferred it to the pfSense machine it was suddenly 'stripped'.
Somehow by zipping it and uploading it thru pfSense's webconfigurator => [upload file] ( prolly a bad idea ;) ) the binary got stripped of the symbols … strange behavior.
Have to look into that, cause I’m intrigued why that would happen.Anyway I just ftp them directly from one machine to the other and no more probs, I can compile and run it !
I’m not seeing any load or traffic yet but I guess that might have something to do with the nic configuration. Next thing to look at.I just needed to change the "ETHDEV" in fbled.h from "dc" to "em" … all 'text leds' are working ! :)So thanks a lot for your time guys, really appreciate it !</file>
-
Hmm, that is weird. I've never looked into it but I think the file upload in the webgui has some filtering. It won't upload my small compiled binary at all for example.
Steve
-
I just needed to change the "ETHDEV" in fbled.h from "dc" to "em"
Yep, my virtual machine had pretend Intel Gigabit adapters (hence "em"), but the real hardware has Macronix adapters handled by the DEC Tulip driver (hence "dc"). I initially wanted to make sure I would not count packets multiple times by looking at just the hardware interfaces. Perils of coding for a particular hardware combination and all that…
Glad to hear it works in text mode. Now on to coding the Arduino client I suppose? Keep us posted.
-
Hey fmertz, I’ve got Status, Load and Traffic working with some rudimentary code. (need to do some refactoring ;) )
But I’m a bit lost in the ‘Bermuda triangle’ :)
Cause I see definitions for all the LEDs in the triangle in the header file. For the tips and the vertices, LED_T2E_1 and LED_T2E_2, etc …. And I can also see them being used in your code for the LED version.
So is the triangle fully functional yet ? Or just the tips for the moment ?And how are the LEDs mapped to the text output? I’m guessing the tips are 3[ . . . . T E O . . ] ?
What about the traffic from and to Trust, Ext and Opt, should those led vertices work yet ? I can’t see them light up.
Also how would 8 text bits represent 3 firewall block tips + 6 traffic vertices ?Can’t seem to find anything about it in the docs or on this forum.
thanks
-
The triangle is not fully coded, yet, mostly for lack of imagination.
For the tips, I tried and code something generic, without policy. Users can configure the firewall to log whatever packet they want, and fbled can capture the packet and blink the tip of the interface where the logging occurs. So, you could blink for an ssh attempts on the WAN side for example. It is really open to whatever pf lets you log.
I would like to do something similar for the triangle sides, but I have not thought through it, yet. I wanted to avoid a fixed scheme that is leading the lights to be just about always on, or off. One line of thought is connection tracking. Another is NAT/port forwarding. Many ways to go…
-
ah right ok.
connection tracking or NAT/port forwarding sounds great !
