LCDproc and Arduino to control Watchguard FireBox leds
-
Thanks Steve,
I looked at fmertz’s code, and he was very helpful in answering some questions I had.
Thing is, this code is for the original FireBox motherboard that uses a parallel port. Also I’m not really familiar with programming applications for BSD/pfSense. (working on it ;) )
Somehow the step to get the LCDproc text driver (which almost does what I need) to output to /dev/cuau0 seems simpler than trying to modify fmertz’s code. If I could just figure out how ;)
Btw, I just found I can select /dev/cua0 as the Com Port (LCDproc-dev v0.5.6), choose the text driver, but I’m receiving nothing. I works when I send text using terminal; cu -l /dev/cuaU0 …
-
What output are you hoping to see from lcdproc?
It seems to me that using lcdproc is just giving yourself more work. You don't have an LCD and the lcd proc server and client are designed to handle text. Since you've gone to the trouble of fitting an Arduino, and presumably programmed it, it seems to me it might be easier to use a custom script to sent the data. :-\Steve
-
Yeah after looking into LCDproc some more, I guess you have a point there Steve.
What’s a good place to start learning about how to interface with pfSense and how to access the data/stats I need for my LED panel script ?
I have been searching the forum but haven’t really come up with anything yet. I believe pfSense hasn’t got an API right? -
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.
