Hey guys!! Is it correct to assume that before learning Wireshark I should learn TCP/IP and other protocols so I can know what I'm looking for on a trace file? Because I see in every Wireshark video a lot of "how to do this or that inside Wireshark" but I'm kind of clueless of what I was supposed to look for in the first place.. Thanks! asked 24 Feb '14, 11:58  rafaelbn edited 24 Feb '14, 14:16  cmaynard ♦♦ |
One Answer:
Well, this is a bit difficult to answer - it sure helps to know how TCP/IP and other protocols work to be able to understand what Wireshark is showing you, but learning protocols from a book/RFC is not exactly helpful either. My advice would be to focus on simple things first, and then work your way up by running Wireshark while doing some tests to see how protocols behave. For example: run Wireshark, ping another PC or other network device, and check how Ethernet addresses change from source to destination when the answer comes back. Then take a look at ARP, which is used to resolve IP addresses to MAC adresses - because if a IP is pinged it needs to know what MAC it has. Next check out IP, then ICMP (which is used by ping), and so on. If you're curious about network functionality Wireshark is a great learning tool to watch things happen. If you can't figure something out that you've seen in Wireshark you can always come back here and ask specific questions. answered 24 Feb '14, 12:39  Jasper ♦♦ |
I think I got the basics covered. I currently hold Cisco CCNP. But every now and then I got some "network is broken" kind of problem and can't always find out what's wrong. And Wireshark shows it but I guess I can't see it because I don't understand how every protocol works... And all my peers, when we fire up Wireshark seems desperation mode kicking in because we don't know what to look for...
I guess that's me sayin I don't get networks that well BUT that's going to change!!
Any suggestions where to go next as far as protocols?
What I do when someone says "the network is broken" is pretty simple:
Problems are usually either "the communication is slow", "the communication breaks down" or "I can' get a connection". For that you should know who TCP works (Three Way Handshake, Reset, FIN, Push etc), and you need to look at timings. Things that should be fast need to be verified. Things that can take some time (like a client reading a web page and only requesting the next a minute later) can be ignored. Of course there are always exceptions, but that is something that is learned with experience.
well, I guess nobody knows how every protocol works. But if you know enough basic protocols, you can easily learn/understand pretty much every protocol, at least well enough to find 'typical' problems with the help of Mr. Google.
So, here are some questions:
From Cisco's page on CCNP I infer that you at least have to know something about IP to get it, so you've presumably learned IP, at least.
For some problems it would be useful to know something about TCP as well; if, for example, a routing/switching-layer problem manifests itself as slow or failing attempts to establish a TCP connection to a Web site, it might appear in a trace as initial SYNs with no SYN+ACK response (due to the initial SYN not making it from the client to the server, or the SYN+ACK response to that initial SYN not making it from the server to the client), so knowing about the TCP three-way handshake would help.