Comment # 13
on bug 9607
from Evan Huus
I still feel like I'm not doing a great job explaining myself :/ I shall try
again:
Wiretap can be viewed as a function that takes a raw file as input, and outputs
some metadata and packet records.
Epan can be viewed as a function that takes those metadata and packet records
as input, and outputs the dissection of those records.
Wireshark chains those two libs together to produce a function taking raw files
as input, and outputting dissections of the packets in those files.
Fileshark, ideally, takes raw files and produces the dissection of the files
themselves. I think the simplest way to accomplish this is to generate dummy
metadata and a dummy record, pass those to epan and let it do the work. I don't
think this process is complicated enough to warrant it's own library - it's
just a few memzeroed structs and one file-backed TVB.
On that method, Fileshark adapts to epan's API. We could, alternatively, do a
great deal of work to make epan's API more generic (presumably by splitting it
into a generic part, a packet part, and a file part). In this case fileshark
would be able to pass the raw file directly to the "file-specific epan" API,
and would also not need an intermediate library.
You are receiving this mail because:
- You are watching all bug changes.
