ASN1 decoding
Closed this issue · 7 comments
Hi,
this is not an issue, but I would like to ask how can I decode captured CAMs of this amazing project, like
ffff ffff ffff 0000 0000 0000 8947 1200 1a01 0210 0000 01e5 763f 4f98 fc02 0000 0024 8000 0151 2050 0080 002d 0100 8000 0000 0000 0000 473b 36fb 1d11 3b88 06d0 6527 8000 0000 0000 0000 07d1 0000 0202 0000 0001 3731 005a 56c4 918e 4346 e51f ffff fc23 b774 3e00 0001 2000 003f e1ed 0403 ffe3 fff4 0043 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00
Unfortunately, I'm not so far with ASN.1 and I saw some hints in the recent entries how to 'decode a message within the code'. But how can I use Vanetza's asn files to decode the captured messages with wireshark? I only found an obsolete wireshark ITS plugin
Thanks for your help!
You don't need a plugin for Wireshark any longer, it can dissect GeoNetworking packets and CAMs out-of-the-box now.
Vanetza has no built-in support for Wireshark's PCAP format, so you will need to add some code for reading captured packets from a file. As soon as you have copied the bytes from the captured packet into a vanetza::ByteBuffer, it is fairly easy to create a vanetza::CohesivePacket out of it. You can just pass this packet then to the geonet::Router via its indicate method. Vanetza does not care if a packet comes from a network interface card or has been forged from a capture file.
I tried the first option.
I used the print-tx-cam option while I have captured the messages on the receiving module. I opened this file with wireshark and copied the data bytes to an online ASN1 decoder. There, I selected the ETSI CAM protocol version 1.4.1 and decoded the data bytes. The strange thing is that the content of the printed tx cam is different than the content of the decoded cam, see attachments.
printed_tx_cam.txt
exported_packet_dissections.txt
e4e8256f580149a78f718e7e7a339243.hex.uper.txt
The bytes you have selected in your screenshot (starting with 0x12) are not only CAM but GeoNetworking headers + BTP header + CAM. The actual CAM payload starts 44 bytes later with the two consecutive 0x02 bytes; former is the protocol version (2), latter the message id (also 2).
What you have decoded with the ASN.1 decoder is "GeoNetworking interpreted as CAM", which produces the garbage you have attached.
I have installed (unmodified) Wireshark 3.4 on my system, which can neatly dissect the packets generated by Vanetza's socktap. See the attached screenshot.
Thanks. Sorry, the newest wireshark version within my used package repo didn't correspond to the newest official version from wireshark itself.
@riebl: Yes, my problem is solved after updating to wireshark version 3.4.
A small additional question: I also executed the UDP link variant of socktap and looked for the UDP packets in Wireshark (filtering for port 8947). The captured packets are identified (as expected) as UDP packets, but the UDP payload (which contains the Ethernet, GN header and so on) is identified as skype protocol. Is it possible to apply the GN and CAM dissector directly to this UDP payload?
You can tell Wireshark to decode payloads arriving at UDP port 8947 as "Ethernet". Look for "Decode as..." in the "Analyze" menu.