Wireshark-bugs: [Wireshark-bugs] [Bug 8590] Move understanding of PCAP-NG blocks out of libwiret
Comment # 3
on bug 8590
from Brandon
(In reply to comment #2)
> With this change, could I, for example, read a pcap-ng file containing only
> Ethernet packets and write out a pcap file, or a Microsoft NetMon file, with
> the packets in question?
It depends on on how much the other formats depend on the interface and section
information filled in by the current PCAP-NG wiretap routines. This patch does
not currently fill in most of those fields, however, it would not take much to
fill in those details from the PCAP-NG dissector so that saving/exporting works
as expected.
> The dissection might be better, but the question is whether most of the goals
> could be achieved with changes to the Wiretap library API (which might also
> improve the handling of *other* file formats)?
I would not consider this enhancement feature complete. I did not want put
much more time into it unless the Wireshark community thinks it worth pursuing.
If there is interest in moving this forward, I would love to work with the
community to complete it. Or if there is alternative approach that produces
similar results, I would love to help out there as well.
What I am really interested in is being able to easily add support for
additional block types without having to add a bunch of pointers to special
structures to move that data from libwiretap to libwireshark. It is also
valuable to view some non-packet data mixed in with the packet data. For
instance, the Hone patch adds process information in with the packets to give a
better picture of what is really happening on a system (I'll try to add a Hone
capture soon).
This is actually my second attempt at meeting these goals. The first left the
block dissection in libwiretap, but it was difficult to implement without
making a mess of things. This implementation is much cleaner because it lets
the two libraries do what they do best: libwiretap just reads and writes record
blocks and libwireshark handles the dissection. You can see that this approach
is pretty clean by how little the already existing code changed. This version
is also much more stable.
You are receiving this mail because:
- You are watching all bug changes.
