dennypage / dpinger

Pinger engine for monitoring latency and loss

dpinger

dpinger is a daemon for continuous monitoring of latency and loss on a network connection. It is intended for use by firewalls to monitor link health, as well as for providing information to various monitoring systems such as Cacti, Nagios, Zabbix, etc.

The output of dpinger can either be file or socket based, and consists of three numbers:

<Average Latency in μs> <Standard Deviation in μs> <Percentage of Loss>

dpinger also provides for invocation of a command based upon threshold values for Average Latency or Percentage of Loss. Arguments to the command are:

<Target IP> <Alarm on/off> <Average Latency> <Standard Deviation> <Percentage of Loss>

In addition to command invocation, dpinger can also log alerts via syslog.

If several instances of dpinger are being used to monitor different targets, or the same target with different source addresses, etc., an Identifier can be added to the output to identify which instance of dpinger is the source. This is particularly useful with syslog.

Usage examples:

dpinger -t 300s -r 60s 192.168.0.1 >> /tmp/dpinger.out

Monitor IP address 192.168.0.1 for latency and loss. Average results over 5 minutes. Produce a report every 60 seconds and append it to /tmp/dpinger.out.

dpinger -r 0 -S -D 250m -L 20 -p /run/dpinger 192.168.0.1

Monitor IP address 192.168.0.1 for latency and loss. Log alerts via syslog if latency exceeds 250 milliseconds or loss exceeds 20 percent. Record process id in /run/dpinger.

dpinger -f -B 192.168.0.50 -r 10s 192.168.0.1

Monitor IP address 192.168.0.1 for latency and loss. Use 192.168.0.50 as the address for sending and receiving ICMP packets. Run in the foreground and report status via stdout every 10 seconds.

dpinger -R -o /tmp/gw.status fe80::1 -L 35% -C "/var/etc/alert igb1"

Monitor IP address fe80::1 for latency and loss. Maintain a status file in /tmp/gw.status with the current status. If packet loss exceeds 35% invoke the following command:

    /var/etc/alert igb1 fe80::1 <alarm> <latency> <deviation> <loss>

the command will be invoked with an alarm value of 1 when loss exceeds 35%, and again with an alarm value of 0 when loss returns to below 35%.

dpinger -r 0 -s 200m -u /tmp/igb1.status -p /run/dpinger fe80::1

Monitor IP address fe80::1 for latency and loss. Send echo requests every 200 milliseconds. Make current status available on demand via a Unix domain socket /tmp/igb1.status. Record process id in /run/dpinger.

dpinger -S -i Comcast -s 5s -t 600s -r 0 -L 10% -p /run/dpinger 8.8.8.8

Monitor IP address 8.8.8.8 for latency and loss. Send echo requests every five seconds and average results over 10 minutes. Log alerts via syslog including identifier string "Comcast" if average loss exceeds 10 percent. Record process id in /run/dpinger.

dpinger's Issues

readme file?

stumbled upon this through freebsd ports... it's kind of unclear what this does or what advantages it has over regular ping or liboping...

can this be clarified somewhat?

thanks!

Needs to support multiple targets

Hi Denny

Could you possibly review https://redmine.pfsense.org/issues/4354 and let us know your thoughts? I am more than happy to donate financially to the cause if that helps. I had a bad outage yesterday on a pfSense 2.3.2_p1 system that was due to a false positive on dpinger. This caused a gateway to get marked "down" when it wasn't really an ISP issue. We believe it was just an 8.8.8.8 problem.

It has been suggested by myself and others that allowing additional targets would really help reduce these edge cases and improve reliability.

How to use it to check if public/external IP have changed and create an alert notification?

Add control over alarm decay intervals

The current code uses a fixed number (10) of alert intervals to determine the hold time for alarms. This should be configurable, either by the number of alert intervals to be specified or by an explicit hold time specification. Suggested by rat2k4 in PR #35.

Use accept4()

From the code:

// After December 31st, 2016, review use of fcntl() for setting non blocking
// and close on exec. It would be preferable to use accept4(), SOCK_CLOEXEC
// and SOCK_NONBLOCK. These are currently avoided to allow use on older
// systems such as FreeBSD 9.3, Linux 2.6.26.

It's 2017

Does not build on FreeBSD 9

SOCK_CLOEXEC was added in FreeBSD 10.0 [1], it's better if fcntl() is used instead

[1] https://wiki.freebsd.org/AtomicCloseOnExec

Warning: Object directory not changed from original /wrkdirs/usr/ports/net/dpinger/work/dpinger-1.1
cc -O2 -pipe -fno-strict-aliasing -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c dpinger.c
dpinger.c: In function 'main':
dpinger.c:1120: error: 'SOCK_CLOEXEC' undeclared (first use in this function)
dpinger.c:1120: error: (Each undeclared identifier is reported only once
dpinger.c:1120: error: for each function it appears in.)
*** [dpinger.o] Error code 1

