At 22:29 05.06.2023, Guy Harris wrote: >On Jun 5, 2023, at 3:43 AM, Fabian Cenedese <cened...@indel.ch> 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'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 <wireshark-users@wireshark.org> 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
