[David Perry <boolean263@xxxxxxxxx>]

Having slept on this, another approach has come to mind. Since epan 
already links to wiretap, we could move the data-generation part of 
exported_pdu.c into wiretap, while the tap API for exporting PDUs stays 
in epan.

Thoughts on this, or my original email?

David

> Date: Tue, 8 Dec 2020 15:58:06 -0500
> From: David Perry <boolean263@xxxxxxxxx>
> To: wireshark-dev@xxxxxxxxxxxxx
> Subject: [Wireshark-dev] Having/avoiding epan dependencies in wiretap
> Message-ID: <02148f24-8ef1-8e54-68ac-90c996064686@xxxxxxxxx>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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