Firebox LCD Driver for LCDProc

flecom

I have worked on quite a few fireboxes (this one was my first with pfSense) and never seen one with an EL or CCFL backlight (would require an extra PCB and/or onboard inverter)… not saying they don't exist, but if they do I have never run across one...

the LED backlight on a regular text display is usually quoted as 30k-100k hours, but realistically it should last pretty much forever... if you are worried you could drop the voltage going to it by soldering a resistor across J2 to dim the display... undervolting the LEDs should extend their life

also some fireboxes like the XTM 5 series (green LED backlight) leave the backlight on 24/7

since the fireboxes have the LCD attached to the parallel port you actually could just swap the module out with a regular 2x20 HD44780 LCD, should probably fit... not sure if they are pin-compatible, would have to look at the datasheets for that...

stephenw10

Interesting about the XTM5. I have one of those running pfSense which works with the same driver as the previous boxes. I had assumed the only reason Watchguard would have specified a custom display would be to use a common driver across platforms.

IMHO there should be an option to enable the backlight permanently. Have the timer enabled by default with a warning perhaps.

However long the backlight should last there are quite a few reports of X-core boxes with dead backlights! ;)

Steve

flecom

ya like I said, it definitely could happen… I work on a lot of equipment that uses common small character displays, mostly HD44780 but some more oddball chips now and then like these fireboxes... most LED backlit (some EL and CCFL backlit, avoid EL/CCFL backlights!!) and their failure rate is nothing too bad... also if you are handy with a soldering iron you can always replace the LED (much more difficult with EL sheets/CCFL lamps)

I think the XTM is the same controller(?) but the LCD is different, its got a green backlight and is physically much smaller (smaller characters)

in a home environment I would imagine leaving the backlight on 24/7 could be more annoying than useful, but I have these things in racks with smoked plexi doors so without the backlight I cant read anything on the display :)

it would be cool if you could have a check box to leave it on all the time... would also be cool to use it as an indicator... so if there is an error condition you could "flash" the backlight... on these older fireboxes with the giant LCD displays that would definitely get your attention when you walk by it in a rack!

stephenw10

The driver is on github, feel free to start coding! ;)

You can flash the arm/disarm led as an alert though I've never actually coded that.

Steve

flecom

wouldn't even know where to start ;D

alas coding is not a skill I was blessed with… tracing out PCB's, reading schematics, designing/building/repairing hardware no problem...

but writing code... brain asplode :o ;)

going to look into that Arm/Disarm LED thing...

malvank

Will this work on a watchguard firebox 550e and onht elates pfsense build?

Kris

stephenw10

The driver works with all firebox models. However the start up script from the lcdproc-dev package has some trouble with it. You may find it doesn't start reliably at boot. You can start it manually though.

Steve

fmertz

@stephenw10:

IMHO there should be an option to enable the backlight permanently. Have the timer enabled by default with a warning perhaps.

However long the backlight should last there are quite a few reports of X-core boxes with dead backlights! ;)

FWIW, the decision not to leave the light on is based on this spec. As the code is based on said spec, I assume it applies to our boxes. Then again, things could have changed over various models and hardware revisions.

http://www.ktechs.net/pvt_filz/lcdproc/LMC-S2D20-01.pdf

Based on a half-life as low as 3,000 Hrs (depending on how you read the spec, 30,000 Hrs is also listed), the prudent thing to do is to leave the light off unless a button is pressed (a proxy for knowing when a human is around to see it). I am open to suggestions to work around this apparent limitation, but I want to keep this code as free of hacks as possible so I can keep it acceptable for inclusion in the upstream lcdproc project.

fmertz

@flecom:

going to look into that Arm/Disarm LED thing…

The code on github has the logic for LED control built-in. It is meant to support all known models, but it has not been tested adequately just yet. The idea is that the code captures the many posts revealing the technical implementation details that have been painstakingly discovered over the years. The catch is that, as of now, there is no lcdproc client that uses that functionality. The lcdproc server only offers the "output" function, with the semantics and implementation left for the driver to decide.

For testing, read this prior post:

http://forum.pfsense.org/index.php/topic,44034.msg247112.html#msg247112

Keep us posted.

ninjamick

hi all im new to linux and pfsence i got a wg x700 and im tring to install pfsence with a working display is there a version i can get that will work without adding extra scripts as im rubbish at commands so help would be greatful as there is very little on the web which works with windows please help :-[

stephenw10

You can get the LCD working entirely from the webgui using the LCDproc-dev package which can be found in the pfSense package system. However it currently fails to start correctly at boot on some models. You can manually start it from the webgui though.
Working from the command line is not that difficult. If you acces the box via SSH (using putty) you can copy and paste commands which is even easier. :)

Just a quick note; pfSense is not Linux. It's build on FreeBSD. Both are equally different to Windows though.

Steve

stephenw10

