ta using p_add_proto_data() appears to have worked correctly.
Thanks to you both for your help,
d
> -Original Message-
> From: David Arnold
> To: Developer support list for Wireshark
> Sent: Sun, Mar 10, 2013 1:32 pm
> Subject: Re: [Wireshark-dev] Dissector q
independent" and should just use the visited flag.
-Original Message-
From: David Arnold
To: Developer support list for Wireshark
Sent: Sun, Mar 10, 2013 1:32 pm
Subject: Re: [Wireshark-dev] Dissector question
On 10/03/2013, at 5:13 PM, Evan Huus wrote:
Hi Evan,
Thanks for your help
On Sun, Mar 10, 2013 at 1:24 PM, David Arnold wrote:
> On 10/03/2013, at 5:13 PM, Evan Huus wrote:
>
> Hi Evan,
>
> Thanks for your help.
>
> <...>
>
>> I'm not sure I follow this. Can't you simply store the most recent
>> sequence number in the conversation struct, and increment it for each
>> PD
On 10/03/2013, at 5:13 PM, Evan Huus wrote:
Hi Evan,
Thanks for your help.
<...>
> I'm not sure I follow this. Can't you simply store the most recent
> sequence number in the conversation struct, and increment it for each
> PDU received?
I tried to do this, and perhaps I just got it (slightly)
On Sun, Mar 10, 2013 at 12:56 AM, David Arnold wrote:
> Hi all,
>
> I'm writing a dissector for a TCP-based framing protocol which implements
> application-level sequence numbers by counting received messages. When a
> client logs into the server, the login acceptance packet from the server
>
Hi all,
I'm writing a dissector for a TCP-based framing protocol which implements
application-level sequence numbers by counting received messages. When a
client logs into the server, the login acceptance packet from the server
includes the number of the next packet to be delivered, and the cl
kfor...@nhhancocks.net wrote:
> I think I'm missing something pretty basic on dissectors around reusing
> subsets of a protocol vs. the need to enumerate everything in the hf[]
> array.
[...]
> and I'd just parse through field-by-field, however this gets incredibly
> unwieldy as the number of
Apologies if this came through twice...I didn't see it make it into a
digest.
I think I'm missing something pretty basic on dissectors around reusing
subsets of a protocol vs. the need to enumerate everything in the hf[]
array.
I can illustrate by a sample protocol foo; in pseduo-code:
enum {
hi ,
i've implemented a dissector in the development version of wireshark and it
worked .
when i placed the dissectors dill's in the release version , the dissector
failed .
i've debbuged it , and noticed that he function : *
**tcp_dissect_pdus*behaves differently between both version .
i am usin
Guy Harris wrote:
> Unfortunately, that doesn't handle the "Generator 1"/"Generator 2"/...
> issue.
>
> It might be useful to add new APIs that take an array index as an
> argument, and that add the array index value after the field name in
> the display representation of the item. (I thin
I
click on one "group" of those in the middle pane, will it highlight the proper
bytes in the bottom display
Sincerely,
John Jamulla
- Original Message -
From: "Stephen Fisher" <[EMAIL PROTECTED]>
To: "Developer support list for Wireshark"
Sent: Tues
On Feb 27, 2007, at 5:05 PM, Stephen Fisher wrote:
> You would typically use proto_tree_add_item() and define the bitmask
> as
> part of the hf[] field registration.
Unfortunately, that doesn't handle the "Generator 1"/"Generator 2"/...
issue.
It might be useful to add new APIs that take an
On Sat, Feb 24, 2007 at 11:04:27AM -0500, John Jamulla wrote:
> I have some data in my own protocol that is really a set of 512, 2
> byte bit fields, and I want to display something like:
>
> Generator 1 Fielda
> Generator 1 Fieldb
> Generator 1 Fieldc
> Generator 1 Fieldd
> Generator 2
Hello,
I have a working dissector now, and have figured out many part of how to
display individual values, fields, strings, etc. I have some subtrees as
well, but...
I have some data in my own protocol that is really a set of 512, 2 byte bit
fields, and I want to display something like:
Generato
14 matches
Mail list logo
