Hi Experts, I am hoping to get some advice on what I am seeing in the trace: http://www.cloudshark.org/captures/b519beceeb7a We have a soft phone that keeps getting disconnected and hence a wireshark capture was attempted. I am trying to understand the significance of packets 93-96 with regards to it being unseen segments/uncaptured segments. For packet 93, the sequence number is 2161 with the len as 54. I guess I would expect to see the ACK to be 2215 and not 2259 in packet 94. Packet 95 is kinda confusing me as it states the ACK is for a packet with a sequence number of 254 but it matches the sequence number stated in packet 94. However, I guess, the length of the packet in packet 94 should be 44 giving rise to 2303. I am getting confused at this stage so I apologise if I got the wrong end of the stick with that. Then in packet 96, I think that matches packet 95 but it says TCP ACKed unseen segment when I think the segment it ACKs is packet 95. I think the above is correct but would appreciate some advice if anyone has a moment. Regards, R asked 05 Jun '13, 13:19  Rhodium edited 06 Jun '13, 04:59  grahamb ♦ |
One Answer:
For packet 93, the sequence number is 2161 with the len as 54. I guess I would expect to see the ACK to be 2215 and not 2259 in packet 94. That's correct. There are 44 bytes missing from the capture file. That's why packet 94 says "TCP ACKed unseen segment" and packet 95 says "TCP Previous segment not captured." We know from the ACK in packet 94 that the missing bytes were received, but Wireshark did not capture them. Packet 95 is kinda confusing me as it states the ACK is for a packet with a sequence number of 254 but it matches the sequence number stated in packet 94. However, I guess, the length of the packet in packet 94 should be 44 giving rise to 2303. I am getting confused at this stage so I apologise if I got the wrong end of the stick with thatAn ACK does not correspond to the sequence number of the packet it's acknowledging; it corresponds to the next expected sequence number. So packet 95 is acknowledging packet 92. The sequence number of packet 92 is 212 and there are 42 bytes of data, so the next expected sequence number is 254. Then in packet 96, I think that matches packet 95 but it says TCP ACKed unseen segment when I think the segment it ACKs is packet 95.Again, an ACK matches the next expected sequence number, so packet 95 with sequence number 2303 is the one after the packet that is being acknowledged by packet 96 with an ACK number of 2303. So we already know from the ACK number of 2259 in packet 94 that there are 44 bytes missing; now the ACK number of 2303 in packet 96 tells us that there are another 44 bytes missing, for a total of 88 bytes, and again Wireshark confirms this with the "TCP ACKed unseen segment" message. answered 05 Jun '13, 14:37  Jim Aragon showing 5 of 6 show 1 more comments |
Hi Jim, thank you for taking the time to respond to my query and for clearing my confusion somewhat.
"We know from the ACK in packet 94 that the missing bytes were received, but Wireshark did not capture them."
We know that because the ACK states 2254 and if we did not receive it, we would never proceed to increase the ACK to 2254. Is that a fair deduction.
"so packet 95 with sequence number 2303 is the one after the packet that is being acknowledged by packet 96 with an ACK number of 2303"
That makes sense somewhat but then it raises a question as to the order of packets being captured and how does this happen?
Finally, it seems that there are no packets missing at all as implied by the tool, it was just as you stated, they were not captured for some reason or other?
Yes, that's a fair deduction. A device will not acknowledge data that it did not receive. An ACK of 2259 means "I've received bytes 1 through 2258, and I expect 2259 next."
I'm not sure what you're asking about the order of packets being captured. I do not see any evidence of actual packet loss between the two hosts, but there are clearly packets that weren't captured.
I don't think this is a TCP problem. That session looks ok until a FIN at packet 98 though there are no indicators that either side is missing any data.
I'm not an expert in H.323 or H.225, but looks like three seconds after the TCP warnings in question we see an H.225 message over that session on packet 97, which is ack'd in packet 98, but packet 98 also has a TCP FIN. So, at the TCP layer the data was received and was acknowledged, but something (possibly the application layer in response to packet 98) decided the TCP session should be ended. Also see that the corresponding UDP stream has an H.225 unregistration request at the same microsecond as the TCP session's FIN.
As the signaling is done using "non standard parameters" and oid:S it's impossible to understand the call flow without having the interpretation of the OID:s. Does codecs match between caller and callee for instance?
Hi all,
Thank you for the very informative and enlightening answers.
Jim, you advised that:
"so packet 95 with sequence number 2303 is the one after the packet that is being acknowledged by packet 96 with an ACK number of 2303"
So I am inferring that packet 95 should be after packet 96 and thus the order of the packets is a bit disordered or did I misunderstand?
Quadratic, it does seem to be an "application" issue as you stated because the TCP communication, seems to be fine.
Anders, this is for a soft phone and I agree that it uses proprietary information in the parameters but the client complains about loss of comms with their CM when attempting to pickup a call with the error message "network problem" which is patently untrue.
Thank you once again for your insight, it is much appreciated.
"So I am inferring that packet 95 should be after packet 96 and thus the order of the packets is a bit disordered or did I misunderstand?"
This has to do with where you captured the data and the round trip time between the two systems. The transmitting system does not stop and wait for a packet to get all the way to the receiver and for the ACK to come back, it keeps transmitting. Because of this, an ACK will not always be in the trace file immediately after the packet that it is acknowledging. The sender is often able to get several more packets on the wire before the ACK makes its way back.