LCDproc and Arduino to control Watchguard FireBox leds


  • Hi guys,

    I put a Supermicro mini ITX board in a Watchguard FireBox 1000. And I would like to control the LED front panel.
    I connected the LED board to an Arduino and programmed it so it can receive serial text over USB to control the LEDs.

    Is there a way to use LCDproc to do this? I just need to gather the data and send it as text to /dev/cuau0 (I can’t see this com port in the selection list btw)
    Is there an LCDproc driver to just send plain text to the com port ?

  • Netgate Administrator

    Just the LEDs or the LCD too?

    What do you want the LEDs to indicate?

    Steve


  • It’s this one, so only the LEDs …

    So I basically want to send info about traffic, load, traffic between LAN ports and firewall events to the Arduino in plain text.
    I already programmed my Arduino to drive the LEDs and receive text 'commands' to control them. (And this works from terminal program for now)
    I can of course always adjust this code to work with what LCDproc is sending. (Why I like using a small Arduino for this, it's flexible)

  • Netgate Administrator

    Ah, OK.

    Lcdproc won't send anything useful to you I fear. It doesn't usually work like that, though there are many lcproc clients so I supporde one of them might do. It looks to me like lcdproc would just get in the way here. You would be better off writing a script that get that info directly from  pfSense and sends it in the correct text format to your arduino.

    Have you seen fmertz's work he did creating a driver for the LEDs on that box?
    https://forum.pfsense.org/index.php?topic=36546.0

    Steve


  • 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 …

  • Netgate Administrator

    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?

  • Netgate Administrator

    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
    
  • Netgate Administrator

    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 !


  • @subsense:

    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 “)”)
    
  • Netgate Administrator

    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"
    

    configure.txt


  • 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 table
    

    I’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)

  • Netgate Administrator


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

  • Netgate Administrator

    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


  • @subsense:

    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 !