Hearthbeat Works, Speedtest Works, Hops Work, Pings doesn't works... why?

[mftitalia]

Hello,

I installed the software (extended) on a windows 10 64bit pc with admin rights, firewall disabled and result is:
Hearthbeat Works, Speedtest Works, Hops Work, Pings doesn't works

So, because this PC was behind a Sophos Firewall, i tryed uninstall it, and reinstall on other pc that is not behind any firewall and the results it's the same:
Pings doesn't works

In both case i'm able to ping your server.

The Agent ID is: 129687

Can you help me please?

[OutagesIO_Support]

@mftitalia said in Hearthbeat Works, Speedtest Works, Hops Work, Pings doesn't works... why?:

129687

Hi,

It looks like we have a bug in this new version. We've put up a banner to explain it.

The agent algorithm uses pings as one piece of information to determine if there is a possible slowdown in order to trigger a speed test if that is enabled.

However, the new version 1.75.2205 (Windows only) doesn't seem to be sending those pings to the dashboard.

Oddly, it only seems to be affecting some of the installations and not all of them. So you might not see pings while someone else does.

Since hops are coming in and I see an outage as well, it means that everything else is working as it should be but those pings aren't coming in.

We'll investigate and put out a fix once we can isolate this. It takes a while since we have to test first to make sure we don't introduce any new problem so just look for an update and when it's there, update please.

We very much appreciate when members to let us know that something is not working right.

Too many walk away or think someone else reported which means sometimes, it can take a while before we are even aware of a problem.

Thank you for taking the time to let us know.

[mftitalia]

Thanks for the feedback, I hope this fix happens soon.

Is it by chance also possible to have a packet-loss statistic?

[OutagesIO_Support]

It takes a while for updates as there is a lot of testing that has to be done before releasing otherwise members get stuck in an endless loop of updates.

The agent cannot at this time show packet loss information. You would have to pick a source and destination over the Internet and test between those.

We did have such a function some time ago but we could never one hundred percent confirm that it was accurate since Internet paths go over many networks that we/you don't control.

[mftitalia]

As an ISP I agree with what you said, but the packet-loss should be done exclusively on the gateway of the ISP, that is the fundamental packet-loss to know. You could activate it as an experimental option, where if you cannot independently determine it, ask the user to enter the IP. Do you think you could implement it?

[OutagesIO_Support]

The problem is that there is no absolute way of knowing if it's packet loss or ICMP being limited since only the ISP controls its own hardware.

When you see packet loss using MTR for example, it gives some idea of where something might be slowing down but it cannot confirm that it's packet loss.

It could be ICMP limitation, or the switch being too busy etc. The only way you can measure is to have an end to end test but even then, it's not possible to know with certainty if it's actually packet loss.

Trust me, it's something that's been on our plate for a long time and we have some interesting ideas/code/tests but it's simply never verifiable.

My question would be... when you say on the gateway of the ISP, I assume you mean on their remote hardware, not on your own local router provided by the ISP?

[mftitalia]

Yes, through a device directly connected to the router at the end customer's premises, and the router is connected directly via the ISP infrastructure (layer 3), with the gateway of the ISP itself, you could therefore have a fairly reliable feedback that " the last mile "provided by the ISP is qualitatively reliable

[OutagesIO_Support]

I'm not sure that we are in sync.

If you were the ISP and we could run something on your end, then yes, we might have something we could test/try.

If you don't own or control the ISP gateway that is beyond the location you are monitoring, then there is no true way to determine loss of packet.

You would have to own both ends or be allowed to install something on the ISP side of the network.

[OutagesIO_Support]

Maybe we were not understanding each other.
I reviewed this post and I think what you are asking for is to specify what you'd like to ping.

If so, this is something we've considered and may implement in the future but I'd like to explain why it's not that way right now.

The main goal of the service is to let you know if your ISP is having problems. That means source and destination but not specifically with the ISP, only through it. In other words, so long as the destination is outside of the ISP, you'll be able to tell when/if your ISP is having problems.

If we set the ping destination to a certain hop, then you'll only ever know if that hop becomes unavailable and since packets can take different paths, you may not know about other connections failing.

This is why we just go through the provider to our own network where we have target servers that let the agents know if they reached or didn't reach the target, logging in between when there are IP outages.

Now, if you were not even seeing hops coming in, that would mean that ICMP is being blocked somewhere and that would affect one aspect of the agent being able to determine outages. Pings aren't really that important but they play one part. There is a constant test being done for source/destination latency. If pings start showing a certain amount of latency, that will trigger an automatic speed test.

I hope this helps to explain.