LCDProc 0.5.4-dev

stephenw10

Further to my previous post.
I again found that LCDd had crashed out though this time the box was still responsive. Nothing useful in the logs as they are completely filled with the lcdproc php client error.
However I restarted the service and:


Jan 14 01:11:52 pfsense LCDd: LCDd version 0.5.5 starting
Jan 14 01:11:52 pfsense LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
Jan 14 01:11:52 pfsense LCDd: Listening for queries on 127.0.0.1:13666
Jan 14 01:11:53 pfsense LCDd: Connect from host 127.0.0.1:57448 on socket 11
Jan 14 01:11:54 pfsense LCDd: Connect from host 127.0.0.1:10311 on socket 13
Jan 14 01:11:55 pfsense LCDd: Connect from host 127.0.0.1:27771 on socket 14

There now seem to be three copies of the php client so it isn't correctly being killed by the rc file.

Steve

Cino

been running the 0.5.5 pkg for a couple of days now and no issues so far with the picolcd driver…

power_matz

@stephenw10:

The newest driver for the sdeclcd no longer gives you that option. This is because the lamp in the display has a half life of just 3000 hours! You do not want it on all the time.
However if enough people want it it could be reinstated I guess.

Steve

I was using a Firebox x700 over 1,5 years with the LCD light on. No issues.
I was using a Cobalt Raq 3i for 3 years. There the light is on by default all the time. No issues.

Where do you have this information. Is it really a LAMP? No LED?

ADD:

OK, I looked up the specs myself. There a two versions: EL and LED backlight.

If the backlight is a LED then the half life (means half the brightness as a new one) is 50.000 h. Thats over 5 years!

So, I don't see here an issue to enable the permanet backlight on, if it is made by LED.

fmertz

@power_matz:

Where do you have this information.

The code is based on this spec:

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

A re-read shows both 3,000 hrs for the "EL" part, and 30,000 hrs for the "LED" part. The block diagram seems to show a LED back light. 30,000 Hrs is less than 3.5 years. Folks like us typically get these Fireboxes used, so knowing nothing of the Watchguard software, I have to assume these lights could have been on for the better part of their life. Therefore, little time may be left. I am trying to keep it safe here, I guess. What length of time would you prefer?

fmertz

Looks like the vbars were upside down (my goof). The driver with a fix is here:

https://github.com/downloads/fmertz/sdeclcd/sdeclcd.so

Anyone can test on pfSense? Seems to work on Linux…

If this works, I'll open a ticket with pfSense on github. Thanks.

power_matz

@fmertz:

What length of time would you prefer?

What will it "cost" to let the user decide if he wants the BL on permanantly or only for 30 sec after a button was pressed?

fmertz

@mdima:

Added the "output led" support for the "CFontz633" driver.

I am getting around to coding the LED support in the SDEC driver for Fireboxes. At the moment, it runs on Linux for the X-Core-e boxes. The code can get the I/O ports for the GPIO out of the PCI configuration by reading /sys. This is not available in any of the *BSDs, so additional coding is required to make it work in pfSense. In the meantime, here is the (proposed) interface for the "output" function:


#define SDEC_OUTPUT_RED		0x0001
#define SDEC_OUTPUT_GREEN	0x0010
#define SDEC_OUTPUT_RED_BLINK	0x0100
#define SDEC_OUTPUT_GREEN_BLINK	0x1000

This means a client can issue "output 1" to turn the "Armed/Disarmed" to red, or "output 256" to make it blink red. Unused bits are masked off.

I guess at this point, feedback would be welcome regarding what we want to see driving the LEDs. mdima has already a number of things coded in the client. Maybe what was proposed for LED4 would work, but maybe with more feature as we have the blink function.

In addition, and outside of the client, do we want the driver itself to set these LEDs? What about a setting in LCDd.conf to set one of the LED at startup? Thoughts welcome.

stephenw10

Yes I like your proposal.
Have an option in LCDd.conf for an initial state on boot up. For most people this will be sufficient.

Go to (some other state) on gateway down is intersting. Another suggestion was go red when there is a warning in the GUI.

My X-Peak box LCD is still crashing in less than 24hours. It's interesting to note though that LCDd displays the "thankyou for using pfSense" message so presumably it doesn't crash out hard but rather shuts down or is killed.

I'll try the new driver.

Steve

stephenw10

This can't be right. :-\


[2.0.1-RELEASE][root@pfsense.fire.box]/root(7): ps aux | grep lcdproc
root    5983  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   22313  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   23243  0.0  3.4 47452 17184  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   25113  0.0  0.3  3656  1400  ??  IN   11:27PM   0:00.01 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
root   32258  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   59818  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php

Steve

fmertz

Brave souls:

Test SDEC driver with LED support:

Code ported from Linux, basic testing under FreeBSD, with hard coded support for X-e boxes only for now:

https://github.com/downloads/fmertz/sdeclcd/sdeclcd_led.so

Rename the file to sdeclcd.so
Restart LCDd
telnet <pfsense box="" ip="">13666
"hello"
"info"
"output 1" <– Red on
"output 16" <-- Green on
"output 256" <-- Red blinking

Again X-Core-e only for now. Feedback welcome. Thanks.</pfsense>

mdima

@stephenw10:

This can't be right. :-\


[2.0.1-RELEASE][root@pfsense.fire.box]/root(7): ps aux | grep lcdproc
root    5983  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   22313  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   23243  0.0  3.4 47452 17184  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   25113  0.0  0.3  3656  1400  ??  IN   11:27PM   0:00.01 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
root   32258  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   59818  0.0  3.4 47452 17220  ??  SN   11:27PM   0:00.36 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php

