[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 15 on bug 9607 from Evan Huus

(In reply to comment #14)
> (In reply to comment #13)
> > I still feel like I'm not doing a great job explaining myself :/ I shall try
> > again:
> 
> I've certainly followed it all and I think it's all things that need to be
> said/discussed (just not sure if it should be in this bug or -dev).  Comment
> #13 is a nice summary of comment #12 and overall I still prefer (and have
> been working towards) the second approach.  However I feel I've reached the
> point where "disruption" is about to occur in order to go farther with it.
> 
> > Wiretap can be viewed as a function that takes a raw file as input,
> > and outputs some metadata and packet records.
> 
> Yes, that was my goal with Filetap - to take a raw file and turn it into an
> array of records and metadata (that I would usually see as a "header")
> 
> > Epan can be viewed as a
> > function that takes those metadata and packet records as input, and outputs
> > the dissection of those records.
> 
> Then the output of Filetap should able to be cleanly passed to Epan without
> modification
> 
> > 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.
> 
> I agree it doesn't really need it's own library, but I created one to not
> disrupt wiretap in its current state (because functionality was different
> enough).

I don't think it would disrupt wiretap even if it didn't have its own library.
It's basically a single function that takes the filename and returns all the
necessary structs, so you could practically inline it in tfshark.c for a proof
of concept.

> I don't like the idea of that much "dummy data".  "Long term" I
> thought both could be merged, but I didn't want to take that time now and
> hold up the fileshark idea.

Me neither; I'd just rather have a basic working program (dummy data and all)
to attract more contributions before we start rearchitecting.

> Since Wireshark's architecture is more "record based" (from epan all the way
> through the GUI and how information is displayed), I was intentionally
> trying to gear the filetap/fileshark design towards record based file
> formats.  The "file dissectors" that currently exist and want to be
> committed all fall in that category.  If someone wanted a non-record based
> file to part of fileshark, I would want them to "hack" something to treat
> the entire file as a single record, but I'm hoping that's the exception, not
> the rule.  That's why I didn't want to start with presenting the whole file
> as a single tvb.

Ah, I see, I was taking the opposite approach here; I would assume files are
*not* record-based, and let the file-*.c dissector call some new API to add
records.

> > 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.
> 
> I thought the current "file dissectors" have proven that epan's API doesn't
> need to modified as long as file has a record based architecture.  And
> that's all I want Fileshark to be at the moment.

Ok, that's where the confusion is - I thought you were playing with ideas where
we could support non-record-based files as well. Filetap makes much more sense
if we're focusing just on record-based files.

---

In this case my first concern is with record types. Wiretap works because there
only ~150 ways network packets can reasonably be encapsulated. The equivalent
filetap list would get quickly out of hand if we add an "encapsulation type"
for every kind of record for every kind of file-type.

Also, it feels weird to have file-structure logic split in two places; we'd
need some logic in filetap to extract the records, and some logic in the
dissector to dissect those records. If the record-length depended on the
record-type, for example, then that information would be duplicated in both.

I understand the goal of filetap now, but I am coming to the conclusion that
even focusing just on record-based formats, it might make more sense to
initially present the file as a single frame/record/packet to the appropriate
dissector.

---

      You are receiving this mail because:

• You are watching all bug changes.