This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

interpret protocol=sll

1
1

Hello,

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

BMWE
467811
accept rate: 100%

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

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

Hi Jasper,

File can be found here: https://www.cloudshark.org/captures/d6cb15b41593

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 ♦♦

One Answer:

1

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!

Regards
Kurt

answered 01 Jun '14, 15:48

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
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).

https://www.cloudshark.org/captures/24b4754bb602

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 ♦