This is our old Q&A Site. Please post any new questions and answers at


I've captured some traffic where wireshark can't interpret packet as there are destination MAC address (capture was done on all interfaces). I know that this is SCTP packet. How can i force wireshark to interprat it?

asked 29 May '14, 03:18

BMWE's gravatar image

accept rate: 100%

Your question is not really clear - Wireshark should be able to read cooked captures. Can you post the capture at so we can take a look?

(29 May '14, 03:40) Jasper ♦♦

Hi Jasper,

File can be found here:

i refer to packets like 3,4, 7,8,9...

(01 Jun '14, 07:12) BMWE

Was that packet sent over a VLAN? Linux does things with VLAN headers that are not particularly helpful for code that's trying to capture packets, and there are some issues with libpcap in "cooked mode" and VLAN headers.

Unfortunately, the only way to get Wireshark to dissect those packets would be to undo whatever damage was done to them in the capture process, by removing the 4 bytes starting at an offset of 14 into the packet data. I don't know of any tools that would make that easy.

(01 Jun '14, 15:38) Guy Harris ♦♦

If you look at the packet bytes of those frames (3,4,7, etc.) you can see the bytes:

81 00 00 0a

That is a VLAN tag (VLAN 10). Only after that VLAN tag, the IP ethertype (0x0800) and the IP header starts (45 9f 00).

Either there is a problem with libpcap on that system (adding the VLAN tag in cooked mode in the wrong way - there has been a problem in earlier libpcap versions) or Wireshark is unable to handle VLAN tagged frames in Linux cooked mode.

So, please do the following:

In the meantime, you can simply remove the extra bytes with editcap.

First export only those frames with 0x81 at position 12 in the frame (start of VLAN tag marker):

tshark -nr sample.pcap -Y "frame[12] eq 0x81" -w export.pcap

Now remove the 4 additional bytes (VLAN tag)

editcap -C 12:4 export.pcap fixed.pcap

If you open fixed.pcap you'll see that there are UDP, TCP and ARP frames, but no SCTP frames!


permanent link

answered 01 Jun '14, 15:48

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

edited 01 Jun '14, 15:49

Yes, there are definitely problems with libpcap and VLAN, and I don't think they're fixed in the latest libpcap; the right place to file a bug on libpcap about this is the libpcap GitHub issues list.

(01 Jun '14, 21:13) Guy Harris ♦♦

I modified the original capture file with a hex editor (only frame 3).

Wireshark is now able to read frame #3 as a VLAN tagged frame in cooked mode.

So, yes it looks like a problem with libpcap and VLAN tagging in cooked mode. The byte order is somehow mixed up and thus Wireshark is unable to dissect those VLAN tagged frames in cooked mode.

(02 Jun '14, 13:18) Kurt Knochner ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 29 May '14, 03:18

question was seen: 2,718 times

last updated: 02 Jun '14, 13:20

p​o​w​e​r​e​d by O​S​Q​A