Ask Your Question
0

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

asked 2018-07-12 02:18:27 +0000

carle gravatar image

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?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
1

answered 2018-07-12 08:17:39 +0000

NJL gravatar image

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)?

edit flag offensive delete link more

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 gravatar imagecarle ( 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 gravatar imageNJL ( 2018-07-12 08:49:30 +0000 )edit

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

NJL gravatar imageNJL ( 2018-07-12 08:57:43 +0000 )edit

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

carle gravatar imagecarle ( 2018-07-14 02:26:23 +0000 )edit
0

answered 2018-07-12 15:41:03 +0000

cmaynard gravatar image

updated 2018-07-12 17:35:18 +0000

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.

edit flag offensive delete link more

Comments

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

carle gravatar imagecarle ( 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 gravatar imagecarle ( 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 gravatar imagecmaynard ( 2018-07-13 13:29:31 +0000 )edit

I see, thanks.

carle gravatar imagecarle ( 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 gravatar imagecmaynard ( 2018-07-13 15:10:22 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-07-12 02:18:27 +0000

Seen: 1,131 times

Last updated: Jul 12 '18