Firebox LCD Driver for LCDProc

stephenw10

Interesting I'll have to give this a shot. I still expect the php client to be killed eventaually when it hits the time limit on php processes. That could be worked around by using the Service Watchdog package to monitor it.

Really there are many packages that have no need to be restarted due to an IP change. It seems to me there should be a configuration option to choose if your package is restarted or not. Obviously something for the devs.

Steve

phil.davis

Really there are many packages that have no need to be restarted due to an IP change. It seems to me there should be a configuration option to choose if your package is restarted or not. Obviously something for the devs.

Redmine issue raised: https://redmine.pfsense.org/issues/3623
Please read and comment there.
I have thought about this in the past also. In my first thoughts, it seems easiest to just pass an extra parameter in addition to "restart", to indicate the restart type/reason. Then each package can be modified to react differently to the parameter if it cares. All the existing packages that need to restart all the time anyway will not need any modification ("a good thing").

g.jauch

Of course it is always better if pfSense itself would inform the scripts under /usr/local/etc/rc.d for what reason they are called instead of the following "workaround".

Hi,

a simple approach to notice if a restart of packages occured could be realized like so:

1. The restart itself is initiated via a function inside /etc/inc/util.inc called send_event(). This function open a socket to a daemon and send "commands" to him.
In our case the command "service reload packages"

2. We can intercept/modify this send_event() function to see if a successfull restart of the packages has been triggered and touch an "event file" to indicate this.

3. Now we can check at the beginning of the scripts under /usr/local/etc/rc.d if the "event file" exists and act to it if needed.

4. At the end we need a "delete script" under /usr/local/etc/rc.d that runs after all other scripts and deletes our "event file" to reset our mechanism back to null

Let's start:

That is the original send_event() function of pfSense 2.1.2

function send_event($cmd) {
	global $g;

	if(!isset($g['event_address']))
		$g['event_address'] = "unix:///var/run/check_reload_status";

	$try = 0;
	while ($try < 3) {
		$fd = @fsockopen($g['event_address']);
		if ($fd) {
			fwrite($fd, $cmd);
			$resp = fread($fd, 4096);
			if ($resp != "OK\n")
				log_error("send_event: sent {$cmd} got {$resp}");
			fclose($fd);
			$try = 3;
		} else if (!is_process_running("check_reload_status"))
			mwexec_bg("/usr/bin/nice -n20 /usr/local/sbin/check_reload_status");
		$try++;
	}
}

here is the modified on:

function send_event($cmd) {
	global $g;

	if(!isset($g['event_address']))
		$g['event_address'] = "unix:///var/run/check_reload_status";

	$try = 0;
	while ($try < 3) {
		$fd = @fsockopen($g['event_address']);
		if ($fd) {
			fwrite($fd, $cmd);
			$resp = fread($fd, 4096);
			if ($resp != "OK\n")
			{
				log_error("send_event: sent {$cmd} got {$resp}");
			}
			else
			{
				if ( $cmd == "service reload packages" )
					mwexec_bg("/usr/bin/touch /tmp/service_reload_packages_running.txt");
			}
			fclose($fd);
			$try = 3;
		} else if (!is_process_running("check_reload_status"))
			mwexec_bg("/usr/bin/nice -n20 /usr/local/sbin/check_reload_status");
		$try++;
	}
}

The modification in detail:


if ($resp != "OK\n")
{
	log_error("send_event: sent {$cmd} got {$resp}");
}
else
{
	if ( $cmd == "service reload packages" )
	mwexec_bg("/usr/bin/touch /tmp/service_reload_packages_running.txt");
}

If the response from the daemon was "OK" ( that means that the transmitted command was successfully executed ) we check if that command was "service reload packages" and touch an "event file" under /tmp called service_reload_packages_running.txt

At the beginning of the scripts under /usr/local/etc/rc.d we can now simply check if this "event file" exist and exit/ignore the restart

if [ -f /tmp/service_reload_packages_running.txt ];then
    exit
fi

Our delete script simply deletes the "event file"

if [ -f /tmp/service_reload_packages_running.txt ];then
    rm /tmp/service_reload_packages_running.txt
fi

We call it zzz_delete.sh to make sure it's called at the end/lastly and put it under /usr/local/etc/rc.d

cu gunther

stephenw10

Looks rational.
It's somewhat outside the scope of this thread though. ;) I suggest you add your thoughts to Phil's feature request on Redmine. That way it will get some eyes-on from the dev team.

Steve

stephenw10