Stop in /wrkdirs/usr/ports/net/dpinger/work/dpinger-1.1.
*** [do-build] Error code 1

Stop in /usr/ports/net/dpinger.

Command not running on failure

Hi,

I run the following:

dpinger -r 0 -S -D 100m -L 2 -C /usr/sbin/reboot -f 192.168.1.1

On failure nothing happens. Am I misunderstanding or missing something?

dpinger fails to start on IPv6 IPs considered "tentative"

For reference: https://redmine.pfsense.org/issues/5696

Multiple targets revisited

Hi,

I have read #22 and #24, but I believe that multiple targets support (without decision making) is still makes sense.

The problem is that dpinger creates 4 threads for single host (+ main thread), and I believe that this is a waste of resources and context switches if one has to monitor (say) 100 targets, and even for 10 targets this is a little bit too much, IMHO, especially on embedded systems (async I/O based on libev, for instance, would be more appropriate, but this is another story).

The idea is just to allow multiple targets to be processed by single instance of dpinger, and every report has to be prefixed with target ip/name.

So, the question is - do you have any interest to implement this feature?

pidfile not checked

dpinger doesn't check the pidfile when it's specified. This can lead problems that you've multiple dpinger daemons running that all write the same pidfile and likely will even have problems when they all try to use the same socketfilename.

IMO: During starting dpinger should check if a pidfile already exists and check it's content (ping process to detect orphaned pidfiles.

dpinger doesn't work with source IPs specifying a scope ID

For reference: https://redmine.pfsense.org/issues/5695

Remove DISABLE_ACCEPT4

Prior accept() behavior use can be restored by defining DISABLE_ACCEPT4. If you have a platform where this is necessary, please add a comment to this issue explaining the circumstance. If no one comments, the conditional will be removed in a future release.

[FEATURE REQUEST] Multiple Targets

Background:

*https://redmine.pfsense.org/issues/4354
*https://redmine.pfsense.org/issues/1189

There is even this now: https://forum.pfsense.org/index.php?topic=123741.0

$2500 bounty.

Feature request: Multiple Targets To Ping

So the most basic feature to ask for in relation to multiple targets in dpinger I would think is: that if all ips are down then pfsense (dpinger) could mark the connection as down. I have a few devices out in the field and sometimes pings just stop to a target until they are restarted/re routed.

I think also that this should be a feature because of the way broadband ISP's seem to handle pings anymore. Even on a few 'business' connections I will see dropped pings to an ISP gateway, like they just kill the pings or routes that have to do with icmp.

I have had anycast IP's stop pinging too, when a connection is just fine. I think it stems from just crap routing and traffic management setups, where ISP's just do not care about this type of traffic anymore.

I have quite a few dedis and VPS's in the wild but I cannot guarantee 100% uptime on all at the same time, but I can guarantee that at least 8 out of 10 will be up, or 5 out of 10.

I really do think that this is a valid request for a piece of software like this anymore as it is more and more common for small business level internet to have issues with pings. I have had routers in at least 10 different locations across 10 different states, with 10 different ISP's all have issues like this. Time Warner, Spectrum, ATT, Verizon DSL, Verizon 4G, Comcast, FIOS, Brighthouse, Misc WISP, etc etc.

This issue @ pfsense has been open for 6 years now and I know it might not be as glamorous as fast kernel space packet routing but anymore this is a huge problem. I have clients dumping money into the pfsense project via hardware and support purchases only to have unreliable broadband because of this.

I am not 100% in tune to the relationship between dpinger and pfsense but it was suggested by Mr Thompson to come here and ask for something like this. Please help.

Very handy app! But missing some features!

Would be nice to also have:

• combine loss/latency so it stays on alert until both latency and loss < threshold.

• Even better, not only execute command if > threshold, but also another command (or script) if back to < threshold. Also with optional function like above.

Thanks anyway, this is great small tool for various things.

Don't wait for send interval before sending first echo request

Send the first echo request upon start up rather than waiting for a send interval. This will allow for quicker determination of status when long send intervals are in use.

Reported by @NOYB in #25

Negative numbers in parameters should be rejected

Reported by @NOYB in #26

argument to define interface instead of ip

Hello,

I would be great if we could define interface name instead of source ip address.

thanks

Collecting Stats

Good morning,

In your readme you state dpinger can provide information to "Cacti, Nagios, Zabbix, etc."

How would you go about getting the dpinger stats to a monitoring tool? I would like to run dpinger on a mips linux based router. Compiling dpinger with static binary is no problem and everything seems to work. However I am not sure what the best way to get data to one of the monitoring tools.

Thanks!
Josh