[Abhik Sarkar <sarkar.abhik@xxxxxxxxx>]

Hello Manolis,

I have seen this and use the following approach:

> a. either during capture (via linux tcpdump) or

Find out which interface the traffic will use. For example, if it is a server and bound to a particular IP, then find out which interface the IP is on. Then capture only on that interface. I understand that this is not always possible or might be difficult to find out. But, it's usually not impossible. For example, if you have eth0 and eth0.vlan_id, then using "-i any" is likely to capture the same traffic on both interfaces. Instead, you might want to use only "-i eth0.vlan_id"

> b. during display (take out the duplicate frames)?

Use a display filter like !(tcp.analysis.retransmission or tcp.analysis.duplicate_ack) combined with anything else protocol specific. This gets rid of most of the unwanted stuff (though might also hide genuine retransmissions).

Of course, I am also happy to find out a better method :)

Hope this helps.

Abhik.

On 15 January 2015 at 09:00, Manolis Katsidoniotis <manoska@xxxxxxxxx> wrote:

Hello

This is a long shot my apologies if the question is not directly related to this forum.

In our lab we use (linux) tcpdump to capture frames (using interface "any" for applications that do not communicate internally) and wireshark to view and process the captured frames.

Lately after some upgrades we've been noticing the same frame is captured twice, once including the vlan tag and once with the tag stripped (actually sometimes we've noticed several repeated frames)

Does anyone happen to know how we can eliminate this
a. either during capture (via linux tcpdump) or
b. during display (take out the duplicate frames)?

thanks

Manolis

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe