ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Some questions about the "option block" interface in libwire

From: Michael Mann <mmann78@xxxxxxxxxxxx>
Date: Fri, 20 May 2016 20:50:13 -0400
I'll take a shot at this.  I think I have some ideas that could work.
 
 
-----Original Message-----
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, May 20, 2016 7:28 pm
Subject: Re: [Wireshark-dev] Some questions about the "option block" interface in libwiretap

 
> 11) Self-writing/serializing block types: For the same reason I really don't think self-writing of PCAP-NG blocks belongs in wtap_opttypes.c (as relatively recently added in https://code.wireshark.org/review/#/c/14357/). I think the optionblock should act more like a well-known list of generic and filetype specific options that fit into that metadata category. Perhaps formats could register a write function each for the block type, but I personally don't see much benefit in this. The format might as well treat it similarly to foreign encap types in its dump function, where the wiretap determines how the information should be converted or written out for that format.

Yes, wtap_opttypes.c combines "generic" code and code to write pcapng blocks and option, so the code to handle pcapng is split between that file and pcapng.c. Code to *read* them is still all in pcapng.c, however.

I think it might be best not to have the "generic" code know anything about the pcapng file format.