Using SLL dissector output in own dissector?
Hello,
I've cobbled together my very first dissector today to decode an internal company protocol, identified by EtherType = 0x88aa.
We capture traffic in a Linux-derived computer unit using tcpdump and so the Wireshark trace includes "Linux cooked capture" of the first few octets.
I've worked around this and managed to get my dissector working on the "unicast to us (0)" packets just as I need:
0000 00 00 00 01 00 06 02 00 00 80 3b 30 00 00 88 aa
0010 01 3b 00 10 09 00 00 00 00 10 09 7b 00 00 05 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 22 00 00 30 00 00 00 00 00 00 00 00 a0 90
0040 3b 00 02 00 00 01 3b 00 02 00 00 80 3b 20 02 00
0050 00 80 3b 30
Frame 9078: 84 bytes on wire (672 bits), 84 bytes captured (672 bits)
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: 02:00:00:80:3b:30 (02:00:00:80:3b:30)
Unused: 0000
Protocol: Unknown (0x88aa)
Nokia EMB Protocol
EMB header version: 0x01
DMX message length: 34
DMX computer: 0x00003000
DMX family: OMU-0 (0x00000000)
DMX message number: EPO_SYNC_MSG_S (0x000090a0)
DMX phys_computer: GISU-1 (0x0000003b)
However I'd like to also decode the "sent by us (4)" packets too:
0000 00 04 00 01 00 06 02 00 00 80 73 30 00 00 88 aa
0010 02 00 00 80 00 30 02 00 00 80 73 30 88 aa 01 73
0020 00 d2 81 80 3b 20 02 63 86 68 00 00 05 00 00 00
0030 00 30 73 30 6b 06 00 00 00 80 00 00 e8 8d 73 00
0040 22 00 00 30 00 00 00 00 00 00 00 00 a0 90 73 00
0050 02 00 00 01 73 00 02 00 00 80 73 20 02 00 00 80
0060 73 30
Frame 9081: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 1
Link-layer address length: 6
Source: 02:00:00:80:73:30 (02:00:00:80:73:30)
Unused: 0000
Protocol: Unknown (0x88aa)
Nokia EMB Protocol
EMB header version: 0x02
My dissector really needs to start at octet 2 as this is the payload I want to decode.
So is there any way, in my dissector, I can check the sll.pkttype value that the SLL dissector generates? If it's LINUX_SLL_OUTGOING (0x0004) then my dissector can handle the rest of the message, but my dissector can only see from octet 16, after the SLL dissector has had its fill.
Will continue researching.
What do you mean by "at octet 2"? Octet 2 of what - the SLL payload, i.e. the octet at an offset of 0x12 from the beginning of the frame - as opposed to dissecting incoming packets starting at octet 0 of the SLL payload, i.e. the octet at an offset of 0x10 from the beginning of the frame?
I.e., you've registered your dissector with the Ethertype 0x88aa, so the SLL dissector calls it automatically, but it needs to dissect outgoing packets differently from incoming packets?
Thanks for your reply Guy.
I'd like to decode our message from octet 2 of the hex output I included - when I view the frame in Wireshark, the SLL has handled octets 0 & 1 as "sent by us (0004)".
When I run my dissector it can only see the frame's contents from octet 16/0x10 onwards.
But in reality our payload starts at octet 2 in the examples.
I'm able to workaround the issue for the frames that SLL deems as "unicast to us" and my dissector works perfectly (first example).
But for the frames that are "sent by us", I'm stuck. In fact, it looks like there's some duplication - note the EtherType 0x88aa is duplicated at octet 0x1C. This looks ... weird ... to me.
Really, for all frames, I want to start decoding at offset 2 (as shown in the hex dumps) in every ...(more)
"I guess what I want to do, a bit of a kludge but as long as it works for solving faults, is decode from octet 2 onwards regardless. If not, then I'm happy to be able to check sll.pkttype and workaround the issue"
By this I mean:
At the moment [1] works fine but I can't do [2] because I'm not sure how to check sll.pkttype from my dissector.
Alternatively, override the SLL dissector completely and I can start decoding from octet 0x2 (if the word at offset 0xE is 0x88aa).