# UAVCAN v1 Wireshark plugin **URL:** \ **Category:** Applications & Usage\ **Created:** [January 7, 2021, 4:15pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058 "2021-01-07T16:15:22Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\ **Post date:** [January 7, 2021, 4:15pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/1 "2021-01-07T16:15:22Z")
Hey all, I’ve made a simple wireshark dissector for UAVCAN/CAN v1. It supports both CAN2.0B and CAN FD transport using SocketCAN in Linux. People can use SLCAND to use UART based adapters. Current features of the dissector is: - CAN ID decoding - Tail byte decoding - Message reassembly - Basic static message decoding - Very basic error checking Current messages with static port identifier can be decoded: - Heartbeat 1.0 - Access 1.0 - List 1.0 - NodeIDAllocationData 1.0 - NodeIDAllocationData 2.0 I didn’t verified for correctness, but it does check the toggle-bit in multi-frame transfers. Furthermore I’m not planning to include to all the public\_regulated\_data\_types. If people are interested we can take a look to get it into upstream Wireshark. ![uavcan_heartbeat](https://forum.opencyphal.org/uploads/default/original/1X/c44635aa8beb1579f740ab6e1945665d3d31f9a0.png) ![uavcan_multi_frame](https://forum.opencyphal.org/uploads/default/original/1X/a36af4c286bf787adf19cbc3671c11299ca5b428.png) It’s located here [GitHub - PetervdPerk-NXP/wireshark: Read-only mirror of Wireshark's Git repository at https://gitlab.com/wireshark/wireshark. GitHub won't let us disable pull requests. ☞ THEY WILL BE IGNORED HERE ☜ Please upload them at GitLab. · GitHub](https://github.com/PetervdPerk-NXP/wireshark) The code for the dissector itself is here: [https://github.com/PetervdPerk-NXP/wireshark/blob/d2b0614246af759158c86c91563cf53155ef4c40/epan/dissectors/packet-uavcan.c](https://github.com/PetervdPerk-NXP/wireshark/blob/d2b0614246af759158c86c91563cf53155ef4c40/epan/dissectors/packet-uavcan.c) ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [January 7, 2021, 5:50pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/2 "2021-01-07T17:50:28Z")
Hey Peter, This is great. I’ve been also thinking that it would be nice to have a dissector for Wireshark. I think if there is an opportunity to have these changes upstreamed, that would be great, but I would like to add a few comments on this. First things first: in the column “protocol” it says “UAVCAN”, but I think what you mean is “UAVCAN/CAN” because as you know _there is no “CAN” in “UAVCAN”_. One may want to [leverage Wireshark for UAVCAN/UDP](https://forum.opencyphal.org/t/alternative-transport-protocols-in-uavcan/324/47) or UAVCAN/anything-else in which case having distinctive names for different transport layers would be helpful. There are also comments in the source code that seem to say “UAVCAN” where “UAVCAN/CAN” would be more correct: > Second, would you consider perhaps extracting the DSDL dissector from the UAVCAN/CAN layer in order to allow people to use it with other transports? Observe that UAVCAN/CAN is the transport layer whereas DSDL is the presentation layer that can also sit on top of UAVCAN/UDP, so from the standpoint of architecture and plain reusability it makes sense to separate it. Although that said, I am not sure if it makes much sense to dissect DSDL in the first place (whether as part of the transport layer or from a separate dissector) because DSDL is too abstract for a tool like Wireshark. For purposes of comparison, you wouldn’t use Wireshark to parse an RPC-XML payload, too, because the tool is not built for debugging the application layer and simply lacks the necessary UX rigging for the job. Also, as I wrote recently [in the documentation for Yakut](https://github.com/UAVCAN/yakut), giving the standard data types too much of special treatment may set dangerous precedents: > A question one is likely to ask here is: _Why don’t you ship precompiled regulated DSDL together with the tool?_ Indeed, that would be trivial to do, but we avoid that on purpose to emphasize our commitment to supporting vendor-specific and regulated DSDL at the same level. In the past we used to give regulated namespaces special treatment, which caused our users to acquire misconceptions about the purpose of DSDL. Specifically, there have been forks of the standard namespace extended with vendor-specific types, which is harmful to the ecosystem. If you feel like your work on the DS-015 integration is dependent on the availability of a decent diagnostic tool, I suggest we channel our efforts in a different direction: extending Yakut (and eventually Yukon, but that is a separate story) with the proper UAVCAN-centric application-layer diagnostic capability – something that you can’t do properly in Wireshark as I just wrote. The plan is simple and we can set it up in no time if you could lend me a hand with a bit of Pythoning here. Over the last month, I have done the groundwork necessary for performing [packet capture and dissection using PyUAVCAN](https://pyuavcan.readthedocs.io/en/latest/pages/architecture.html#advanced-network-diagnostics-sniffing-snooping-tracing-spoofing). This foundation does most of the hard work already, but what’s missing is a human-friendly interface on top of it. I am envisioning two additional commands for Yakut for this purpose: - **`yakut capture`** to read frames from the specified network interface (which, observe, doesn’t need to be SocketCAN! @polaris is planning to finalize [his pull request](https://github.com/UAVCAN/pyuavcan/pull/123) adding support for another CAN backend supporting other hardware + Windows over this weekend). The command would receive raw transport frames from the network, encapsulate them using [**`uavcan.metatransport.*`**](https://github.com/UAVCAN/public_regulated_data_types/tree/master/uavcan/metatransport), serialize using UAVCAN/serial, and emit them into stdout. The result is intentionally not human-readable, but it can be piped into a file or into the next command: - **`yakut trace`** , which reads the UAVCAN/serial encoded stream of encapsulated frames from stdin and feeds that into [**`pyuavcan.transport.Tracer`**](https://pyuavcan.readthedocs.io/en/latest/.apidoc_generated/pyuavcan.transport.html#sniffing-snooping-and-tracing). The output is then deserialized using the data types specified by the user and printed into stdout in our conventional YAML or JSON format (like `yakut sub` does). Naturally, the data supplied via stdin may come either from the aforementioned `yakut capture` or from a UAVCAN log file. The latter would close the long- and sorely-missing feature that has been discussed [many](https://forum.opencyphal.org/t/what-should-our-logging-format-be/764), [many](https://forum.opencyphal.org/t/yukon-design-megathread/390/19), [many](https://forum.opencyphal.org/t/looking-for-a-way-to-record-can-log-to-file-uavcan-gui-app/763), [many](https://github.com/UAVCAN/yakut/issues/1) times already. Then, for a real-time capture session, the usage would be roughly as follows: ```auto yakut capture --transport='CAN(something...)' | yakut trace 33.uavcan.si.sample.length.Vector3.1.0 --path=/my/dsdl ``` The fact that we split the work into two operations (capture and trace) is essential here as it allows us to drastically conserve work by addressing different use cases with a single feature. The resulting log format is not specific to Yakut, since it is just a raw dump of UAVCAN/serial, and as such, it can be supported by standalone on-board data recorders, which is also a commonly requested feature. The missing bits are fairly minor and can be implemented in a few working days: - Implement the capture and tracing functionality for the UAVCAN/CAN transport in PyUAVCAN (currently it is available only for UAVCAN/serial and UAVCAN/UDP). I can do this myself, CAN is an easy transport to implement this for. - Merge [Address design issues in uavcan.metatransport by pavel-kirienko · Pull Request #99 · OpenCyphal/public\_regulated\_data\_types · GitHub](https://github.com/UAVCAN/public_regulated_data_types/pull/99) (it’s finished already) - Add the two commands to Yakut. They will contain very little business logic, mostly related to converting data between different representations using PyUAVCAN. Would you be inclined to join this effort? I can give you a quick intro to Yakut then. If you choose yes, then I would recommend actually withdrawing the DSDL parser functionality from your Wireshark dissector (keeping the transport dissector intact of course) for the aforementioned reasons. ---
**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\ **Post date:** [January 7, 2021, 6:50pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/3 "2021-01-07T18:50:12Z")
Hi Pavel, Good point about the naming, indeed the dissector is for UAVCAN/CAN traffic, I can change the name that’s no problem. > Second, would you consider perhaps extracting the DSDL dissector from the UAVCAN/CAN layer in order to allow people to use it with other transports? I don’t think we should include DSDL into Wireshark, I think tooling such as PyUAVCAN, yakut or Yukon will do a better job at that. Furthermore in Wireshark everything seems to be quite static whereas for example the public\_regulated\_data\_types repository is bound to change from time to time. However there’s a reason why I’ve implemented the minimal subset of messages/services (Heartbeat, register and NodeIDAllocation) since I think they are part of the “UAVCAN Standard Message definition” and allows for quick debugging and filtering through Wireshark. ![uavcan_heartbeat_filter](https://forum.opencyphal.org/uploads/default/original/1X/6496cd22a703ea0863dbb0f1352ea47eadd6743e.png) > If you feel like your work on the DS-015 integration is dependent on the availability of a decent diagnostic tool, I suggest we channel our efforts in a different direction: extending Yakut (and eventually Yukon, but that is a separate story) Having more advanced tooling is always a nice to have and thus I don’t want to extent Wireshark dissector any further (it’s already 1200 lines of code anyhow 😉). Using Wireshark in combination with PyUAVCAN to decode DSDL is currently enough for me now. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [January 8, 2021, 11:48am UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/4 "2021-01-08T11:48:43Z")
> [@PetervdPerk](#): > > I don’t think we should include DSDL into Wireshark, I think tooling such as PyUAVCAN, yakut or Yukon will do a better job at that. Furthermore in Wireshark everything seems to be quite static whereas for example the public\_regulated\_data\_types repository is bound to change from time to time. That’s my point exactly. You seem to prefer to keep the current limited support of DSDL in place, in which case I would recommend extracting it into a separate dissector to make it reusable with other UAVCAN transports. Would that be possible? > [@PetervdPerk](#): > > Having more advanced tooling is always a nice to have and thus I don’t want to extent Wireshark dissector any further That makes sense, but what I am offering is not related to Wireshark at all and it does not affect your dissector in any way. ---
**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\ **Post date:** [January 15, 2021, 6:04pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/5 "2021-01-15T18:04:47Z")
I’ve extracted the DSDL decoding from UAVCAN/CAN into [packet-uavcan-dsdl.c](https://github.com/PetervdPerk-NXP/wireshark/blob/a936ffad1c3bc8452eeaacf855686bc162b96f9c/epan/dissectors/packet-uavcan-dsdl.c) which in theory can be used with a UAVCAN/UDP dissector. Furthermore I did some naming/taxonomy fixes regarding UAVCAN/CAN, feel free to test it out. ![wireshark_uavcan_dsdl](https://forum.opencyphal.org/uploads/default/original/1X/efe39f3c85d068fec10811c4e82510b799cd7d21.png) ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [January 15, 2021, 6:30pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/6 "2021-01-15T18:30:04Z")
This is great. How difficult would it be to get it into upstream? Also, seeing GPS in your screenshot reminds me that this PR would benefit from your review: > ---
**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\ **Post date:** [January 18, 2021, 9:56am UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/7 "2021-01-18T09:56:42Z")
Didn’t look at the merging process from Wireshark yet (e.g. code-style & QA), but I suppose it shouldn’t be that hard since didn’t had to change core functionality of wireshark. But first I do want to do some extensive testing of the dissector with more advanced test data. To fix things like > ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [January 30, 2021, 7:19pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/8 "2021-01-30T19:19:20Z")
This is super-exciting. I have a vendor that is looking for this support. Please let me know when it is upstream so I can copy them. Thanks @PetervdPerk! ---
**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\ **Post date:** [April 21, 2021, 7:55pm UTC](https://forum.opencyphal.org/t/uavcan-v1-wireshark-plugin/1058/9 "2021-04-21T19:55:10Z")
As of now it’s available in upstream Wireshark > **[UAVCAN/CAN dissector see https://uavcan.org/ (4959ae65) · Commits · Wireshark...](https://gitlab.com/wireshark/wireshark/-/commit/4959ae652eb626b03b07ce284d3f36d4472bb0a7)** > > Wireshark's official Git repository.