Re: [Wireshark-users] Custom CAN dissector script

[Fabian Cenedese]

At 17:46 07.06.2023, you wrote:

>I don't know why I'm not receiving all messages on this thread, but I'm unable 
>to respond to the latest one from Guy, so I'm responding to this one instead.
>
>In any case, here's a simple proof-of-concept in Lua using the "Decode As" 
>solution referenced below:

Hey, that's great! It does show the data as well as the ID bytes.
I can now adjust it to split the data into the bitfields. I already
had a solution for the data bytes but not for the ID.

Thanks again.

bye  Fabi

___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Custom CAN dissector script

[Maynard, Chris via Wireshark-users]

I don't know why I'm not receiving all messages on this thread, but I'm unable 
to respond to the latest one from Guy, so I'm responding to this one instead.

In any case, here's a simple proof-of-concept in Lua using the "Decode As" 
solution referenced below:

local can_id = Field.new("can.id")
local p_cansub = Proto.new("cansub", "CANSUB Protocol")
local pf = {
id0 = ProtoField.uint8("cansub.id0", "ID0", base.DEC),
id1 = ProtoField.uint8("cansub.id1", "ID1", base.DEC),
id2 = ProtoField.uint8("cansub.id2", "ID2", base.DEC),
id3 = ProtoField.uint8("cansub.id3", "ID3", base.DEC),
data = ProtoField.bytes("cansub.data", "Data", base.NONE, "The 
CANSub Data")
}
p_cansub.fields = pf

function p_cansub.dissector(tvbuf, pinfo, tree)
local cansub_tree
local can_id_tvbr = can_id().range

pinfo.cols.protocol:set("CANSUB")

cansub_tree = tree:add(p_cansub, tvbuf(0, -1))
cansub_tree:add(pf.id0, can_id_tvbr(0, 1))
cansub_tree:add(pf.id1, can_id_tvbr(1, 1))
cansub_tree:add(pf.id2, can_id_tvbr(2, 1))
cansub_tree:add(pf.id3, can_id_tvbr(3, 1))
cansub_tree:add(pf.data, tvbuf())

end -- p_cansub.dissector()

-- Registration
DissectorTable.get("can.subdissector"):add_for_decode_as(p_cansub)

Hope it helps,
Chris

> -----Original Message-
> From: Wireshark-users  On
> Behalf Of Fabian Cenedese
> Sent: Monday, June 5, 2023 4:58 PM
> To: Community support list for Wireshark  us...@wireshark.org>
> Subject: Re: [Wireshark-users] Custom CAN dissector script
>
> At 22:29 05.06.2023, Guy Harris wrote:
>
> >On Jun 5, 2023, at 3:43 AM, Fabian Cenedese 
> wrote:
> >
> >> We're using CAN bus as protocol and I implemented a capture to save
> >> the sent and received frames into a .pcapng file.
> >
> >So presumably that's using LINKTYPE_CAN_SOCKETCAN as the link-layer
> type in the IDBs, with the SocketCAN pseudo-header:
> >
> >
> https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html
>
> I also tried CAN20B (190), but now I'm using SOCKETCAN (227) as this
> worked better.
>
> >> I can
> >> load it in Wireshark and the frames are displayed as CAN which is
> >> correct. However the fields are only shown as identifier and data
> >> bytes which doesn't say much yet.
> >
> >I.e., a SocketCAN header with ID, flags, and frame length, followed by an
> undissected Data field?
>
> Yes.
>
> >> I would like to add a custom dissector that will interpret the CAN
> >> fields further down. The identifier needs to be broken down into two
> >> separate fields
> >
> >I.e., you need to redissect the ID field as having two separate subfields?
>
> This is a dumping tool for an existing customer application that is based
> on CAN. However they didn't follow any open protocol and implemented
> it a bit different. The ID includes both a node ID as well as a command
> (5+6 bits). Also the first data byte is combined of two fields (2+6 bits). To
> better make out the values I wanted to see them in Wireshark directly as
> they are cumbersome to calculate in the head from the bytes.
>
> >If by "script" you mean "dissector written in Lua rather than C", that's
> going to be a bit tricky; subdissectors called by the SocketCAN dissector
> are passed a pointer to a structure that includes, among other things, the
> ID, but that's a C structure, and we don't currently have a good way to
> pass information to Lua subdissectors.
>
> I just assumed that lua is the fastest or easiest way to go, but I could also
> create a dll if that is better.
>
> >> as well as the first data byte.
> >>
> >> How would I register this dissector as it doesn't use an Ethernet
> >> port?
> >
> >Not sure what an "Ethernet port" is, but various dissectors that call
> subdissectors have dissector tables using various keys, such as Ethernet
> types, TCP or UDP ports, and so on.
>
> Exactly, always Ethernet related.
>
> >The SocketCAN dissector has two tables, named "can.id
> <http://can.id/>" and "can.extended_id", which use the un-extended 11-
> bit ID field and the extended 29-bit ID field, respectively, as keys.  They
> use the entire ID field, not a subfield of the ID field.  It should be 
> possible
> to register either a C or Lua dissector in that table.
>
> Sounds promising, I&#

Re: [Wireshark-users] Custom CAN dissector script

[Guy Harris]

On Jun 5, 2023, at 1:58 PM, Fabian Cenedese  wrote:

> At 22:29 05.06.2023, Guy Harris wrote:
> 
>> On Jun 5, 2023, at 3:43 AM, Fabian Cenedese  wrote:
>> 
>>> We're using CAN bus as protocol and I implemented a capture
>>> to save the sent and received frames into a .pcapng file.
>> 
>> So presumably that's using LINKTYPE_CAN_SOCKETCAN as the link-layer type in 
>> the IDBs, with the SocketCAN pseudo-header:
>> 
>>   https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html
> 
> I also tried CAN20B (190), but now I'm using SOCKETCAN (227) as this
> worked better.

Unfortunately, CAN20B was never documented, and the people at CACE 
Technologies^W^WRiverbed^WSysdig don't remember what it was any more.

So, yes, LINKTYPE_CAN_SOCKETCAN is what should be used.

>> If by "script" you mean "dissector written in Lua rather than C", that's 
>> going to be a bit tricky; subdissectors called by the SocketCAN dissector 
>> are passed a pointer to a structure that includes, among other things, the 
>> ID, but that's a C structure, and we don't currently have a good way to pass 
>> information to Lua subdissectors.
> 
> I just assumed that lua is the fastest or easiest way to go, but I could
> also create a dll if that is better.

"Better" depends on the criteria; if your dissector needs to get at the CAN ID, 
as their... nonstandard way of using the ID seems to indicate, a C dissector 
would be "better" in that, currently, there's no way to get that from Lua.

(In the long term, we should provide a way to get at that from Lua (which might 
also involve passing information as a key-value store, which would also help 
*C* dissectors, as, instead of getting a blob whose structure is defined only 
by convention between the calling and called dissector, which is rather 
fragile, they'd get it as a key-value store as well.  But that's not what we 
have now.)

>>> as well as the first data byte.
>>> 
>>> How would I register this dissector as it doesn't use an Ethernet
>>> port?
>> 
>> Not sure what an "Ethernet port" is, but various dissectors that call 
>> subdissectors have dissector tables using various keys, such as Ethernet 
>> types, TCP or UDP ports, and so on.
> 
> Exactly, always Ethernet related.

TCP and UDP ports aren't Ethernet-related; only Ethernet types are.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Custom CAN dissector script

[Fabian Cenedese]

At 22:29 05.06.2023, Guy Harris wrote:

>On Jun 5, 2023, at 3:43 AM, Fabian Cenedese  wrote:
>
>> We're using CAN bus as protocol and I implemented a capture
>> to save the sent and received frames into a .pcapng file.
>
>So presumably that's using LINKTYPE_CAN_SOCKETCAN as the link-layer type in 
>the IDBs, with the SocketCAN pseudo-header:
>
>https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html

I also tried CAN20B (190), but now I'm using SOCKETCAN (227) as this
worked better.

>> I can
>> load it in Wireshark and the frames are displayed as CAN which
>> is correct. However the fields are only shown as identifier and
>> data bytes which doesn't say much yet.
>
>I.e., a SocketCAN header with ID, flags, and frame length, followed by an 
>undissected Data field?

Yes.

>> I would like to add a custom dissector that will interpret the CAN
>> fields further down. The identifier needs to be broken down into
>> two separate fields
>
>I.e., you need to redissect the ID field as having two separate subfields?

This is a dumping tool for an existing customer application that is based
on CAN. However they didn't follow any open protocol and implemented
it a bit different. The ID includes both a node ID as well as a command
(5+6 bits). Also the first data byte is combined of two fields (2+6 bits). To
better make out the values I wanted to see them in Wireshark directly as
they are cumbersome to calculate in the head from the bytes.

>If by "script" you mean "dissector written in Lua rather than C", that's going 
>to be a bit tricky; subdissectors called by the SocketCAN dissector are passed 
>a pointer to a structure that includes, among other things, the ID, but that's 
>a C structure, and we don't currently have a good way to pass information to 
>Lua subdissectors.

I just assumed that lua is the fastest or easiest way to go, but I could
also create a dll if that is better.

>> as well as the first data byte.
>> 
>> How would I register this dissector as it doesn't use an Ethernet
>> port?
>
>Not sure what an "Ethernet port" is, but various dissectors that call 
>subdissectors have dissector tables using various keys, such as Ethernet 
>types, TCP or UDP ports, and so on.

Exactly, always Ethernet related.

>The SocketCAN dissector has two tables, named "can.id " and 
>"can.extended_id", which use the un-extended 11-bit ID field and the extended 
>29-bit ID field, respectively, as keys.  They use the entire ID field, not a 
>subfield of the ID field.  It should be possible to register either a C or Lua 
>dissector in that table.

Sounds promising, I'll try that.

>> I'm happy if I can use it in the "Decode As" menu, it
>> doesn't need to be applied automatically.
>
>You could use dissector_add_for_decode_as() for a C dissector, or 
>dissectortable:add_for_decode_as() for a Lua dissector, to register in the 
>"can.subdissector" table; using "Decode As..." to specify that dissector would 
>cause all undissected CAN data to be passed that data.

I'm not in office on Tuesday but I will try when I get back. Thanks for
your help.

bye  Fabi

___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Custom CAN dissector script

[Guy Harris]

On Jun 5, 2023, at 3:43 AM, Fabian Cenedese  wrote:

> We're using CAN bus as protocol and I implemented a capture
> to save the sent and received frames into a .pcapng file.

So presumably that's using LINKTYPE_CAN_SOCKETCAN as the link-layer type in the 
IDBs, with the SocketCAN pseudo-header:

https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html

> I can
> load it in Wireshark and the frames are displayed as CAN which
> is correct. However the fields are only shown as identifier and
> data bytes which doesn't say much yet.

I.e., a SocketCAN header with ID, flags, and frame length, followed by an 
undissected Data field?

> I would like to add a custom dissector that will interpret the CAN
> fields further down. The identifier needs to be broken down into
> two separate fields

I.e., you need to redissect the ID field as having two separate subfields?

If by "script" you mean "dissector written in Lua rather than C", that's going 
to be a bit tricky; subdissectors called by the SocketCAN dissector are passed 
a pointer to a structure that includes, among other things, the ID, but that's 
a C structure, and we don't currently have a good way to pass information to 
Lua subdissectors.

> as well as the first data byte.
> 
> How would I register this dissector as it doesn't use an Ethernet
> port?

Not sure what an "Ethernet port" is, but various dissectors that call 
subdissectors have dissector tables using various keys, such as Ethernet types, 
TCP or UDP ports, and so on.

The SocketCAN dissector has two tables, named "can.id " and 
"can.extended_id", which use the un-extended 11-bit ID field and the extended 
29-bit ID field, respectively, as keys.  They use the entire ID field, not a 
subfield of the ID field.  It should be possible to register either a C or Lua 
dissector in that table.

> I'm happy if I can use it in the "Decode As" menu, it
> doesn't need to be applied automatically.

You could use dissector_add_for_decode_as() for a C dissector, or 
dissectortable:add_for_decode_as() for a Lua dissector, to register in the 
"can.subdissector" table; using "Decode As..." to specify that dissector would 
cause all undissected CAN data to be passed that data.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

[Wireshark-users] Custom CAN dissector script

[Fabian Cenedese]

Hello

We're using CAN bus as protocol and I implemented a capture
to save the sent and received frames into a .pcapng file. I can
load it in Wireshark and the frames are displayed as CAN which
is correct. However the fields are only shown as identifier and
data bytes which doesn't say much yet.

I would like to add a custom dissector that will interpret the CAN
fields further down. The identifier needs to be broken down into
two separate fields as well as the first data byte.

How would I register this dissector as it doesn't use an Ethernet
port? I'm happy if I can use it in the "Decode As" menu, it
doesn't need to be applied automatically. The examples I've
seen use a port which makes sense for Wireshark but not in
my case. Would it need to be a CAN sub-protocol?

Thanks for any help.

bye  Fabi

___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe