Messages

This might not be your problem, but I've found that some providers, particularly wireless providers, sometimes drop the abnormally small ping packets sent by dpinger. For all of my gateways I set "Data Length" to 56 (you'll need to switch on "Advanced Mode" to see this option).

Just came in here again to say changing the data length to 56 has solved the issue for me (as far as dpinger giving false positives). I have been externally monitoring my own IP as well as the IP I am using for the monitor. The few failures I get now are due to monitor IP unreachable but my own connection was working.

I still need to think on monitoring as a whole in my situation. It is useful to me to know when my connection was disrupted, but only if actually true. If dpinger could check several IPs in series, and only if all fail assume the gateway unusable, it would mitigate the false positives from a single monitor IP being unreachable.

This one has been biting me several times over the past few weeks with my combination of ISPs and monitor addresses. I have multiple ISPs, and gateway flapping while I'm on a livestream is brutal.

Changing Data Length from the default 1 to 56 has already made a dramatic difference for me, so thanks for that. But I think the larger problem is still relying on a single monitor IP as the authority for whether a gateway is usable.

I'd really like to see multiple monitor targets per gateway, with some simple quorum/weighting logic, e.g. if one target stops answering but two others are healthy, don't declare the connection down. Those same few well-known targets could be reused across gateways while each gateway probes them through its own connection.

Recovery could use some asymmetry too: fail me off reasonably fast, bring me back more slowly. I'd rather require sustained evidence that a recovered connection is healthy before putting new states back on it than flap back and forth during an intermittent problem.

In short: one unreachable IP shouldn't be enough to declare an entire Internet connection dead, and recovery doesn't necessarily need to be as eager as failure detection.