connmon connmon - Internet connection monitoring

[Jack Yaz]

Hey. Is multi destination ping feature in the roadmap or not? The reason I'm asking is i want to have it ping two destinations. One to my local servers and one to somewhere outside my country since sometimes ISP or the link to say other countries is down and the only way to know if it's a fully down internet or just a link to other countries issue is from pinging IPs. Thanks! If it's not planned then no worries!! Was just wondering!!

it's wishlisted as it's not a simple change

 

[Stephen Harrington]

@Jack Yaz - My only comment would be that my preference would be for the new Target/Duration columns to go after the existing Ping/Jitter/Quality columns.
I think ping time is perhaps the thing I'm looking for most.
Anyone else feel the same?

Clearly not then ...

 

[maghuro]

The IP would need to be resolved at test time and stored, which is possible

Thanks in advance!

 

[Jack Yaz]

@Jack Yaz - My only comment would be that my preference would be for the new Target/Duration columns to go after the existing Ping/Jitter/Quality columns.
I think ping time is perhaps the thing I'm looking for most.
Anyone else feel the same?

Clearly not then ...

any other votes for this?

 

[Jack Yaz]

Thanks in advance!

is this what you meant?

 

[maghuro]

Oh yeah, as simple as that!

Thank you

is this what you meant?
View attachment 33422

 

[Jack Yaz]

Oh yeah, as simple as that!

Thank you

you know where to find it if you want early access!

 

[maghuro]

you know where to find it if you want early access!

Your develop branch - my daily stable driver

 

[Jack Yaz]

v2.11.2 is now available
Changelog:

• NEW: Setting to choose whether to include ping tests in QoS or not
• IMPROVED: Show IP used for test when using a domain to ping
• IMPROVED: Show placeholder text in WebUI while data is loading

 

[dave14305]

IMPROVED: Show IP used for test when using a domain to ping

A separate dig isn’t necessarily reliable for capturing the actual IP used in the ping test, as it may change. But the IP is available in the ping output.

Here’s an example of 8.66 being the dig top result, but ping using 9.66.

# dig +short +answer www.snbforums.com; ping -w 10 www.snbforums.com
104.26.8.66
104.26.9.66
172.67.69.81
PING www.snbforums.com (104.26.9.66): 56 data bytes
64 bytes from 104.26.9.66: seq=0 ttl=57 time=26.421 ms
64 bytes from 104.26.9.66: seq=1 ttl=57 time=26.177 ms
64 bytes from 104.26.9.66: seq=2 ttl=57 time=26.819 ms
64 bytes from 104.26.9.66: seq=3 ttl=57 time=27.105 ms
64 bytes from 104.26.9.66: seq=4 ttl=57 time=27.017 ms
64 bytes from 104.26.9.66: seq=5 ttl=57 time=26.483 ms
64 bytes from 104.26.9.66: seq=6 ttl=57 time=26.857 ms
64 bytes from 104.26.9.66: seq=7 ttl=57 time=26.588 ms
64 bytes from 104.26.9.66: seq=8 ttl=57 time=26.576 ms
64 bytes from 104.26.9.66: seq=9 ttl=57 time=27.124 ms

--- www.snbforums.com ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 26.177/26.716/27.124 ms

 

[Jack Yaz]

A separate dig isn’t necessarily reliable for capturing the actual IP used in the ping test, as it may change. But the IP is available in the ping output.

Here’s an example of 8.66 being the dig top result, but ping using 9.66.

