I have two wireshark captures. One showing the packets leaving one location. The other capture shows packets arriving at the destination. What is a good reference point to look at in the leaving packet so I can tell it's the packet that arrived at the destination. I thought I could do that with sequence numbers but it doesn't seem to work that way. So any unique fixed value in the packet should help. Thanks, Gary asked 15 Sep '10, 09:49  GaryC |
2 Answers:
Gerald is totally right in asking about which protocol is used to be able to answer your question. If I'm assuming that the sequence number you are referring to is the TCP sequence number and that these TCP packets are transported by IPv4, then indeed the sequence number might be changed by devices in between the client and the server (firewalls tend to do that for instance). A field this is mostly not altered is the IP identification in the IP header. This field is only changed when there is an application level proxy in between (loadbalancers often also behave as application level proxies, so they often create new IP identification values). So if you look at the ip.id of the packet at the client end, you will most likely find it also at the server end. You can copy it in the client trace (rightclick on the ip.id in the packet details and choose "Copy as filter") and then use "Edit -> Find Packet" (or <ctrl>-F) in the server trace and paste the filter in and click on "Find". Beware that IP identification fields are 16 bit, so there will be multiple instances in a tracefile with many packets... answered 15 Sep '10, 12:15  SYN-bit ♦♦ |
Thank you both for your comments. First off I'm looking now at the Identification number to see if that will work and I really appreciate the idea. It gives me something to try. Some additional details I should have included in the original question are: I'm looking at TCP and the packets I'm looking at are keeping the far end device alive. The far end device will reset periodically as in randomly once a day or every other day. The packets are all in the same subnet but are making it to the far end through a wireless bridge. It appears that they stop going through then the far end device resets and when it comes back up the packets are fine for another 24 or 48 hours (but not exactly) for example once at 4:49 am and the other capture of the failure was at 9:19 am on the following day. I believe the packets are actually stopped and lost rather than late as a result of the failure. Thanks again, Gary answered 15 Sep '10, 15:15 GaryC |
What kind of traffic? TCP? UDP? DECnet phase IV?