I am testing the Netwatch TTL / Accept ICMP Time Exceeded option and don’t quite understand why, when pinging 8.8.4.4 (as an example), a TTL of 3 passes but a TTL of 4 fails the test.
The traceroute shows 7 hops, a Netwatch TTL of 3 results in an UP state:
Why does a Netwatch TTL of 4 cause a fail?
And TTL’s of 5 and 6 pass as well. Why does a TTL of 4 fail???
Yoy are rather “near” to google 
.
Try manually with ping ttl option, i.e.:
/ping ttl=1 8.8.4.4
/ping ttl=2 8.8.4.4
/ping ttl=3 8.8.4.4
/ping ttl=4 8.8.4.4
/ping ttl=5 8.8.4.4
…
It will give you status TTL exceeded until you hit the right number.
Here (in traceroute) 8.8.4.4 is #12, and ping with up to ttl=11 returns “TTL time exceeded”.
[xxxx@RB5009] > ping 8.8.4.4 ttl=1
SEQ HOST SIZE TTL TIME STATUS
0 124.19.98.145 56 255 5ms593us TTL exceeded
1 124.19.98.145 56 255 5ms608us TTL exceeded
2 124.19.98.145 56 255 5ms614us TTL exceeded
sent=3 received=0 packet-loss=100%
[xxxx@RB5009] > ping 8.8.4.4 ttl=2
SEQ HOST SIZE TTL TIME STATUS
0 8.8.4.4 timeout
1 8.8.4.4 timeout
2 8.8.4.4 timeout
sent=3 received=0 packet-loss=100%
[xxxx@RB5009] > ping 8.8.4.4 ttl=3
SEQ HOST SIZE TTL TIME STATUS
0 124.19.61.124 96 253 6ms282us TTL exceeded
1 124.19.61.124 96 253 6ms377us TTL exceeded
2 124.19.61.124 96 253 6ms323us TTL exceeded
sent=3 received=0 packet-loss=100%
[xxxx@RB5009] > ping 8.8.4.4 ttl=4
SEQ HOST SIZE TTL TIME STATUS
0 74.125.147.174 56 252 7ms247us TTL exceeded
1 74.125.147.174 56 252 7ms410us TTL exceeded
2 74.125.147.174 56 252 7ms445us TTL exceeded
sent=3 received=0 packet-loss=100%
[xxxx@RB5009] > ping 8.8.4.4 ttl=5
SEQ HOST SIZE TTL TIME STATUS
0 192.178.97.93 96 249 8ms99us TTL exceeded
1 192.178.97.93 96 249 8ms410us TTL exceeded
2 192.178.97.93 96 249 8ms196us TTL exceeded
sent=3 received=0 packet-loss=100%
I still don’t understand why a netwatch TTL of 4 fails. Remember, “Accept ICMP Time Exceeded” is enabled in the netwatch test. TTL of 4 should pass the test.
More netwatch bugs?
Try another canary address, possibly with more hops, what you posted makes little sense:
Is the above exactly repeatable in several re-iterations?
Just a guess, but like you have timeout in #2 above, if it happens (on #2 or on #4) that timeout failure (and not the TTL exceeded) might trigger (or fail to trigger) the netwatch.
This is repeatable
Yes
You asked me to post this!
Hop #2 fails obviously because that Optus router is not accepting ICMP packets, no big deal.
A TTL of 4 works against 1.1.1.1 with the same #2 hop timeout:
Yep, what makes little sense is the results, in theory TTL=1 to the actual distance should all result in the same TTL exceeded, if this does not happen (even if justified/understandable by the Opus router) it probably affects some other parameter of the ICMP probe.
The 85% (or whatever) percentage?
Or latency?
Or whatever other among the n parameters/thresholds?
With a more distant target the failed (timeout) on hop #2 probably would have less relevance.
I bumped all the thresholds well over what would have caused any failures. There is something in that TTL hop count that is causing issues. If I choose a different endpoint, say, 8.8.8.8 or 1.1.1.1 the check fails on different TTL values. It makes no sense.
Yep, but which different ones?
There must be a pattern of some kind. 
From your device:
8.8.4.4 is hop #7 and ttl 1 to 6 work BUT NOT 4
1.1.1.1 is hop #10 and ttl 1 to ? work BUT NOT ?
8.8.8.8 is hop #? and ttl 1 to ? work BUT NOT ?
…
Maybe one could have a script to traceroute to the destination and then set the ttl to ((number of hops)-1).
But in v6 traceroute lines are prepended by an ordinal number, I see in your screenshot that this doesn’t happen in v7?