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
