First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

How to make tshark/wireshark to analyze tcp flow group by interface_id

Hi guys. I have a pcapng file with multiple interfaces. It seems wireshark/tshark don't consider the interface while decoding the flows, for example, there are two exactly identical packets but with different interface id, and wireshark will show the second packet as "retransmission/duplicate/out of order".

So is there any way to tell wireshark to decode different interfaces separately?

carle's avatar
1
carle
asked 2018-07-12 02:18:27 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

2 Answers

1

You should be able to use a Display Filter to select the interface you want and then you can export that data as a separate capture file. Once that is done you can open e.g. two files (one with interface-id1 and another with interface-id2) so you can compare what you're seeing. This should also be possible using tshark if you prefer commandline. The reason I write "should" is because I've never actually handled a capture file with captures from multiple interfaces. Can you share your capture (or some of it)?

NJL's avatar
120
NJL
answered 2018-07-12 08:17:39 +0000
edit flag offensive 0 remove flag delete link

Comments

thanks for your quick reply. that's workable, but I still prefer someway to show multiple channels in one page. And sorry, I don't have enough points to upload the file.

carle's avatar carle (2018-07-12 08:43:44 +0000) edit

If you can upload the file to cloudshark, google drive, dropbox etc. you can share the link

NJL's avatar NJL (2018-07-12 08:49:30 +0000) edit

Here's an excellent post covering some of the possible issues with multi-interface captures.

NJL's avatar NJL (2018-07-12 08:57:43 +0000) edit

I add a file for your reference at https://www.cloudshark.org/captures/4...

carle's avatar carle (2018-07-14 02:26:23 +0000) edit
add a comment see more comments
0

Currently, there isn't a solution for this; however, there is a mechanism in place that could handle it, but it will require changes to the Wireshark code before this is possible.

I don't know which version of Wireshark you're using, but at least with 2.6 or later you can enable the preference to enforce stricter conversation tracking heuristics.

The preference can be enabled via Edit -> Preferences -> Protocols -> Enable stricter conversation tracking heuristics.

As the tooltip states:

Protocols may use things like VLAN ID
or interface ID to narrow the potential
for duplicate conversations. Currently
only ICMP and ICMPv6 use this
preference to add VLAN ID to
conversation tracking

Anyway, if someone were to extend the strict_conversation_tracking_heuristics preference to include the interface ID in strict conversation tracking, the problem you're facing could be avoided. At the very least, I would recommend that you open a Wireshark Bug Report, asking for this to be implemented. I think this would be very useful.

cmaynard's avatar
11.1k
cmaynard
answered 2018-07-12 15:41:03 +0000, updated 2018-07-12 17:35:18 +0000
edit flag offensive 0 remove flag delete link

Comments

Anyway, very useful information and good to know that, thanks.

carle's avatar carle (2018-07-12 17:07:06 +0000) edit

I try the "Enable stricter conversation tracking heuristics" with wireshark 2.6.1, the issue is still there.

carle's avatar carle (2018-07-12 23:47:06 +0000) edit

Yes, that's to be expected, but the intent of that preference is to allow things like the interface ID to be used to better track conversations. As I suggested, a Wireshark Bug Report should be filed to enhance strict_conversation_tracking_heuristics to handle interface ID's as well, especially since that's the intent of that preference.

cmaynard's avatar cmaynard (2018-07-13 13:29:31 +0000) edit

I see, thanks.

carle's avatar carle (2018-07-13 14:58:48 +0000) edit

I do want to stress the importance of filing bugs to fix/enhance Wireshark. First, if bugs are not filed, then developers may not even be aware of problems and second, although they may be aware of limitations such as this, if nobody cares much about the limitations, then there's less motivation to fix/enhance them. All developers are volunteers with only so much time to dedicate on Wireshark development, so while "the squeaky wheel gets the grease" isn't necessarily true, the quiet wheel almost certainly won't get any grease.

cmaynard's avatar cmaynard (2018-07-13 15:10:22 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer