As mentioned by Chris Maynard on Ask Wireshark (
http://ask.wireshark.org/questions/22527/using-hexviewer-to-look-at-the-pcap-file-how-do-you-know-the-start-of-frame)
there appears to be another product called FileShark (
https://www.fileshark.us/) that for only $200 automagically deletes old
copie
On Thu, Jun 20, 2013 at 11:54:37AM -0700, Evan Huus wrote:
> This topic has come up a couple of times already on the list, and
> people have has submitted several patches to dissect files but there
> has been some worry about scope creep and the potential architectural
> differences between file an
On Jun 24, 2013, at 12:04 AM, Michal Labedzki wrote:
> On 21 June 2013 19:54, Gilbert Ramirez 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
On 21 June 2013 19:54, Gilbert Ramirez 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 FileSha
On Jun 20, 2013, at 11:57 PM, Michal Labedzki 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 support
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 ha
> Thoughts? Comments? Suggestions?
I like the idea of a sister application targetting files. I'm not concerned at
this point how to structure dissectors, libraries and APIs. We should just get
it started and re-evaluate after some months if we like the partition. If we
plan to go through a review
Hi,
I think that presented idea is good news.
So question from my side:
1. Why separate application? ("Shared") Code maintenance should be easier
in one application (no copy of any code). I guess there will be only some
cosmetic changes in present file instead of protocol:
a) no Packet List (becau
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 thin
On Thu, Jun 20, 2013 at 2:39 PM, Gilbert Ramirez 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 dissect
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
On Jun 20, 2013, at 11:54 AM, Evan Huus 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 ch
This topic has come up a couple of times already on the list, and
people have has submitted several patches to dissect files but there
has been some worry about scope creep and the potential architectural
differences between file and packet dissection, so not a lot has
gotten done and most of those
13 matches
Mail list logo