In case any of you are still looking at this. CMB recently found a bug in rc.renewwanip which seems relevant:
https://forum.pfsense.org/index.php?topic=76735.msg421118#msg421118

Steve

Cino

i will have to try this… anytime apinger kicked in that an interface was down for a second, i would have to restart LCD-Proc manually

TieT

LCDProc isn't working on pFsense 2.2

stephenw10

Yeah there's a bug in the PBI for LCDproc-dev that makes it fail to find the conf file. It works fine if you use almost anything but the default meathod to start it. ::) Altrernatively you can copy the LCDd.conf file from /usr/local/etc and put it in /usr/pbi/lcdproc-i386/local/etc and it will work. See:
https://forum.pfsense.org/index.php?topic=83747.0

Steve

unknown001

Man, this version 2.2 is giving a lot of issues for firebox. I no longer can install LCDproc-dev in system packages on webgui. Anyone have the below issue? I'm just encountering issue after issue. Something about "No digital signature!". By the way the LCDproc packages installs without any issue.

Beginning package installation for LCDproc-dev .
Downloading package configuration file... done.
Saving updated package information... done.
Downloading LCDproc-dev and its dependencies... 
Checking for package installation... 
 Downloading https://files.pfsense.org/packages/10/All/lcdproc-0.5.6-i386.pbi ...  (extracting)
 ERROR: No digital signature! If you are *SURE* you trust this PBI, re-install with --no-checksig option.
of lcdproc-0.5.6-i386 failed!

Installation aborted.Removing package...
Starting package deletion for lcdproc-0.5.6-i386...done.
Removing LCDproc-dev components...
Tabs items... done.
Menu items... done.
Services... done.
Loading package instructions...
Removing package instructions...done.
Auxiliary files... done.
Package XML... done.
Configuration... done.
done.
Failed to install package.

Installation halted.

stephenw10

Ah, is it still not signed? It should probably be merged back into lcdproc, which is now using a newer version.

There's a check box to allow installing unsigned packages in System > Advanced, Misc tab.
Note my above post though, you'll find it won't run initially.

Steve

lharris428

Thanks for this info guys. In addition to my firebox, I have an MSI MS-9211 that has an LCD on com2… I've spent the last couple of nights not understanding why I couldn't get LCDProc to start. I totally nuked the install and started over thinking my upgrade had borked.

They should fix up the package before signing it again.

stephenw10

The sdeclcd driver is now included upstream and the original package is now a more recent version than dev. The two should be merged.

Steve

wwwdrich

I also found that on 2.2 lcdproc would fail to connect to LCDd if you are using IPv6 and the dev version of the package. LCDd is binding to 127.0.0.1 and lcdproc is trying to connect to ::1. In order to get it working I had to:

smlink /usr/local/etc/LCDd.conf to /usr/pbi/lcdproc-i386/etc/
edit /usr/local/pkg/lcdproc.inc and change the define for LCDPROC_HOST to point to 127.0.0.1

I tried editing LCDd.conf to use ::1, but it doesn't bind properly.

moogoom

Hello Steve and guys !
My WG X700 has installed LCDProc-dev. :-)

But I've still problem with LCD in X700, because not work.
In Status –-> Services: lcdproc is STOPPED, and I can't running.

I read description in links, but not can't solve the problem. :(
LCD lights all the time and it annoys me, because he destroys… (I installed new LCD blue color) ;-)

lcd_proc_not_running_01.jpg_thumb

stephenw10

You should try to start it with Shellcmd entries instead of using the package as described here:
https://forum.pfsense.org/index.php/topic,7920.msg344513.html#msg344513

Steve

moogoom

Hello Steve !

Thanks to You, my LCD in X700 worked. :-)

A few more comments:

Not work navi buttons on the X700.
I can not turn the LCD backlight.

You can do something about it?

stephenw10

The buttons should work, the code for them is in the driver. Did they ever work with the Watchguard OS?

Steve

moogoom

on version 2.1 was all OK.
After completing the upgrade to version 2.2 LCD stopped working.

stephenw10

Hmm, well that's trickier then. I'll try to upgrade my X700 and see what happens when I get a chance. Hard to see what that might be though. Port permissions problem? Wrong port mode? Do you see anything parallel port related in the logs?

Steve

stephenw10

Ok, pulled out and dusted off my X700. I added the line to disable DMA in 2.2 to loader.conf.local and hit auto-upgrade. Went really without a hitch. I had to reboot to start LCDproc as the first boot it's reinstalling but then everything is up and running. The buttons work fine. I had forgotten how much better the LCD is in the X-Core box than any of the subsequent boxes. So much faster.

Steve