Seeking help with reading capture file. I have read some books and online articles about identifying problems in capture files and the supported examples make it fairly easy to understand but I find it difficult to put this into practice with my own traces. Can you walk me through this capture snippet: https://www.dropbox.com/s/n4qqvr962vwd5ao/Untitled.jpg?dl=0 It shows the start of a connection to a web app with some out of order, dup acks and retranmissions. Thanks! asked 22 Apr '15, 07:21  Brad_101 edited 22 Apr '15, 07:22 |
2 Answers:
Well, this trace certainly is not a beginner's first choice to learn reading captures. The reason is that the packets from the server towards the client are traced 3 times as they flow through the device where the trace was taken. The result is that the retransmissions are not really retransmissions but are flagged as such as wireshark is looking at the sequence numbers and gets fooled by duplicate packets. So here is the 3-way handshake of the first session: Packets 1,[3,4,7],9 and a picture of what might be happening ...
I suggest you filter on tcp.stream==0 and 'export specified packets' as a seperate trace file. Then add MAC addresses and the ip.ttl and tcp.options as columns to the packet list and provide another screenshot - if you really cannot share an "unwranglered" raw trace. Regards Matthias "what are common reasons for duplicated frames? with out of order, is it a problem if they are present on a network device and not at sender/receiver?" The out_of_order flagged packets and also the retransmissions that you see here are caused by the sub-optimal trace setup in the device and - as they do not appear at the endpoints - can just be ignored. That's why I said this trace is not really good to start for a beginner. ;-) answered 22 Apr '15, 12:26  mrEEde edited 24 Apr '15, 08:31 The duplicated frames may be not so relevant (we need the MAC Address), I think it, too. So if it so we can see in the trace the phenomen, what I call "Hunting the Ghost". Also it could be that you need to capture the icmp packets, too. (23 Apr '15, 14:36) Christian_R |
So I think the main problem what you have with the trace, is that you do not have an expectation. But in the most often times you need an expectation. To generate this expectation you should do some things:
When you want to analyze a trace which was captured by an other person. You first have to ask her a lot of questions, analyze the logfile araound the trace and so on. This all should be done by you for the generation of the expectation. When you have a very clear expectation, you will be able to analyze a big tracefile(>1 GB) in minutes. answered 23 Apr '15, 14:11  Christian_R edited 23 Apr '15, 14:27 thanks all for your comments & matthias for picture what are common reasons for duplicated frames? with out of order, is it a problem if they are present on a network device and not at sender/receiver? (24 Apr '15, 00:13) Brad_101 they can be a sign for a network problem. e.g. looping network (24 Apr '15, 02:37) Christian_R Out of Order normally is no prob. For that kind the SEQ/ACK mechanism was invented. But if you have Realtime apllications like VoIP it is a prob. (26 Apr '15, 16:29) Christian_R |
That looks exactly like the problem in your other question (duplicate frames reason unknown).
Unless you have an explanation why this is different, I'm going to close this question as DUPLICATE, because we don't want to have several questions for the same problem from the same person.
The trace was taken whilst working with the same application (as per the previous post) and the eventual goal is to understand what may be affecting performance within that app, but the purpose of this question was for me to try and understand how to interpret my own traces
You still have duplicate frames in that screenshot, so it still looks like the same problem as in the other question. Unless you are able to solve that, it's hard to do any performance troubleshooting!
BTW: Troubleshooting based on screenshots is (almost) impossible!
I wasn't expecting or hoping anyone could troubleshoot an issue in this post.
I was just hoping that within the snippet of info shown, someone could walk through packet by packet explaining what it means (& why) because I find it harder to put the troubleshooting steps explained in books to practice within real life captures.