brew install mtr
Try tapping 'd' twice to enable a stripchart
? for help
My traceroute [v0.95]
xxxxxxxx.local (172.16.0.2) -> news.ycombinator.com (50.1122022-07-27T23:37
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 172.16.0.1 0.0% 14 15.4 17.6 14.1 20.5 2.2
2. (waiting for reply)
3. 162.158.164.5 14.3% 14 34.4 71.1 16.5 145.4 47.3
4. 198.41.160.6 0.0% 14 32.9 36.0 30.2 43.9 3.4
5. 198.41.140.95 0.0% 14 61.9 45.0 35.3 64.7 9.8
6. 99.83.70.192 0.0% 14 40.7 36.7 33.1 49.6 4.4
7. 150.222.214.101 0.0% 14 36.6 41.3 34.7 58.1 6.2
8. 52.95.52.29 0.0% 14 41.6 40.0 35.1 51.1 4.2
9. (waiting for reply)The best alternative is a commercial product called PingPlotterPro. You can use it for free during a trial period.
Networking people generally don't use Windows much for troubleshooting. Windows networking behavior causes all kinds of problems and nobody wants to deal with that shit.
sudo apt install mtr-tiny • See the whole path fast - don't wait on one unresponsive hop to see "deeper" hosts
• Run ongoing traces to get path quality (per-hop packet drop & latency min/max/avg)
• Optional jitter statistics
• Color "strip chart" view (press 'd' twice)
• Drawback: need sudo, unlike trace routeSame with traceroute -- it's a common question in our interviews, "if you suspect a poor route in a given topology, which servers (client, server) should you run traceroute on?". The most common answer is just the client, without a lot of understanding that you have to consider the route from the server to the client and, like the article shared, that you only get the route info from the server you test.
Networking is still pretty tough I would say and a lot of support tickets raised for my company's product are 100% related to the network in the environment, but the Network Admin/Team lacks the depth to really investigate such issues, but knows enough to at least try to argue it's not network.
I love articles like this which clearly and plainly discuss the basic elements of networking because how you understand the basic elements fundamentally shapes how you understand network errors. The number of conversations I've had with clients who when faced with an error like "Host refused connection" when our product can't connect to a host ask with a straight face "so why did your application close the connection?" is far too high, and it's pretty disappointing on a personal level to have such discussions. Ignorance is not a sin. Reveling in ignorance is.
No, that's "Destination net unreachable". Destination host unreachable means it didn't get an ARP response so it doesn't know the MAC address of the system with that IP.
tcpdump -i any src port 5432 or dst port 5432
If it is now received you know you need to investigate on your receiving side, if it is not, the problem might be firewall or network. tcpdump -i any port 5432An easy trick I use a lot is host OS identification via ICMP. A TTL of around 64 is Linux, ~128 is windows.
That's what made Crafting Interpreters[0] so compelling to me. Does anyone know any similar resources for networking?
https://ma.ttias.be/silly-little-ip-tricks/
>ping 0x08080808
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=4ms TTL=58
Reply from 8.8.8.8: bytes=32 time=4ms TTL=58
Reply from 8.8.8.8: bytes=32 time=4ms TTL=58
Reply from 8.8.8.8: bytes=32 time=4ms TTL=58 ping 192.168.0.123
followed by arp -a 192.168.0.123
should tell me the MAC address of the router. But instead I get "No ARP entries found." - what's going on here?This tool has great documentation, see https://nmap.org/book/intro.html for more details
Some times you can’t make out the text in films, but that is what Enhance is for.
curl -v telnet://example.com:8000
Wonder whether ssh -verbose could work in a pinch? Haven’t tried it for non-ssh coms.
The whole point of course is not every protocol nor service provides a minimalistic/widespread way of testing for basic connectivity.
nc example.com 8080 -v -w 60