Using SLL dissector output in own dissector?

asked 2020-06-18 07:32:36 +0000

7 ●1 ●3 ●4

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.

Comments

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?

Guy Harris ( 2020-06-18 08:12:31 +0000 )edit

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)

brett323 ( 2020-06-18 09:07:58 +0000 )edit

"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:

if sll.pkttype == 0000 (unicast to us), my dissector works as it does now starting at offset 0x32
if sll.pkttype == 0004 (sent by us), my dissector starts working at octet 0x10 instead

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).

brett323 ( 2020-06-18 09:24:27 +0000 )edit

add a comment

answered 2020-06-18 21:40:47 +0000

Jaap

13742 ●711 ●115

Look in pinfo->p2p_dir, it is set as follows in the SLL dissector before your dissector is called.

case LINUX_SLL_OUTGOING:
                pinfo->p2p_dir = P2P_DIR_SENT;

edit flag offensive delete link

Comments

Ahhh, perfect, thanks Jaap!

That works perfectly - and now I'm understanding more about how they work. Thanks to the excellent documentation and discussions, I was able to not only learn how to compile Wireshark from source but also write an almost fully working dissector in only one day.

So I've added this to my dissector to adjust the offset and it's now decoding all of our internal messages just as I need it to - will saves a lot of time troubleshooting.

#define SLL_OFFSET              14 /* due to Linux Cooked Capture capturing some of the EMB message header */

/* SLL, Linux Cooked-Capture dissector has already decoded
   the first 16 octets, but this includes part of our EMB packet ...
   We can work around by checking pinfo->p2p_dir value */
switch (pinfo->p2p_dir)
{
    case P2P_DIR_RECV: /* unicast to us (00) */
        initial_offset = 0;
        break;
    case P2P_DIR_SENT: /* sent by us (04) */
        initial_offset = SLL_OFFSET;
        break;
}

Next, to figure out ...(more)

brett323 ( 2020-06-18 23:47:43 +0000 )edit

To be pedantic you compile for Windows. Unless your dissector makes Win32 API calls that aren't supported on downlevel versions of Windows (making such calls from a dissector would be extremely unlikely) then the dissector will run fine on all supported versions of Windows.

The Windows build instructions in the dev guide are much more explicit as there are many more moving parts. Following them step by step and not deviating ensures the best chance of success. My advice would be to create your dev env. in a VM to keep it isolated from any other dev activities.

grahamb ( 2020-06-19 07:02:17 +0000 )edit

Hi there Graham! Yep, followed them exactly and I got it compiled last night. I actually run my work Win10 machine as a VM on my Mac.

Do I need to delete the Windows build directory contents after each change to my dissector I make? When I modify it on the Mac one, as long as I delete the resulting Wireshark.app, I just copy my updated code into the plugins directory and then when I recompile it will recompile just my modified dissector code.

But when I tried that on the Windows one, it didn't seem to make any difference. Well, I did the initial compile and verified it worked, then added in my dissector code like I did on the Mac source, but it didn't make any difference.

Will try again. My next challenge is to figure out how to combine multiple frames of our protocol ...(more)

brett323 ( 2020-06-20 00:21:19 +0000 )edit

To rebuild, edit source file, run the msbuild ... step and compilation of the required elements takes place. The CMake generation step is only required if you modify anything that affects the solution, e.g. touching any CMakeLists.txt.

grahamb ( 2020-06-20 11:20:55 +0000 )edit

Sorry Graham, you're going to have to explain how to "dit" my updated source file - I have searched but can't find any info how to do it. I feel silly asking - ask me to write & compile code for a Nokia MSS in PL/M, C or TNSDL and I can do that no problems on Vax or Windows - but I'm very new to compiling Windows software!

brett323 ( 2020-06-23 23:27:08 +0000 )edit

Okay, don't know if this is right but it seems to work well enough for me.

I modified this line in CMakeLists.txt by adding ALL:

add_custom_target(plugins ALL)

brett323 ( 2020-06-24 00:03:38 +0000 )edit

Sorry "dit" was a (un)typo, should have been "edit".

I think there's confusion between adding new source code and modifying existing code. If you add or remove source files then after modifying CMakeLists.txt wherever appropriate or for a plugin creating a top level CMakeListsCustom.txt from the CMakeListsCustom.txt.example file with your plugin listed, the CMake generation step will have to be run to create a new Visual Studio solution and project files. After that completes, run the build step. If you only modify an existing CMakeLists.txt file, then the CMake generation will be run automatically by the build step but I find doing it separately helps to spot errors.

If you modify an existing source file, e.g. adjust something in your dissector, then you only need to run the build step.

Your modification to CMakeLists.txt seems unnecessary.

grahamb ( 2020-06-24 08:05:05 +0000 )edit

LOL, okay, no worries! Maybe I didn't do it right the first time - for my initial implementation, I'd been testing on my Mac and I simply had to copy the updated source across and then just re-execute the "cmake ../ && make" command. I thought I'd copied the modified dissector code and re-ran the build step on Windows in a similar fashion but it didn't seem to re-compile it. Will check what I was doing again.

brett323 ( 2020-06-24 08:11:16 +0000 )edit

see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Using SLL dissector output in own dissector?

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Using SLL dissector output in own dissector? edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Using SLL dissector output in own dissector?