ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] What is best way to use other protocol subdissectors?

From: Anders Broman <anders.broman@xxxxxxxxxxxx>
Date: Wed, 30 Jan 2019 09:42:30 +0000

 

 

From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Dmitriy Linikov
Sent: den 29 januari 2019 11:09
To: wireshark-dev@xxxxxxxxxxxxx
Subject: [Wireshark-dev] What is best way to use other protocol subdissectors?

 

>Hi, guys.

> 

>I'm adding support for CAN messages over IEEE1722 control frames. What is the best way to decode CAN message and payload?

> 

>Up to now I have found the following approaches:

>- like in packet-caneth.c, adding fake "can.flags.xxx" to the list of protocol fields and explicit using "can.subdissectors" table.

 

Why do you need to add “fake "can.flags.xxx" to the list of protocol fields”?

 

>- using the composite tvb to combine real payload with a fake socketcan header.

> 

>The first approach has failed for me because during commit i have several errors like the following: "can.flags.rtr doesn't match PROTOABBREV of ieee1722".

 

I think the reason for that is that you are adding hf variables to a protocol whose name is ieee1722 and in that case the expected format is

Ieee1722.can.flags.rtr. I guess you should register your sub protocol and name the hf’s accordingly but it’s hard to say with the information given.

Publish you code snippet?

 

 

>But the second approach seems a bit unnatural for me.

Yes

 

>What would you suggest?

> 

>Best regards,

>Dmitriy Linikov.

Attachment: smime.p7s
Description: S/MIME cryptographic signature