[Gilbert Ramirez <gram@xxxxxxxxxxxxxxx>]

Hmm, I don't know what I'm thinking of "file dissectors" as being analogous to wiretap modules.  I should have thought of them as dissectors instead. My fault.

As long as we have plugins with a good API, then that's good. In fact, we should have a better plugin API than what we have now. I am thinking specifically of custom file formats that I would want to write "file dissectors" for (for some proprietary file formats at my job).

Thanks,

Gilbert

On Thu, Jun 20, 2013 at 3:57 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

On Thu, Jun 20, 2013 at 2:39 PM, Gilbert Ramirez <gram@xxxxxxxxxxxxxxx> wrote:
> I've written some tools to read various file formats, and what I have
> learned from this is that it's really most useful to create:
>
> 1. a generic library for reading a file format.
> 2. an application dissector (i.e, a FileShark dissector) for using the
> generic library, and providing the API that the application (FileShark)
> wnats.
> 3. And on top of that, FileShark itself.
>
> This is good so that other programs besides FileShark can make use of the
> generic libraries.

I think this is the wrong way to approach the problem. To draw a
parallel, there's a reason we don't just link a normal TCP stack into
Wireshark. The goal is to be able to display the raw structure of the
file/packets, which is sometimes quite different from the values that
an application reading the file/packets is going to care about.

> This is different from how we did wiretap, in which the logic for dissecting
> a packet capture is embedded directly in the wiretap module. If another
> application wanted to decode packet captures, it would have to link against
> wiretap, and use its APIs.

Wiretap is a library for reading packet file formats, which is
basically step 1 of your proposal. I'm not entirely clear on what in
your proposal is different, or why it makes sense to do this.

> This would mean we might spawn some new projects that read the file formats,
> and those would be separate from FileShark itself. But, that's more
> generally useful.

If we're going to be decoding a file in Fileshark, there's almost
certainly already a library to read/write it for applications, as
otherwise there would be no files for us to decode.

> Taking this a step further, maybe it's time to "harden" the APIs of the
> various modules of Wireshark, and also break apart Wireshark. wiretap could
> be removed entirely out of the Wireshark source base, and put into its own
> SCM repo and released independently.

I would be very happy to make proper libraries out of wiretap,
dfilter, epan, etc (and I designed wmem with this in mind). I suspect
splitting them out into multiple repositories is just making work at
this point, but if there's interest once they're usable stand-alone
then it might make sense to reconsider.

Evan

> Gilbert
>
>
>
>
>
> On Thu, Jun 20, 2013 at 2:15 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>>
>>
>> On Jun 20, 2013, at 11:54 AM, Evan Huus <eapache@xxxxxxxxx> wrote:
>>
>> > 3. Create a separate application called Fileshark that doesn't use
>> > wiretap and links only against libfiledissectors. When dissecting
>> > files directly, wiretap simply gets in the way. Additionally, people
>> > have pointed out several possible UI changes that make sense for files
>> > but not for packets. While hopefully Fileshark and Wireshark will be
>> > able to share much of their code, there are still places where they
>> > will diverge and we want to be able to do that cleanly.
>>
>> Yes.  For example, in Fileshark, you either:
>>
>>         1) might want to show, in a summary pane, multiple items for
>> multiple sections/records/etc. of a file
>>
>> or
>>
>>         2) show only one pane, a detail pane, so that with everything
>> closed up, you have a list of sections/records/etc..
>>
>> > Some of the consequences of this:
>> > - Wireshark proper will not open non-capture files directly. It will
>> > parse files it sees over transport protocols, but to parse an on-disk
>> > file directly will require opening it in Fileshark.
>>
>> Note, BTW, that you might well want to have file dissectors for various
>> forms of capture files that Wireshark can read; if you open those files in
>> Wireshark, they'd show you the packets (and perhaps other records), but if
>> you open them in Fileshark, they'd show you the file header (if there is
>> one) and the file records (including the raw contents of record headers,
>> etc.) - that might be a useful tool for Wireshark developers
>> reverse-engineering features of not-publicly-documented file formats.
>>
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe