Decode data on interface with link type LinkTypeLinuxSLL (i.e. linux cooked socket)

[GoogleCodeExporter]

I would like to decode the data from an interface that is using a cooked socket 
for encapsulation. Is there an existing way of doing this w/ gopacket? I saw 
there's a link type for it (LinkTypeLinuxSLL) but I didn't see a decoder 
associated with it and it doesn't appear to be parsing the data correctly with 
the LayerTypeEthernet (as expected). In case it matters, I'm using the 
"gopacket.NewDecodingLayerParser(layers.LayerTypeEthernet,...)" to decode the 
packets.

1. Is there an existing decoder for processing packets from a cooked socket?

2. If not, what is the right way of doing it in gopacket?

3. Sort of related (since I'm dealing w/ virtual interfaces), but passing an 
interface ala "venet0:0" isn't recognized as a proper interface by the 
OpenLive() method.

Any thoughts/ guidance on this issue would be greatly appreciated. Thank you!

Original issue reported on code.google.com by sur...@gmail.com on 15 Sep 2014 at 3:17

[GoogleCodeExporter]

Hey, sutri,

Thanks for the report!  I'm unfamiliar with LinuxSLL, so I'll have to look it 
up.  Short story is that we don't currently have a decoder for it, and we'll 
need one if we're to correctly parse packets off that type of interface.  Do 
you have any links to particularly useful docs on the format?  Otherwise, I'll 
just do a few web searches and see what I can come up with.

  --Graeme

Original comment by gconnell@google.com on 15 Sep 2014 at 3:40

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-HowTo

[GoogleCodeExporter]

Here's some documentation by Wireshark on it:

http://wiki.wireshark.org/SLL

I've dealt w/ this type of link type before when parsing packets and I just 
ended up skipping the first 16 bytes when SLL was detected (instead of 14 for 
Ethernet). So for my code it ended something like:

#define SLL_HEADER_LENGTH 16

ip = (ip_hdr *)(packet + SLL_HEADER_LENGTH)

This type of header is really common on VPS machines created with OpenVZ (ala 
venet0:0), so if you have access to a VPS then chances are you'll be seeing 
this.

Original comment by sur...@gmail.com on 15 Sep 2014 at 5:25

[GoogleCodeExporter]

I'd run into the same problem as well, when processing a packet capture taken 
on the "any" interface in Linux. I've created a patch that allows gopacket to 
interpret the SLL layer, yielding the gooey IP and TCP within.

The patch is attached.

Original comment by kan...@gmail.com on 15 Oct 2014 at 8:24

Attachments:

• linux_sll.diff

[GoogleCodeExporter]

Original comment by gconnell@google.com on 16 Oct 2014 at 4:12

• Changed state: Fixed