Comment # 11
on bug 9607
from Michael Mann
(In reply to comment #10)
> I think
> you're over-complicating things if I understand correctly. Wiretap's job is
> to abstract all the different capture formats into a single API providing a
> list of packets + extra stuff like name-resolution blocks. For tfshark we
> have no "pre-processing" to do before we hand the data to the dissectors -
> all we need is an API that abstracts the file into a series of bytes, which
> is what fopen and friends already do.
I was certainly worried about starting to over-complicating things, but I
thought one of Wiretap's jobs was to provide a "header" and an array of
"records" (aka packets), so I thought Filetap was necessary to provide "a
generic version" of that for non-capture files.
> In my mind, the simplest way forward
> is first to implement epan/tvbuff_file.c which fopens a file and uses
> seek/read to implement the TVB interface (I don't expect this to be too
> hard, Jakub knows this interface best).
But file.c already provides seek/read functionality within a file itself, it's
just uses a capture_file structure (which I don't really want). This sits
below wiretap (which is below tvb), and I wanted to somehow put filetap between
file.c (functionality) and the tvb.
> Then the normal "dissect" path in
> tfshark becomes very simple:
> create a tvb_file backed by the file we are
> dissecting create dummy wtap_pkthdr and frame_data structs (probably just
> memzeroed is fine)
> pass all of the above to epan_dissect_run()
> Wiretap/filetap/etc never need to get involved.
> Does this make sense?
I can see this is a simpler design, but I thought we wanted to leverage
frame_data structs as a "generic record/frame" and discard (preferably remove)
wtap_pkthdr in favor of a "generic header" (data blob) within fileshark. Are
you seeing my design as more of a "long term solution" or do you think it will
always be "too complicated"?
You are receiving this mail because:
- You are watching all bug changes.
