[lickfrog]

I've been looking into windows based cmd line commands that i could use for troubleshooting network settings and hardware issues. I know a little about Netsh and Netstat (mostly simple commands for checking connection status) but was wanting to know from a practical standpoint what kind of information i could expect to find and whether it would be enough to determine if there are any hardware related issues.

[baph0m3t]

Netsh and netstat are not going to tell you much about your network hardware, the former is really for CLI admin of network servers, the latter more a list of what's happening on your system. For any kind of network troubleshooting, you have missed the most important one: ping. I've worked in networks for years and still, whenever a network issues is passed to me, ping is almost always the first command I fire up. Ping will tell you if your tci/ip stack is configured and working correctly (ping 127.0.0.1), whether you have DNS issues (ping by IP, but not by FQDN), whether you are on a correctly routed network, whether the target is physically up and on the network, etc, etc. Shitloads from one simple command.

OK, a quick insight. Someone comes to me and says that they cannot see google, here's how I would work it.

1. Can I see google from my machine? If so, then the issue is localised to their machine / network. If not, then the end of the world is nigh.
2. Either way, from their machine I would try to ping google - does it ping? If so, then the problem is somewhere between layers 4-7 of the OSI model and, as a network engineer, not my problem.
2.1. It doesn't pong to ping. Try pinging it by IP addy instead of domain name, if this works, then we have a DNS issue on our gateway device.
3. It doesn't respond by either IP or domain name, time to run a traceroute - how far does that get? Most importantly, does it get to my gateway? If so, then the LAN looks ok, if not, then I have to fix it because the problem exists within my network.
4. It gets to my gateway, I see it hit my ISP first hop router, then die. The issue is with the ISP and beyond my control.
5. The ping packet gets to google and gets returned, but my client still cannot see it. Time for telnet: can I telnet to the port I am trying to connect on (port 80 in this instance)? If so, then the issue is confirmed to exist at layers 4-7 of the OSI, it's most likely an application or fragmentation issue. Just to be sure, I fire up a port scanner and scan the remote host to see if the correct port is open.



Anyhow, you really don't want to be using DOS to diagnose hardware issues, what exactly are you trying to achieve?