On Jun 24, 2013, at 12:04 AM, Michal Labedzki <michal.labedzki@xxxxxxxxx> wrote:
> On 21 June 2013 19:54, Gilbert Ramirez <gram@xxxxxxxxxxxxxxx> wrote:
>
>> One thing that comes to mind about how a FileShark GUI should be different from a WireShark GUI is the amount of data that should / can be shown.
>>
>> In my job, I often analyze ELF files. Very big ELF files. One thing I'd like to do in FileShark is to read them, look at the various headers, but not have it show me all the data in each ELF section by default. Because, they are huge, and I don't need a hexdump of megabytes of data I don't care about.
>>
>> maybe it's just a matter of not using the "data" dissector.... but then again, I wouldn't want the hexdump pane to have to show gigabytes of raw data.
>
> Ok, so you need to change UI Pane Layout only (Packet Bytes set to None).
Depends on the file. For example, showing the bytes that aren't just flagged as "raw data" by the dissector - i.e., stuff it considers "headers" rather than "data" - might be useful.
> But for me File/Packet Bytes is very useful (Packet List is not useful...
Not useful *for you*, perhaps. I've found it useful on occasion (especially with a filtered capture/display, so it's showing a particular conversation I'm interested in).
And the panes a given user wants to see in Fileshark might be different from the ones they want to see in Wireshark.
>
> On 21 June 2013 19:56, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
>>> 3. What about files like *.pcap, *.pcapng, btsnoop, etc.? In Wireshark will be easy to firstly dissect it by file dissector
>>
>> Possibly, possibly not. If a file dissector can do *everything* that a libwiretap module can (including supporting random access), and not show the user the details of how packets happen to be represented in this particular file format (which isn't interesting to somebody looking at network traffic), then yes, otherwise no.
>
> I guess interesting option can be:
> 1. Dissect on demand (button "Dissect payload" (like "Dissect File"))
> 2. File -> "Open as" - because we can open for example PCAP file in two ways: File or Packet.
That's one option; two different applications is another one, which is not inherently worse than the first option.
> This can be Holy Grail for somebody who have problem opening with heuristics protocols (like mp2t)
Presumably you mean "heuristic Wiretap readers"; "open as collection of packets" vs. "open as structured file" is a choice where there's no "right" answer, as it depends on what you're trying to do (right now, I'm doing some reverse engineering on NetXRay/Windows Sniffer files, where opening as a structured file would be useful, but, other times, somebody might not have any reason whatsoever to care about how that particular file format happens to store packets), but explicitly saying "open as collection of MP2T packets" is just a workaround for heuristics that don't (or can't) figure out the file format - in the best of all worlds, it wouldn't be necessary, and wouldn't be offered, but it might have to be offered in some cases.