I had a few free hours to try again to get a working startup script for the lcdproc-dev package, and again failed. :(
Since it doesn't seem to be easily fixable (by me anyway) I have devised a method for running the new driver using the default lcdproc client. Because it's outside the package system it doesn't fall foul of the rapid start-stop sequence at boot. Anyway I have tested this on all the Watchguard boxes I have here, X-Core, X-Peak, X-e and XTM5 and it works fine.

It has a number or advantages over the lcdd5.tar package:
It uses fmertz's excellent rewritten driver with keyboard support for all models.
It runs on 2.1.
It survives a firmware update (I tested 2.0.2 > 2.0.3 and 2.1 snapshot update).
It integrates with the Status: Services: screen.

Unlike the lcdproc-dev package it doesn't crash every few hours but you don't get the choice of screens offered by the php client.

Anyway I'd welcome any other testers:

1. Install the lcdproc-dev package.
2. In the Services: LCDproc: Server: screen select:
'Enable LCDproc at startup' yes
Com port - Parallel Port 1
Display Size - 2x20
Driver - Watchguard Firebox with SDEC
Hit the save button at the bottom.
3. Doing the above generates the lcdd.conf file we need but it is only temporary so we need to copy it somewhere more permanent.
Go to Diagnostics: Command Prompt and run:

cp /usr/local/etc/LCDd.conf /conf

You could also run that at the CLI but via the webgui takes care of remounting the filesystem for you.
4. No go back to Services: LCDproc: Server: , uncheck 'Enable LCDproc at startup' and set Com Port to 'none'. You must set the com port as none, that's what the lcdproc-dev config script looks for before it removes the RC start-stop scripts.
5. Install the Shellcmd package if you haven't already.
6. Add the following shell commands to start the lcdproc server and client:

/usr/bin/nice -20 /usr/local/sbin/LCDd -r 0 -c /conf/LCDd.conf > /dev/null &

/usr/bin/nice -20 /usr/local/bin/lcdproc C T U &

Both are type 'shellcmd'. You can choose which screens to display, C T U works for me. See my attached screenshot from an X-e box.
7. Reboot. Or run those two commands manually.

Steve

Shellcmd2.png_thumb

Basiliss

I am a bit confused. I've installed the LCDProc package through the PFSense 2.0.3 web interface and tried to follow the above instructions, but I couldn't find the "Driver - Watchguard Firebox with SDEC" option.
Should I manually install a specific driver for Firebox, in order to appear in the driver options?

stephenw10

You need the lcdproc-dev package not the original lcdproc package. Only the dev version has the newer drivers.

Steve

Basiliss

@stephenw10:

You need the lcdproc-dev package not the original lcdproc package. Only the dev version has the newer drivers.

Steve

I see..thanks :)

browntown

@stephenw10:

1. Install the lcdproc-dev package.
2. In the Services: LCDproc: Server: screen select:
'Enable LCDproc at startup' yes
Com port - Parallel Port 1
Display Size - 2x20
Driver - Watchguard Firebox with SDEC
Hit the save button at the bottom.
3. Doing the above generates the lcdd.conf file we need but it is only temporary so we need to copy it somewhere more permanent.
Go to Diagnostics: Command Prompt and run:
cp /usr/local/etc/LCDd.conf /conf
You could also run that at the CLI but via the webgui takes care of remounting the filesystem for you.
4. No go back to Services: LCDproc: Server: , uncheck 'Enable LCDproc at startup' and set Com Port to 'none'. You must set the com port as none, that's what the lcdproc-dev config script looks for before it removes the RC start-stop scripts.
5. Install the Shellcmd package if you haven't already.
6. Add the following shell commands to start the lcdproc server and client:
/usr/bin/nice -20 /usr/local/sbin/LCDd -r 0 -c /conf/LCDd.conf > /dev/null &
/usr/bin/nice -20 /usr/local/bin/lcdproc C T U & 
Both are type 'shellcmd'. You can choose which screens to display, C T U works for me. See my attached screenshot from an X-e box.
7. Reboot. Or run those two commands manually.

Steve

Thanks for this, I've been fighting problems with lcdproc for a while. For reference for anyone that is curious as to what other screen flags you can use (from lcdproc doc)
lcdproc - LCDproc system status information viewer

Copyright 1999-2006 Selene Scriven, William Ferrell, and misc. contributors.
This program is released under the terms of the GNU General Public License.

Usage: lcdproc [<options>] [ <screens>…]
where <options>are
-s <host> connect to LCDd daemon on <host>-p <port> connect to LCDd daemon using <port>-f run in foreground
-e <delay> slow down initial announcement of screens (in 1/100s)
-c <config> use a configuration file other than /etc/lcdproc/lcdproc.conf
-h show this help screen
-v display program version
and <screens>are
C CPU detailed CPU usage
P SMP-CPU CPU usage overview (one line per CPU)
G CPUGraph CPU usage histogram
L Load load histogram
M Memory memory & swap usage
S ProcSize biggest processes size
D Disk filling level of mounted file systems
I Iface network interface usage
B Battery battery status
T TimeDate time & date information
O OldTime old time screen
U Uptime uptime screen
K BigClock big clock
N MiniClock minimal clock
A About credits page

Example:
lcdproc -s my.lcdproc.server.com -p 13666 C M X</screens></config></delay></port></port></host></host></options></screens></options>

stephenw10

Ah intersting, are you using a server on a different machine? What does X show? Is that just the example from the help file? ::)

Steve

dwfa

I installed pfSense 2.1.1 to fix other issues I was having and was following the instructions to get the LCD working and it seems to hang when installing lcdproc-0.5.6-i386.pbi. It has downloaded the filed and it just sits there extracting. I went to the command line and noticed bsdtar is in the state biowr (writing) and consumes about 1% constantly (seems odd).

I had no issues installing this package on 2.1. Not sure it is just my environment or not; thought I would put this out there.

EDIT:

I decided to let this run for some time. It took very long > 15mins (went for a bite to eat), is this normal?

stephenw10

Writing to the CF card can be exceptionally slow! I have experienced long delays re-installing packages though I'm not sure it was 15mins. Upgrading my test box from 2.1 to 2.1.1 took a while reload packages, including lcdproc-dev, but I'm unsure how long since I shot myself in the foot with a bad config.

Steve

dwfa

Thanks for the info. I know they can be slow; it was not this slow when I was using 2.1 - I will chalk it up to an outlier condition ;D.