Re: What is best way to use other protocol subdissectors?

[Dmitriy Linikov <dmitriy.linikov () gmail com>]

> Date: Wed, 30 Jan 2019 09:42:30 +0000
> From: Anders Broman <anders.broman () ericsson com>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Subject: Re: [Wireshark-dev] What is best way to use other protocol
> subdissectors?
>
> Why do you need to add “fake "can.flags.xxx" to the list of protocol
> fields”?

I want wireshark to treat ACF-CAN submessages of IEEE1722 like any regular
can message that is handled by packet-socketcan: decode payload and use the
same filters.


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?

The example of such code can be seen in packet-caneth.c which is also a
transport protocol for CAN messages over Ethernet. It defines "can.id" and
other "can.xxx" hf in addition to its own "caneth.magic", "caneth.version",
etc.
Maksim Salau has already pointed me to the list of exceptions in "sub
is_from_other_protocol_whitelist" in tools/checkfiltername.pl, but still
I'm not sure whether it is the right way to do it.

It looks like there is a flaw in wireshark's CAN support which is at the
moment not abstract and is bound to the Linux-specific SocketCAN driver
implementation.

Best regards,
Dmitriy Linikov.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe