Firebox LCD Driver for LCDProc
-
Hmm, this is tricky to my head around. More coffee perhaps! (more likely less :P)
It seems odd that this check is for a valid IP address in the config. If it always failed on dhcp (and presumably, pppoe or any thing other than static) why does it eventually stop renewing the interfaces?
Simply adding that line seems dangerous, though I have no actual code to point to to back that up.Steve
-
What I am doing wrong? If I remove the added lines and reboot, everything is back to normal.
Thanks!
ArkAngel
Please answer me 2 questions:
1. What is the "Alarm Pinger"… is it a addon package ?
2. What version of LCDProc-Dev & pfSense do you use ?I'll have a deeper look into it... tommorow ;)
Hmm, this is tricky to my head around. More coffee perhaps! (more likely less :P)
It seems odd that this check is for a valid IP address in the config. If it always failed on dhcp (and presumably, pppoe or any thing other than static) why does it eventually stop renewing the interfaces?
- That is indeed a good question… why is this not turning into an endless loop ?
- I'll also take a look what pfSense 2.0.3 carries in the "$config['interfaces'][$interface]['ipaddr']" Array, I'm pretty sure it's the real IP address that you receive from your DHCP server instead of the word "dhcp".
I asume that after the restart… pfSense versions > 2.0.3 return also the real IP inside that "$config array"... otherwise you would get that mentioned "endless loop" !
Simply adding that line seems dangerous, though I have no actual code to point to to back that up.
yes it is !
Another approch could be to touch a file if "pfsense" does that restart and check inside the scripts under /usr/local/etc/rc.d/ if that file is there and if so simply exit and do nothing!
cu gunther
-
Please answer me 2 questions:
1. What is the "Alarm Pinger"… is it a addon package ?
2. What version of LCDProc-Dev & pfSense do you use ?I'll have a deeper look into it... tommorow ;)
1. Sorry I didn't noticed where this apinger came from. It is described as "Gateway Monitoring Daemon". The only packages I run is LCDProc-Dev and phpSysInfo.
2. LCDProc-Dev-0.5.6 pkg v. 0.9.7 (lightly modded, as per what I've found in the forum), pfSense 2.1.2-RELEASE (i386)Fresh installation from a few days ago.
Thanks
ArkAngel -
Hi,
1.st I should not post nore asume anything on a late evening !
2.nd I should read my previous postings again !Please answer me 2 questions:
1. What is the "Alarm Pinger"… is it a addon package ?
2. What version of LCDProc-Dev & pfSense do you use ?I'll have a deeper look into it... tommorow ;)
1. Sorry I didn't noticed where this apinger came from. It is described as "Gateway Monitoring Daemon". The only packages I run is LCDProc-Dev and phpSysInfo.
2. LCDProc-Dev-0.5.6 pkg v. 0.9.7 (lightly modded, as per what I've found in the forum), pfSense 2.1.2-RELEASE (i386)Fresh installation from a few days ago.
Thanks
ArkAngel1. Ok, thanks for the info… I'm pretty new to pfSense!
2. that is the same setup I haveOK… here I go again!
Till pfSense 2.0.3 this if-condition contained the first 2 conditions only!
So finally I looked inside the /etc/inc/util.inc which contains the implementation of this is_ipaddrv4() function
and added this code inside the function:
if ( $ipaddr == "dhcp" ) return true;That was not the best idea… especially if you read the first sentence again!
stephenw10 also replied "It seems odd that this check is for a valid IP address in the config".
This check for a valid IPV4 address should be inside the function that is called after you hit the SAVE-Button inside the webconfigurator!So leaf the /etc/inc/util.inc untouched… and instead of this if-statement inside the /etc/rc.newwanip
if (!is_ipaddr($oldip) || $curwanip != $oldip || !is_ipaddrv4($config['interfaces'][$interface]['ipaddr']))get rid of the 3.rd / is_ipaddrv4 condition and try this:
if (!is_ipaddr($oldip) || $curwanip != $oldip )That should be a better/saver solution, with less side-effects !
If your Alarm Pinger still won't work with that new code… then probably there is something wrong/incompatible with your mentioned other "slightly mods".
I'll take a deeper look into the rest this afternoon:
cu gunther
-
I think the coder of this function made a mistake inside the /etc/rc.newwanip
if (!is_ipaddr($oldip) || $curwanip != $oldip || !is_ipaddrv4($config['interfaces'][$interface]['ipaddr']))Probably he wanted to check the $curwanip to be IPV4 conform ( that make more sense ).
So right now I use this code, everthing else untouched, all is fine the LCD "is working" after the startup and there shouldn't be any harmful side-effects if you use this code!if (!is_ipaddr($oldip) || $curwanip != $oldip || !is_ipaddrv4($curwanip)The script & the whole process itself is fine with the WAN settings! pfSense get all necessary informations from the DHCP and configures the WAN interface.
Apr 22 17:23:26 php: rc.newwanip: rc.newwanip: Informational is starting sk0. Apr 22 17:23:26 php: rc.newwanip: rc.newwanip: on (IP address: 192.168.178.45) (interface: wan) (real interface: sk0). Apr 22 17:23:26 php: rc.newwanip: ,,1,dhcp, // thats my debug output of the if() false, false, true ! Apr 22 17:23:27 php: rc.newwanip: ROUTING: setting default route to 192.168.178.1 Apr 22 17:23:28 php: rc.bootup: ROUTING: setting default route to 192.168.178.1 Apr 22 17:23:29 check_reload_status: Updating all dyndns Apr 22 17:23:32 php: rc.newwanip: Resyncing OpenVPN instances for interface WAN. Apr 22 17:23:32 php: rc.newwanip: Creating rrd update script Apr 22 17:23:33 php: rc.bootup: Creating rrd update script Apr 22 17:23:33 syslogd: exiting on signal 15 Apr 22 17:23:33 syslogd: kernel boot file is /boot/kernel/kernel Apr 22 17:23:34 php: rc.start_packages: Restarting/Starting all packages. Apr 22 17:23:34 php: rc.newwanip: pfSense package system has detected an ip change 192.168.178.45 -> 192.168.178.45 ... Restarting packages.Everything else inside the rc.newwanip script is fine so pfSense continues to start up… but because of the "dhcp" string the restart is triggered once! But it shouldn't do that... because everything is fine!
cu Gunther
-
I think the coder of this function made a mistake inside the rc.newwanip
if (!is_ipaddr($oldip) || $curwanip != $oldip || !is_ipaddrv4($config['interfaces'][$interface]['ipaddr']))Probably he wanted to check the $curwanip to be IPV4 conform ( that make more sense ).
So right now I use this code, everthing else untouched, all is fine and there shouldn't be any harmful side-effects!if (!is_ipaddr($oldip) || $curwanip != $oldip || !is_ipaddrv4($curwanip)The script & the whole process itself is fine with the WAN settings! pfSense get all necessary informations from the DHCP and configures the WAN interface.
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
-
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
-
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
-
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"). -
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 fiOur delete script simply deletes the "event file"
if [ -f /tmp/service_reload_packages_running.txt ];then rm /tmp/service_reload_packages_running.txt fiWe 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
-
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
-
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#msg421118Steve
-
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
-
LCDProc isn't working on pFsense 2.2
-
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.0Steve
-
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. -
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
-
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.
-
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
-
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.
-
