Comment # 10
on bug 9607
from Evan Huus
(In reply to comment #9)
> Evan,
> Do you think the link issue (and the other wtap/capture_file/"file helper"
> stuff) could/should be avoided with your notion of "new_file_based_tvb"?
> Right now I'm not seeing the connection (and thought the tvb stuff would be
> on top of wtap(ftap)/capture_file/etc)
>
> I'm posting this patch and committed the filetap library so that others can
> look at it and provide comments. The functionality is ballooning farther
> than I originally anticipated and I want to make sure I'm using/setting up
> the right building blocks.
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.
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).
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?
Once we've got it opening and dissecting files we can figure out linking issues
to trim the binary size, and how to deal with multi-record filesl, etc.
You are receiving this mail because:
- You are watching all bug changes.