Steve

Hi Steve,
yes, this can't be right!!

What do you think if I add to the stop script something like:

ps auxw |awk '/lcdproc_client/ {print $2}'|xargs kill

Thanks,
Michele

mdima

@fmertz:

Brave souls:

Test SDEC driver with LED support:

Code ported from Linux, basic testing under FreeBSD, with hard coded support for X-e boxes only for now:

https://github.com/downloads/fmertz/sdeclcd/sdeclcd_led.so

Rename the file to sdeclcd.so
Restart LCDd
telnet <pfsense box="" ip="">13666
"hello"
"info"
"output 1" <– Red on
"output 16" <-- Green on
"output 256" <-- Red blinking

Again X-Core-e only for now. Feedback welcome. Thanks.</pfsense>

That's great! With few lines in "lcdproc_client.php" we can support the output leds for the SDEC driver!

stephenw10

@mdima:

What do you think if I add to the stop script something like:

ps auxw |awk '/lcdproc_client/ {print $2}'|xargs kill

In fact I was looking for the wrong thing. lcdproc_client.php is called from lcdproc.sh which should be killed when the stop script is run but doesn't for some reason.

The big problem, as I see it, is that the client program doesn't stop itself if the LCDd daemon is independently stopped for some reason. This leads to the possibility of starting more clients.

It all seems a little odd. I have to investigate further.

Steve

Edit: Also got to try the new driver will LED. :)

m4f1050

So let me get this straight, x-core = x500,x700,etc and x-core-e = x550e,7750e,etc (basically ones ending in "…50e" correct?

fmertz

@m4f1050:

So let me get this straight, x-core = x500,x700,etc and x-core-e = x550e,7750e,etc (basically ones ending in "…50e" correct?

Stephew10 is the expert on the various models, but reportedly all models in a product line have the same hardware, and the number indicates a (watchguard) software feature level. As of now, the test driver has support for the LEDs on all x-<whatever>-e models. I have tested it on a x750e. Basically, all models with a ICH6 Southbridge are coded in at the moment.</whatever>

stephenw10

There are three different hardware types that use the SDEC LCD.

The X-Core: X500, X700, X1000 and X2500.

The X-Peak: X5000, X6000 and X8000.

The X-Core-e: X550e: X550e, X750e and X1250e. And the X-Peak-e: X5500e, X6500e and X8500e.
The X-Core-e and X-Peak-e are effectively the same hardware.

Also there are some variants based on these such as the ssl-100 and ssl-core but these are far more rare.

Steve

stephenw10

OK some interesting things to report.
I did a clean install of v0.8 of the package on my X-Peak and less than 24Hrs later noticed the webgui became unavailable. As before it came back again but left no trace in the logs. However this evening I happened to be connected to the box via ssh when is happened so I could poke around a bit.

I think this explains why I couldn't connect to the webgui or login.


last pid: 56372;  load averages:  4.89,  3.27,  3.44           up 2+20:13:22  20:02:54
111 processes: 10 running, 84 sleeping, 1 zombie, 16 waiting
CPU: 24.0% user,  0.0% nice, 75.7% system,  0.4% interrupt,  0.0% idle
Mem: 55M Active, 16M Inact, 56M Wired, 1036K Cache, 59M Buf, 357M Free
Swap:

  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
50705 nobody    74  r30  3368K  1548K RUN     27.9H 100.00% LCDd

Yes LCDd using 100% CPU. ::)

At that point I didn't want to kill LCDd because I knew that would cause lcdproc_client.php to fill the logs with errors and I was hoping the logs might contain clues. So I thought I would kill lcdclient.sh first:


[2.0.1-RELEASE][root@pfsense.fire.box]/root(22): ps aux | grep lcd
root   51028  0.0  0.3  3656  1508  ??  R    Mon07PM   0:00.00 /bin/sh /tmp/lcdclient.sh
root   51368  0.0  3.4 47452 17472  ??  S    Mon07PM   0:14.73 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
[2.0.1-RELEASE][root@pfsense.fire.box]/root(23): kill 51028
[2.0.1-RELEASE][root@pfsense.fire.box]/root(24): ps aux | grep lcd
root   51028  0.0  0.3  3656  1508  ??  R    Mon07PM   0:00.00 /bin/sh /tmp/lcdclient.sh
root   51368  0.0  3.4 47452 17472  ??  S    Mon07PM   0:14.73 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php

It won't die!

Eventually I did kill LCDd and everything else died with it.

The system logs show nothing unusual.

For me the package is not stable on the X-Peak but I don't know if it's a driver problem or a bug in LCDd.
Hmmm… :-\

Steve

mdima

Hi Steve,
I was thinking about you and your LCDproc problem this evening (no, I don't think it's awkward)…

I am afraid it could be a problem on the driver or the combination between your panel and the driver... can you send me your lcdproc.conf file?

Thanks,
Michele

Brak

I have multiple X-Peak units (x550e, x750e) if you all have a specific tests you want me to run.

fmertz

@stephenw10:

OK some interesting things to report.

So this is on X-Peak only, Version 0.5.5 only, and with the "old" 0.5.4 driver?

Can you give it a shot with the 0.5.5 driver? https://github.com/downloads/fmertz/sdeclcd/sdeclcd.so

Was it working ok on 0.5.4?