Hi All
I am the current maintainer of the protobuf plugin for wireshark
http://code.google.com/p/protobuf-wireshark/
I have made some significant changes in latest version which make it
general enough to parse and register protobuf messages at runtime as opposed
to having to generate a new dissect
2011/4/30 Jeff Morriss :
>>
>> Can anybody please explain the purpose of subtree array (ett_...)?
>>
>> I don't get why should i have several different etts in my dissector's
>> code, while there is no information assotiated with these integers.
>
> Each ett_ stores information about whether the pa
Max wrote:
Can anybody please explain the purpose of subtree array (ett_...)?
I don't get why should i have several different etts in my dissector's
code, while there is no information assotiated with these integers.
Each ett_ stores information about whether the particular subtree
created us
On Sat, Apr 30, 2011 at 12:50:33AM +0400, Max wrote:
> Can anybody please explain the purpose of subtree array (ett_...)?
>
> I don't get why should i have several different etts in my dissector's
> code, while there is no information assotiated with these integers.
My understanding is that Wir
Can anybody please explain the purpose of subtree array (ett_...)?
I don't get why should i have several different etts in my dissector's
code, while there is no information assotiated with these integers.
--
Max
___
Sent v
Jeff, thank you for you reply.
2011/4/29 Jeff Morriss :
> Max wrote:
>>
>> For now I use "global" conversation state for dissection if the packet
>> has no proto data associated with it, otherwise I use state from
>> associated data which
>> stores the state before first packet dissection was done
On Fri, Apr 29, 2011 at 06:59:45PM +0400, Max wrote:
> For now I use "global" conversation state for dissection if the packet
> has no proto data associated with it, otherwise I use state from
> associated data which stores the state before first packet dissection
> was done. Am I right doing s
On Fri, Apr 29, 2011 at 02:30:37PM -0400, Jeff Morriss wrote:
> Jeff Morriss wrote:
> > Done in rev 36954.
>
> cmake should be done in rev 36956.
Thanks!
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wi
Jeff Morriss wrote:
Jakub Zawadzki wrote:
Hi,
On Fri, Apr 29, 2011 at 10:06:23AM +0200, Anders Broman wrote:
It's not a big problem on Windows
Ok, but we need at least to define HAVE_INFLATEPRIME (and we can
remove HAVE_GZCLEARERR).
If you know how I'd be grateful ;)
Done in rev 36954.
Jakub Zawadzki wrote:
Hi,
On Fri, Apr 29, 2011 at 10:06:23AM +0200, Anders Broman wrote:
It's not a big problem on Windows
Ok, but we need at least to define HAVE_INFLATEPRIME (and we can remove
HAVE_GZCLEARERR).
If you know how I'd be grateful ;)
Done in rev 36954.
Still to do: cmake.
__
Max wrote:
Hi, I'm new to the list and to the wireshark development. I want to
ask you a couple of questions, answers for which I haven't found in
the docs and
on the Internet.
I'm writing a dissector plugin which does dissection of some
proprietary protocol which uses encryption and optionally
Ankith Agarwal wrote:
Hi
I have written a dissector for IEEE 802.21 MIH(Media Independent
Handover) protocol. Can this be put in the epan dissectors list in
wireshark, or as a plugin?
(I have tested this code for the coding style and the working of the
dissection also is tested.)
The preferen
Jeff Morriss wrote:
On 03/07/2011 10:54 AM, Gerald wrote:
--- On *Mon, 3/7/11, Jeff Morriss //* wrote:
From: Jeff Morriss
Subject: Re: [Wireshark-dev] TCP dissector handling TCP Fast
Retransmit
To: "Developer support list for Wireshark"
Date: Monday, March 7, 2011, 10:09
On Fri, 29 Apr 2011 13:36 +0200, "Jakub Zawadzki"
wrote:
> Btw. from zlib page:
> Version 1.2.3 (July 2005) eliminates potential security vulnerabilities
> in zlib 1.2.1 and 1.2.2, so all users of those versions should
> ***upgrade immediately***
>
> So maybe it's good (read: safer for us
On 4/29/2011 12:42 AM, subha sree wrote:
Hi,
I'm doing compilation for windows with wiresharkk code base. In my lab
machine there is no internet connection. While i'm executing "nmake -f
Makefile.nmake setup" command which is trying to download libraries from the
internet. So i manually commen
Hi, I'm new to the list and to the wireshark development. I want to
ask you a couple of questions, answers for which I haven't found in
the docs and
on the Internet.
I'm writing a dissector plugin which does dissection of some
proprietary protocol which uses encryption and optionally compression.
Hi,
I think it's enough to manually put the files in the folder for it to work.
regards
Anders
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of subha sree
Sent: den 29 april 2011 06:42
To: wireshark-dev@wireshark.
Hi,
I'm doing compilation for windows with wiresharkk code base. In my lab
machine there is no internet connection. While i'm executing "nmake -f
Makefile.nmake setup" command which is trying to download libraries from the
internet. So i manually commented that lines in Makefile.nmake file and i
Hi
I have written a dissector for IEEE 802.21 MIH(Media Independent
Handover) protocol. Can this be put in the epan dissectors list in
wireshark, or as a plugin?
(I have tested this code for the coding style and the working of the
dissection also is tested.)
Regards
Ankith
--
This message ha
Hi,
On Fri, Apr 29, 2011 at 10:06:23AM +0200, Anders Broman wrote:
> It's not a big problem on Windows
Ok, but we need at least to define HAVE_INFLATEPRIME (and we can remove
HAVE_GZCLEARERR).
If you know how I'd be grateful ;)
On Fri, Apr 29, 2011 at 12:55:34AM -0700, Guy Harris wrote:
> On Apr 29, 2011, at 12:52 AM, Jakub Zawadzki wrote:
>
> > Actually we still can do transparent access, but only when BLOCK is not
> > inside
> > middle of byte.
>
> Does that mean "we can still do fast random access to all gzipped fil
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jakub Zawadzki
Sent: den 29 april 2011 09:52
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Compilation error Red Hat 3.4.3-9.EL4
On Thu, Apr 28
On Apr 29, 2011, at 12:52 AM, Jakub Zawadzki wrote:
> Actually we still can do transparent access, but only when BLOCK is not inside
> middle of byte.
Does that mean "we can still do fast random access to all gzipped files, but we
have to change the way we choose when to start a new block", or
On Thu, Apr 28, 2011 at 11:24:08PM -0700, Guy Harris wrote:
> I wouldn't to it by checking for a particular version, though -
> I'd just check for inflatePrime() and, if it's not present, don't build in
> the "transparent access to gzipped files" support.
Actually we still can do transparent acc
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 29 april 2011 08:24
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Compilation error Red Hat 3.4.3-9.EL4
On Apr 28, 2011,
25 matches
Mail list logo
