Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Firebox LCD Driver for LCDProc

    Scheduled Pinned Locked Moved Hardware
    398 Posts 97 Posters 447.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      g.jauch
      last edited by

      @ArkAngel:

      Works fine for me! apinger is happily working and LCDProc-Dev seems to automatically work at startup, instead of having to restart it after each reboot!

      Thanks a lot!

      ArkAngel

      No problem… it's obvious that something is wrong in the code so I'm pretty sure that this "glitch" will be fixed in future pfSense versions.

      LCDProc-Dev seems to be worst affected by the double start of all scripts under /usr/local/etc/rc.d

      cu gunther

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by

          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").

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • G
            g.jauch
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              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

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • C
                  Cino
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • T
                    TieT
                    last edited by

                    LCDProc isn't working on pFsense 2.2

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      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

                      1 Reply Last reply Reply Quote 0
                      • U
                        unknown001
                        last edited by

                        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.
                        
                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • L
                            lharris428
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              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

                              1 Reply Last reply Reply Quote 0
                              • W
                                wwwdrich
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • M
                                  moogoom
                                  last edited by

                                  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
                                  lcd_proc_not_running_01.jpg_thumb

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    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

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      moogoom
                                      last edited by

                                      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?

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

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

                                        Steve

                                        1 Reply Last reply Reply Quote 0
                                        • M
                                          moogoom
                                          last edited by

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

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            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

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.