21–30 of 40 posts
Earlier quoted context omitted.
There’s also WinMTR for Windows: https://github.com/White-Tiger/WinMTR
Last updated 9 years ago.
https://github.com/traviscross/mtr
> Merge pull request #412 from 23hiro/master … 327dd3f 11 days ago
Telnet to the port sometime establishes connectivity too.
In lieu of telnet, you can use curl as well: curl -v telnet://example.com:8000
Telnet to the port sometime establishes connectivity too.
nc example.com 8080 -v -w 60
Telnet to the port sometime establishes connectivity too.
In lieu of telnet, you can use curl as well: 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.
That's what made Crafting Interpreters[0] so compelling to me. Does anyone know any similar resources for networking?
Another thing that can be useful is to use tcpdump on the other side to see if the stuff sent to e.g. a TCP port is actually received: 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 5432I'm interested in the topic so skimmed the whole thing but it's all just basics. Most people won't know them all, but so FYI: skip the lengthy article if you know how traceroute and ARP and ICMP work in general, what the difference is between connection times out and connection refused, and why sometimes traceroute returns more than one host for a given hop.
I wouldn't call the details he goes into with traceroute "just basics", its common even for network engineers to come to the wrong conclusion based on traceroute output, or not realising that they need more information to truly know what is going on (traceroute from both sides).
Same 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.