Wireshark and tcpdump

First off let me say I started using Wireshark having NO IDEA what the crap was going on other than I see things on the network. This made it a very non useful tool to me. I could find out things I wanted to know without so much jumble in the middle other ways. That said I never had to look at packets as I was generally trying to figure out other things.

Now I have taken the time to look at a few things with it, as I needed a way to capture the packets so the development department at work could figure out if we were truncating responses in our software or if a client was.

Some things to note:
1) Working with Wireshark is much easier once you understand it a bit. It is not something I think someone should just jump into as it gets frustrating.

2) Know what you want to do before you go to Wireshark. In this example I am looking for requests and responses to one other machine.

3) Understand filtering of what you want to do.

So I want to filter two machines (hopefully based on IP) and I want to follow their tracing.

Now I can only capture based on what is sent to one computer so I would need Wireshark on both computers (this being said I only have access to one so I was only responsible for getting results to one).

So objective: Compare two packets and see if loss occurs.

tcpdump is another tool that lets us do basically the same thing but command line only. Write it to a file and then import it to another machine and load it in Wireshark if you prefer the gui.

tcpdump -w <filename>.pcap -i eth0
tcpdump -nvX src net 192.168.0.0/16 and dst net 10.0.0.0/8 or 172.16.0.0/16

(I forgot my username at first, then I forgot to do it with sudo ^.^ sorry but at least it has the commands in there)
Ctrl+c to stop the dump. I believe you can also run it as a daemon but I don't remember.

Results:
Effectively what I ended up doing was using just what I said using tcpdump and inporting it to Wireshark. I dumped everything as I didn't have my notes with but but luckily Wireshark lets you filter very nicely which made it easy. The hard part is I don't have the .pcap file from the other people to compare with they only sent over the csv of ALL the communication between the two computers but none of the packets, which I want to compare.

I merged the two files together so it would be easier to try and use native Wireshark tools to try and analyze it. Here is what I used to filter out the two. The times are different on our end and theirs which made it hard to search through and note I am only looking for https requests hence port 443 being looked at only.

(ip.src == internal.ip.addr.server && ip.addr == external.ip.addr.client)  || (ip.src == external.ip.addr.server && ip.addr == internal.ip.addr.client) && tcp.port == 443
I don't have a server and client scan that I can use (the one I was using has sensitive data on it so I don't want to take a chance).

Here is a smaller filter of a packet capture I did that uses part of this larger filter:

The || is or so if you have both files combined it works nicely. There are lots of tips for filtering Wireshark. Just give Google a go.

Wiresharks native compare tool almost lined the times up exactly from what I could tell which made it much easier to tell where the packet loss happened as well as the fact they issued a connection reset. All in all it was most useful yet we didn't find what was causing the "bug" in our (or their) software, but now I know a lot more about packets and networking.

The compare tool told me basically the time difference and I was able to find it on both sides using that but also because I was at the location on one side and at the beginning of the trace on the other and it just happened to be at the beginning of the other trace. We calculated the difference by hand (basically found some packets that matched and subtracted the time difference) and the compare tool was right on. If you are using two different traces, you have to combine them together first then compare, otherwise it won't tell you much.

Other things to note the sending side will always have more than the receiving as parts are getting stripped in the routing.