I recently had the opportunity to attend a Wireshark class with Laura Chappell, and I must say if you ever have the chance jump at it. I haven’t been too much training but hers was by far the best I have ever been to. I am going to share a small portion of my notes and other things I took away from the class. Notably this was a weeklong class so I can’t possibly fit everything into a single blog post.
One of the most interesting things we went over was TCP. Pretty much everything I have ever seen was that TCP works by sending traffic till it drops a packet, then it slows down, then ramps back up. In actuality your main limiter is often the receive window size (the amount of buffer space on the receiver’s end of a TCP connection). Let’s take a look at a quick webpage loading graph “Time sequence (tcptrace)”
The green line is the receiver’s window size, I was aware of the window before but I didn’t understand it. The receive window is how much data can fit in the receiver’s buffer. So if the receive window is 1Mb then there can be 1Mb of data sent to that target. So if you need to send a 1500B packet but the free space in the receive window is only 400B then that packet will have to wait till receive window space is freed up. You can see in the graph that the green line starts out quite a bit above the data (Blue I-bars) but then the data quickly fills it up. Then there is a ~2 sec gap where the data basically flattens out, then it kicks off again. This capture is of a webpage my guess is that during that time the user was waiting then clicked for something more to be loaded, and it went off again. If there wasn’t a space between the data and the receive window size then that would probably be the client having a memory issue. If that was the case you would probably see some TCP zero window packets and finally a window update to clear up the issue.
If there were drops or something along those lines we would see red in along the blue line indicating Selective ACKs. So your application’s bandwidth is not only about how big your pipe is but also the receive window size and the path time (How fast you’re acks get back). You can of course see the round trip time by looking at the 3 way hand shake. On the client it’s between the syn and syn/ack, on the server it would be between the syn/ack and ack, or you can look at the iRTT in the TCP header (which measures the time from the SYN to the ACK – 1st to the 3rd packet of the TCP handshake).
So if you see a section where the window is full for a prolonged period of time it’s probably the client being slow and running out of memory space.
Comment on packets, and the capture
Use pcapng captures, among other reasons you can make comments about the capture and about each packet using this format. To comment on the packet just right click it and select Packet Comment in the Packet List pane.
This will make it SUPER easy to just pick a capture up that you haven’t touch in days/weeks/months and figure out where all the packets of note are.
Down in the bottom right of Wireshark there is an area marked “profile:”. It doesn’t look like a button, but it is. It’s a good idea to have a different profile for different tasks. Each profile can have custom columns, coloring rules, etc. This way you don’t have to make changes to your UI every time you want to look at something different.
If you hit view and go to Coloring Rules you can setup rules to match known issues. These are rules that we went over in class: Red are security issues, Purple are things you might see when you have a particular issue. So if you open a pcapng file and see a bunch of red along the right-hand scrollbar (the Intelligent Scrollbar) you know immediately there may be some security issues going on.
If you go into the Frame section of a packet, you can see which rule the packet is matching to see why the packet is colored the way it is.
Do you have filters that you are literally always putting in? You might want to look at making a button for this. This is super easy — just put in your filter, hit the + button, then apply a label to this button. You can see in the screen shot I have buttons labeled Syn, DNStime
A well-made set of buttons can cut your TSing time down VERY significantly.
Looking for missing packets? Stick in tcp.seq and tcp.nxtseq as columns and see the current TCP seq number and the next seq number that will be coming. If they don’t match up there was an issue (note each direction has its own seq number). I can’t stress enough how much getting the correct columns will help you. You can make anything a column, just open the packet and right click on a field and hit apply as column.
I would love to add more to this, but it’s already getting quite long. If you have questions please let me know.