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

Wireshark-dev: [Wireshark-dev] Having/avoiding epan dependencies in wiretap

From: David Perry <boolean263@xxxxxxxxx>
Date: Tue, 8 Dec 2020 15:58:06 -0500
Hi all,

In brief, I've found some code in wiretap that appears to be duplicated from code in epan. I can't replace it with calls to the epan code, because that would mean linking wiretap against epan, when epan already links against wiretap. What approach would you suggest?

In detail...

I've decided to poke at [issue 17009][1], seeing if I can increase the size of nettrace file that can be loaded. The nettrace loader works (in part) by reading the XML-based metadata and turning it into binary [Exported PDU][2] headers for parsing by Wireshark proper.

The current code in wiretap/nettrace_3gpp_32_423.c looks to be duplicated from epan/exported_pdu.c, or at least, very strongly inspired by it. The code in the latter file is geared towards being used as a protocol tap, but I've got a working strategy for making it more broadly usable. I got as far as replacing the copied code in the nettrace reader with calls to the exported_pdu code, but the compile test failed because the added dependency of wiretap on epan causes a circular dependency graph.

There are a few ways to proceed, but I'm wondering what you experts would recommend.

The easiest and most hassle-free approach is to just leave the duplicated code as-is. I was hoping to avoid this because any change in epan to the saving or loading of Exported PDU data needs to be propagated to the wiretap code as well.

We could possibly move appropriate parts of epan/exported_pdu.c out of epan and into wsutil, where epan and wiretap can both access it. It'd take some design consideration to do it in a way that makes it independently usable without breaking its use as a tap routine.

There's probably some linker black magic that'd let things work as they are now, but that way lies madness. And of course there are likely other approaches I haven't considered yet.

So, what do you folks think should happen here? What approach would you endorse?

Thanks in advance,

David Perry


[1]: https://gitlab.com/wireshark/wireshark/-/issues/17009
[2]: https://gitlab.com/wireshark/wireshark/-/wikis/Protocols/exported_pdu