[ASK] What does dpinger result trigger please ?
-
Hello,
I would like to execute a script whenever a gateway goes down or comes back.
Where do I hook my script execution to ?
I didn't find the cron task that checks dpinger results.What about/etc/rc.gateway_alarm ? Does this file get executed on gateway loss / recovery ? If yes, this file seems autogenerated, where can I find the source ?
Regards,
Ozy. -
It's not cron, when there's an alarm, dpinger runs /etc/rc.gateway_alarm. You can modify that file to do what you want. It'll be overwritten by upgrades though.
-
Thank you.
I'm working on a way to trigger enabling / disabling gateways for squid. See https://forum.pfsense.org/index.php?topic=109000.msg627041#msg627041/etc/rc.gateway.alarm is only triggered when a gateway goes down. So I have no way to enable the gateway again when it comes back.
I've checked the dpinger sockets, but without loss / latency thresholds defined in the GUI, I can't use them to determine whether pfsense has the gateway enabled or disabled.For now, I only could imagine a cron task that checks dpinger sockets and lanches my script when packet loss is 100%, then launches it again when packet loss is 0%
Any clues where I could hook my script ? Like the hook pfSense uses to add / remove a GW from a routing group.
Thanks.
-
Any ideas please ?
/etc/rc.gateway_alarm is triggered when a gateway goes down.
But what gets triggered when a gateway comes back ? I mean it's added again to a routing group.So actually, where can I hook a script that gets executed on gateway up and gateway down ?
Thanks. -
+1 , I need suggestions too for this.
I have programmed some .sh script to perform multiple pings, and added it to CRON, but maybe using the dpinger daemon would be a better method. -
well you can lookup the current status with
pfSense shell: print_r(get_dpinger_status(WAN_DHCP)); pfSense shell: exec
the 'UP' events might be handled by the 'check_reload_status' monitoring daemon & its probably using unix sockets (too stupid/don't wish to spend much time on it)
-
well you can lookup the current status with
pfSense shell: print_r(get_dpinger_status(WAN_DHCP)); pfSense shell: exec
the 'UP' events might be handled by the 'check_reload_status' monitoring daemon & its probably using unix sockets (too stupid/don't wish to spend much time on it)
Is this solution scriptable, heper?
I don't know much about pfSense, but it seems that pfSense shell works only for developer shell, and I would like to create some .sh script to obtain info from dpinger daemon. -
yea fairly easy to use.
easiest way is to 'record' a macro/script (with or without external parameters)
then playback that macro from shell# pfSsh.php playback my_macro
-
This is my test, heper:
luis@Balanceador:~/Temporal/DPinger$ cat DPinger.pfshell pfSense shell: print_r(get_dpinger_status(WAN_DHCP)); pfSense shell: exec luis@Balanceador:~/Temporal/DPinger$ pfSsh.php playback DPinger.pfshell Starting the pfSense developer shell.... Fatal error: Call to undefined function readline_completion_function() in /usr/local/sbin/pfSsh.php on line 162 PHP ERROR: Type: 1, File: /usr/local/sbin/pfSsh.php, Line: 162, Message: Call to undefined function readline_completion_function()luis@Balanceador:~/Temporal/DPinger$
Am I missing something?
My shell is Bash, I don't know if it bother. -
Hello,
@heper, thanks for the tip, but actually the pfSense shell won't give you more info than you could directly read from the dpinger socket.
In the following example I don't see if P1WAN_DHCP is part of my LB1 gateway group or not.pfSense shell: print_r(get_dpinger_status(P1WAN_DHCP)); pfSense shell: exec Array ( [loss] => 0 [latency_stddev] => 0.282 [latency_avg] => 5.918 [gwname] => P1WAN_DHCP [srcip] => XX.XX.XX.XX [targetip] => YY.YY.YY.YY [status] => none )
I still need to find the code that triggers the "add to gateway group" and "remove from gateway group" behavior.
I found the code but I'm not sure that it's the best entry point to add my code as it's a bit of a hack:
https://forum.pfsense.org/index.php?topic=109000.msg628747#msg628747I actually search for a function that's triggered where I could add my arbitrary code.
-
deajan did you find your answer yet?
I am struggling to solve the same problem as you. I understand dpinger is supposed to trigger /etc/rc.gateway_alarm on both DOWN and UP scenarios, but in my testing I am finding that it rarely (if ever) triggers during the WANUP (in which case arg $3 aka "alarm_flag" should == "0"
I added the following line to rc.gateway_alarm to add some additional logging, and then simulated a failure by yanking the Ethernet cables from my WAN1
/usr/bin/logger -t gwstate "rc.gateway_alarm event detected [$GW] mon_IP:$2 alarm_flag:$3"
I then use clog -f to track the events:
clog -f /var/log/system | grep gwstate
But while it does show alarm_flag:1 events, the corresponding alarm_flag:0 are not being triggered.
??? :o
-
I expect you will find that there is a new instance of dpinger running. A restart of dpinger is probably being triggered externally before dpinger declares an alarm state change.
-
I expect you will find that there is a new instance of dpinger running.
Thanks Denny. How would I tell that? compare PIDs before & after? So that is not how it is supposed to work, right? I mean, the dpinger processes should not be killed and respawned just due to a hotplug event, right?
-
Yes, you can check the PID to see if a new dpinger instance has been started. You will also find a startup message in the system log each time dpinger is started. Dpinger does not log on exit, so it would not be unusual to see a sequence of dpinger start, dpinger alarm on, dpinger start in the system log.
pfSense restarts interfaces and/or packages in many circumstances that at first are surprising. Most make sense after you dig into them a bit.
-
Hi guys,
Sorry bieng late for the party, went into holidays.
As for my answer, I modified /etc/inc/gwlb.inc in order to reach my goal.
I've created a PR on github, but Renalto said there should be a better way.
See the PR discussion here: https://github.com/pfsense/pfsense/pull/3093 -
I know the dpinger events are trapped by rc.gateway_alarm but what about physical link state changes (i.e. cable is plugged/unplugged)? Is there a place we can hook into to run code after a linkup event?
-
As far as my testing got, rc.gateway_alarm does only trigger when a link goes down, but not up.
Physical link state changes are indeed detected as dpinger won't be able to ping whatever you configured.My #PR solution detects link up / downs.
-
Hmm ok yes I was able to log dpinger triggering rc.gateway_alarm during WAN UP events as well but it wasn't consistent. I believe as Denny said, sometimes other processes or scripts are killing dpinger and restarting it and thus it doesn't trigger the call to rc.gateway_alarm. I haven't had a chance to review the code in your PR but I will look at it.
I know Renato wants to do things "right" - of course that is always best but sometimes when the SHTF you gotta do what you gotta do.