Someone thought it would be an awesome idea to launch DoS attacks on
wireshark.org this week so I've been having to do emergency change
management. Everything should be back up and running now. Sorry for the
downtime.
On 6/21/13 9:11 PM, Maynard, Chris wrote:
> Both http://wiki.wireshark.org/ and
Both http://wiki.wireshark.org/ and https://bugs.wireshark.org/bugzilla/ seem
to be down as well.
http://www.wireshark.org/ and http://ask.wireshark.org/ still work though.
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behal
On 2013-06-21, at 8:27 PM, "Maynard, Chris"
wrote:
> Hmm, clicking
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=50109, I get
> the following:
>
> An Exception Has Occurred
>
> Invalid revision
It looks like anon svn is not syncing properly? The last few commits aren't
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
Thus wrote Guy Harris (g...@alum.mit.edu):
> On Jun 20, 2013, at 5:15 PM, Gerald Combs wrote:
> > On 6/20/13 5:13 PM, Evan Huus wrote:
> >> Very cool. I'm starting to wonder now if the file dissectors should be
> >> named file-foo.c instead of packet-foo.c?
> > That makes sense to me.
> +1
Technically you could use smart pointers, or other types too.
But beware the performance impact, and do get numbers before changing.
Ethereal/Wireshark does an enormous amount of small allocations and frees.
One of my primary goals when we added the first emem allocators were
performance.
Make
OK for me also on XP x32, although I'm not sure how to feed in the seed
from the failing test run.
Graham
On 20 June 2013 16:56, Pascal Quantin wrote:
> Failed to reproduce it on my side also, but I was running on Windows 7
> x64. I will not have access to my XP x32 box before I go back home in
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
> C++. It snuck in with Qt. Should we allow C++ in the rest of the code or
> at least use C++ compilation everywhere?
A tough call. If we go C++ we should have a plan to use the STL classes with our
concept of memory (allocator scope). I've started a short discussion last year,
but somebody found
11 matches
Mail list logo
