[Guy Harris <gharris@xxxxxxxxx>]

On May 5, 2025, at 7:12 PM, Michael Mann <mmann78@xxxxxxxxxxxx> wrote:

> 1. I was not looking to write the file back in the original (text based) format.  I was perfectly fine with "open as .trc file, save as .pcap (or .pcapng)" and I thought if I didn't provide write function callbacks in the wiretap, that's how Wireshark would behave.

Yes, the only way there would be support for writing the file back would be if there were write functions for .trc files; as long as the data is savable as pcap or pcapng, you would be able to save it if you make changes in Wireshark, and would be able to export selected packets from Wireshark (and use editcap to write selected packet, etc.).

If you modify it by adding comments, you would probably want to save it as pcapng, as the comments will be discarded if you save as pcap (because pcap doesn't support comments), and I think Wireshark will warn you of that and offer a choice of 1) discarding the comments and saving as pcap, 2) saving as pcapng, or 3) canceling writing the packets.

> 2. You are correct that I was conflating file formats and metadata as far as the layers between wiretap and dissection.  If WTAP_ENCAP_SOCKETCAN is used, then its "metadata format" needs to be followed and that's what I find a little clunky after looking at the dissection in Wireshark.

Constructing a SocketCAN metadata header isn't *that* clunky:

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

If it's a classic CAN frame or a CAN FD frame, see "CAN CC and CAN FD frames", write that header out, and append the payload.

If it's a CAN XL frame, see "CAN XL frames", write that header out, and append the payload.

> Here, I see wiretap as producing a "SocketCAN record",

It's not producing a "SocketCAN record" any more than it's producing an "Ethernet record" if it's producing a pcap packet record or a pcapng Enhanced Packet Block with a WTAP_ENCAP_ETHERNET link-layer type.  The only difference is that LINKTYPE_ETHERNET doesn't have any metadata but LINKTYPE_CAN_SOCKETCAN has metadata.

> and I thought producing a "pcap or pcapng record" would be better.  I thought the wiretap functionality I was writing was to "massage" into an existing "wtap_encap" format, and I want to shoot for a pcap or pcapng record over SocketCAN to take advantage of the LINKTYPE_LINUX_SLL link-layer format/dissection.

If you use WTAP_ENCAP_LINUX_SLL, you would have to produce a LINKTYPE_LINUX_SLL metadata header:

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

and then provide a LINKTYPE_CAN_SOCKETCAN-like metadata header *after* the LINKTYPE_LINUX_SLL metadata header and before the payload (see the information at the bottom of the page). More work, and more file data per packet.

In *either* case there's already a dissector in Wireshark, so you can take advantage of that dissector in either case.

> 3. Apparently text2pcap was refactored a few times since I wrote my "derived" applications. The most notable being in December 2021 when it was converted to use wtap_dump, which replaced all of the pcapio functions my applications were using. To me the "algorithm" text2pcap used to be (and my applications stayed with because I didn't have a reason to change them):
> a) write_file_header() that uses pcapng_write_section_header_block() and pcapng_write_interface_description_block()
> b) parse text data out of the file for packets and create them with pcapng_write_enhanced_packet_block()
> c) write_file_trailer that uses pcapng_write_interface_statistics_block() to provides statistics of the packet data read
> 
> What I was hoping for was a wiretap interface with a similar algorithm where just "b" needed to be adjusted as needed for slight differences in text formats (within the wth->subtype_read callback) and may not need a lexical scanner like text2pcap has.

There isn't such an interface, because nobody's spent any time looking at all the various text file formats that wiretap can read:

	Juniper Netscreen (wiretap/netscreen.c)

	Tektronix K12 text dump (wiretap/k12text.l)

	IBM i communications trace (wiretap/iseries.c - the name predates IBM Power Systems which can run IBM i, AIX, and Linux in separate LPARs)

	VMS TCPIPtrace (wiretap/vms.c)

	CoSine IPSX L2 capture (wiretap/cosine.c)

	Lucent/Ascend access server trace (wiretap/ascend_scanner.l, wiretap/ascend_parser.lemon, wiretap/ascendtext.c)

	Toshiba Compact ISDN Router snoop (wiretap/toshiba.c)

	VMS DBS Etherwatch (wiretap/dbs-etherwatch.c)

	Catapult DCT2000 .out trace (wiretap/catapult_dct2000.c)

	Daintree's Sensor Network Analyzer (wiretap/daintree-sna.c)

and maybe some others, and come up with a general parser that could handle all of them.

> Looking at the current ui/text_import*.[chl], it seems to focus on actual files and not "records" like I would want for the PEAK wiretap interface.

It's for importing/converting a single file in one sequential pass; it's writing a file with records, so it *somewhat* handles individual packets, but it doesn't have anything to remember file offsets and provide them when reading sequentially, or to read a packet at an arbitrary offset, the way a wiretap module would require.