So, I've noticed that the auto bandwidth limit is constantly set at the lowest because no matter what it never receives a ping reply with the default network mode (in my case IPV6). I think there is a bug where it is incorrectly pinging the wrong hosts based on the tracert as you can see here:
Tracing route to google.com [2607:f8b0:4007:801::200e]
over a maximum of 30 hops:
1 17 ms <1 ms 3 ms 1:1:1:2111::1
2 30 ms 9 ms 13 ms 1:1:1:4::1
3 20 ms 13 ms 12 ms 1:1:0:4::10:1
4 20 ms 31 ms 23 ms 1:1:0:4::74
5 35 ms 22 ms 30 ms 1:1:0:8::5c
6 12 ms 23 ms 31 ms 1:1:1:1::c20
7 11 ms 21 ms 16 ms 1:1:1::1
8 24 ms 32 ms 24 ms lax28s01-in-x0e.1e100.net [2607:f8b0:4007:801::200e]
However Tixati returns the following tracert
[12:10:58 PM] traceroute hop: 1:1:4::1:0 (skipped)
[12:10:58 PM] traceroute hop: 1:0:4::10:4041:0
[12:10:58 PM] traceroute hop: 1:0:4::74:0
[12:10:58 PM] traceroute hop: 1:0:8::5c:0
[12:10:58 PM] traceroute hop: 1:1:1::c20:0
[12:10:58 PM] traceroute hop: 1:1::1:0
[12:10:58 PM] traceroute hop: 1:0:1::1:0
[12:10:58 PM] starting ping: 1:0:4::10:1:0
It appears that Tixati is shifting the first hextet to the right adding a :0 and not pinging proper IP addresses.
Once Resolved, Please delete thread details containg IP addresses
This issue still exists in v2.59. For simplicity sake,
When Auto Bandwidth Limit is set to Default, it uses your system default which in many cases will be IPV6. It issues a tracert google.com which resolves the last hop to:
traceroute hop: 4860:0:1::1a9c:0
but that hop contains an invalid address, the proper address is:
8 11 ms 12 ms 11 ms 2001:4860:0:1::1a9c
Tixati is ignoring 2001: and adding the host address :0 which makes the address invalid therefore never receive a ping reply.
