 | 1 | initial version |
The trace file shows several times "no response found" followed by "reply in xxx" and "Request in xxx"
What is wireshark trying to tell me ?
From reviewing your capture.
Apply a display filter of "icmp" and it may make it easier to see.
An IPv4 ping is implemented using ICMP echo request and ICMP echo reply packets. When Wireshark sees either one of these packets it attempts to find the the expected peer packet in the current trace file. The system sending the request includes an id and a seq field. The seq field typically increments by one with each subsequent request. The reply packet simply echos these values back to the sender of the request where they are correlated and reported to the user.
Within Wireshark the value of the seq field, by default, is displayed twice delimited by a "/" character; once as big-endian number and the other as little-endian number. The seq is displayed twice because some ping implementations (e.g. Microsoft Windows) write the seq number field into the packet in a different byte order then your typical *nix systems do.
Wireshark attempts to do request/response tracking.
In the case of "Echo (ping) request" packets, if the peer packet is found, the message "(reply in xxx)" is displayed where xxx is the packet number of peer echo reply packet. But if the reply packet is not seen then the message "(no response found)" is displayed.
In the case of the Echo (ping) reply packets, if the peer packet is found the message "(request in xxx)" is displayed where xxx is the packet number of the peer echo requests packet. There is no "(no request found)" message displayed when no corresponding request can be found for a reply.
Here is where is gets interesting.
Your trace file shows lots of ping reply packets that have no "(request in xxx)" messages in them. Unless you have something spoofing ICMP echo replies (very unlikely), this implies the packet trace was captured from a point or interface where it did not see the request that solicited the reply. This can happen when you have multiple nic interfaces on a host and the request was received on one interface but the reply exits on a different interface (the one you were capturing).
But focusing on the few packets where you did have ICMP Echo requests, you in fact have two copies of each request followed by two copies of each reply which can cause some confusion. Specifically look at frames 10, 11, 12 and 13.
Frame 11 is a duplicate of the frame 10 echo request and frame 13 is a duplicate of the frame 12 ping reply. Wireshark's request/response tracking appears to break down in this case. Wireshark associates frame 11 (duplicate) reply with the frame 12 (original) reply and declares the frame 10 (original) request as "(no response found)". And it does not pair the frame 12 (duplicate) reply with either frame 10 (original) nor 11 (duplicate) request. One could make a case (bug report) that Wireshark could better handle duplicate ICMP Echo packets.
One might ask "Why do you have duplicate ping requests and replies for this one host"?
I suspect it is again of where and how the packet capture was made. Its not all that unusual to artificially create duplicate copies of a packets especially when doing port (or vlan) mirroring on a switch and watching more than one port.