# dig +short +answer www.snbforums.com; ping -w 10 www.snbforums.com
104.26.8.66
104.26.9.66
172.67.69.81
PING www.snbforums.com (104.26.9.66): 56 data bytes
64 bytes from 104.26.9.66: seq=0 ttl=57 time=26.421 ms
64 bytes from 104.26.9.66: seq=1 ttl=57 time=26.177 ms
64 bytes from 104.26.9.66: seq=2 ttl=57 time=26.819 ms
64 bytes from 104.26.9.66: seq=3 ttl=57 time=27.105 ms
64 bytes from 104.26.9.66: seq=4 ttl=57 time=27.017 ms
64 bytes from 104.26.9.66: seq=5 ttl=57 time=26.483 ms
64 bytes from 104.26.9.66: seq=6 ttl=57 time=26.857 ms
64 bytes from 104.26.9.66: seq=7 ttl=57 time=26.588 ms
64 bytes from 104.26.9.66: seq=8 ttl=57 time=26.576 ms
64 bytes from 104.26.9.66: seq=9 ttl=57 time=27.124 ms

--- www.snbforums.com ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 26.177/26.716/27.124 ms

check the code, you'll see i resolve the domain to an IP and ping the IP ;-)

 

[dave14305]

check the code, you'll see i resolve the domain to an IP and ping the IP ;-)

#respectjack

 

[Jack Yaz]

#respectjack

i spotted the flaw when testing against one.one.one.one and google.com , as well as room for the config file to change mid test and lead to the wrong thing being logged. i try to spend a bit of time thinking of obscure edges cases that you're bound to throw at me haha

 

[Stephen Harrington]

any other votes for this?

You must at least half agree with me, as that's the way the columns come out in the exported .csv file - yes, yes I know probably historical ...

But I can see it would vary depending what you are using it for.

I let it do the regular automated tests on the same IP / same duration and want to see/spot if ping times start spiking for some reason, so having the Ping column lined up next to the Time column reads easier for my use case - the Target/Duration is "unnecessary extraneous information' I've got to scan across in that instance. But if you are manually comparing different Ping targets your new layout makes more sense for sure.

How about an option to switch between the "Ping First" or "Target First" layouts?
Could be best of both worlds depending on what you are using it for at the time?

 

[Wistuplu]

My only comment would be that my preference would be for the new Target/Duration columns to go after the existing Ping/Jitter/Quality columns.
I think ping time is perhaps the thing I'm looking for most.
Anyone else feel the same?

Dear Stephen, Jack,
I'm afraid I don't support Stephen's approach. I much prefer Jack 's current approach.
At least in my environment, it is common practice that the first/left columns will describe the context/scope ; and the last/right columns will provide the actual measures/figures.
Just my 2cts...
Best regards

 

[Stephen Harrington]

Just my 2cts...

And a very welcome opinion @Wistuplu, thanks for commenting!

I guess my point here is that for my use case I ONLY use the automated tests so the context/scope is "known and constant" and so is redundantly being repeated at the risk of making the measurements/figures less easily readable. But as I said I can equally see the opposite being valid for other use cases.

Take care and stay well!

 

[Jack Yaz]

You must at least half agree with me, as that's the way the columns come out in the exported .csv file - yes, yes I know probably historical ...

that's just exported in column order from the database table

But I can see it would vary depending what you are using it for.

I let it do the regular automated tests on the same IP / same duration and want to see/spot if ping times start spiking for some reason, so having the Ping column lined up next to the Time column reads easier for my use case - the Target/Duration is "unnecessary extraneous information' I've got to scan across in that instance. But if you are manually comparing different Ping targets your new layout makes more sense for sure.

How about an option to switch between the "Ping First" or "Target First" layouts?
Could be best of both worlds depending on what you are using it for at the time?

I'll consider a setting. Either that or a WebUI only thing where you toggle the column layout and it stores a browser cookie

 

[Stephen Harrington]

I'll consider a setting. Either that or a WebUI only thing where you toggle the column layout and it stores a browser cookie

@Jack Yaz, thanks very much for tolerating my (clearly) edge case thoughts and considering … I think the browser cookie idea could work well for everyone and be more in keeping with your current design philosophy …

 

[Jack Yaz]

v2.11.3 is now available
Changelog:

• NEW: WebUI toggle (cookie) for changing column order of Last X table

 

[Stephen Harrington]

WebUI toggle (cookie) for changing column order of Last X table

Thanks @Jack Yaz - much appreciated!