“ tcp.stream” filters on the stream index, which is assigned to each TCP conversation by Wireshark when loading the trace. The relative filter is “ tcp.stream” which is used whenever a user selects the “follow TCP stream” popup menu option on the packet list (which, as far as I can tell, is the one thing each and every user does first when starting to work with Wireshark 🙂 ). There are basically two filters that you can use to isolate TCP conversations in Wireshark : one of them is a relative filter, the other is absolute. Relative and absolute TCP conversation filters With TCP, you get at least a couple of packets for each conversation, and that makes it more likely to find them. So if you look for a UDP packet you’ve found at one location it may be difficult to find the same packet at the other location – because if it’s not there its often hard to say why, or if it should have been there at all. Finding and matching UDP packets is often more difficult than doing the same for TCP packets, simply because there is no “conversation” going on. It’s not possible to say which of both is easier to achieve since both can get pretty complex. Depending on the problem situation this usually means either to find matching packets and conversations at each location, or determining where the differences are. Old school ftw! 😉 Comparing capturesĪfter recording the packets the task at hand is to compare the capture files. Using SPAN is really only good for application behavior tracking, and when you really do not care about network/packet transmission characteristics. Quick reminder: situations like the three mentioned above will most likely require the use of network TAPs to exclude packet loss/timing issues caused by SPAN ports. when you capture at a client and at a server (and have enough TAPs and capture devices, of course). One of the problems is to select the correct capture locations, but let’s assume we got that covered for the sake of the length of this post. determining if all conversations look the same on both (or more) capture locations.checking if there is packet loss, checksum errors (which is basically leading to packet loss, too) or any unwanted packet modification “on the way”.having to determine if packets get delayed at some point in the network (this would be one of the few cases where “it IS the network”).Some reasons for such multi-point captures include

Every now and then most analysts run into a troubleshooting situations where they need to capture the same packets at different locations in the network.

Compare wireshark captures