"I duplicated this trace, and I also see a slight increase in latency at 68.1.1.167 (your hop 5). This is due to normal ICMP deprioritization. Your traceroute hits the Amazon Web Services (AWS) servers at hop 6. The timeouts once the traceroute reaches the AWS server are expected. Not all AWS servers return ping requests; they block ICMP packets for network security reasons. -Becky, Cox Support Forums Moderator"
Becky said this it means nothing to me please fix my issue or tell me what to do because you guys have been avoiding this issue for months and I'm down with this trash.
This is the same run around I've gotten on my thread. Not sure if this has been attempted, but Cox tech support loves to use the "ICMP deprioritization" excuse. Here's a way around that:
Download Ping Plotter - https://www.pingplotter.com/download - and change the packet type to either UDP or TCP. Servers will not deprioritize those packets.
Do set to UDP, in Ping Plotter go to "Edit" --> "Options" --> "Packet" - change the "Packet Type" option to "UDP Packets".
For TCP, you need an extra piece of free software that can be found here: https://nmap.org/npcap/dist/npcap-0.99-r7.exe
Server will not deprioritize UDP or TCP packets as they are used in normal internet communication as opposed to ping (ICMP) which is used primarily for diagnostics and can be dropped as low priority.
I'd use UDP as I've seen the exact same behavior with UDP or TCP packets in Ping Plotter. Funny enough, a normal trace route using ping produces the same exact levels of packet loss and latency, but because ping can be considered "low priority" by hops, it can be easily waved off as expected behavior.
same problem, PLEASE FIX THIS !!!
