On Tue, Mar 06, 2007 at 11:46:33PM -0800, Steven Le wrote:
> Thanks. How can I register hf_foo_data?
Take a look at the sample dissector code in doc/README.developer between
the "Cut here" lines and section 1.6.
> I want to print out binary data.
Use FT_BYTES in the registration above.
> On t
Thanks. How can I register hf_foo_data? I want to print out binary data. On
the other hand, the length of data is altered each time the message is sent
.
tvb_get_length will get the length of current offset to end of payload, wont
it?
Steven
On 3/6/07, Jaap Keuter <[EMAIL PROTECTED]> wrote:
Hi
On Wed, Mar 07, 2007 at 12:25:22PM +0800, Jeff Morriss wrote:
> Given the volume of changes going into the trunk and the length of time
> it would likely take to parallelize Wireshark, I would think that a
> parallel trunk would get way too far out of sync to be useful.
Full ack. Past (long-time
Hi,
Oke, so how about reading the header and decide where to go from there.
Something crude like:
offset = 0
proto_tree_add_item(tree, hf_foo_header, tvb, offset, 1, FALSE);
header = tvb_get_guint8(tvb, offset);
offset++;
if ((header & 0xE0 == 0) || (header & 0xE0 == 0xE0)) {
proto_tree_add_it
Sebastien Tandel wrote:
>> As almost every dissector will be involved, the only realistic approach
>> in my eyes would be an approach I would call "blooming". The "changed"
>> dissectors will exist for a long time in parallel to the "old"
>> dissectors. The "blooming" approach means we'll have
Shehjar Tikoo wrote:
Comments and suggestions will be much appreciated. I'll be putting up
some documentation RSN.
Oops, forgot to diff the Makefile.common. See attached.
Also, for basic instructions to run the anonymizer, see this page:
http://www.gelato.unsw.edu.au/IA64wiki/NFSTrafficAnony
Thanks jaap, here is more information:
Header is 1byte and its format
7 6 5 4 3 2 1 0 bit
typeX
Messages is 20 bytes
Binary data is unknown
After getting the first 3 bits from header:
Format of this payload will depend on the first 3 bits of header (bit Type
field)
-
Guy Harris wrote:
> On Mar 6, 2007, at 4:00 PM, Shehjar Tikoo wrote:
>> Heres the first version of the NFS anonymizer as a tshark tap.
>>
>> http://www.gelato.unsw.edu.au/~shehjart/patches/nfs_anonymizer_tap.diff
> Wireshark doesn't support overwriting the contents of a tvbuff; it's
> read-only,
On Mar 6, 2007, at 4:22 PM, ronnie sahlberg wrote:
> Since this is so specialized, it might be better to make this into a
> plugin.
> There should be only very minor changes required to make it live
> down in
> ./plugins/nfsanonymizer.
>
> While plugins are usually used for PROTOCOLS there i
On Mar 6, 2007, at 4:00 PM, Shehjar Tikoo wrote:
> Heres the first version of the NFS anonymizer as a tshark tap.
>
> http://www.gelato.unsw.edu.au/~shehjart/patches/
> nfs_anonymizer_tap.diff
...
> +static int
> +anonymize_nfsdata(tvbuff_t *tvb, int offset)
> +{
> + guint8 *tvb_p
Since this is so specialized, it might be better to make this into a plugin.
There should be only very minor changes required to make it live down in
./plugins/nfsanonymizer.
While plugins are usually used for PROTOCOLS there is nothing that
prevents you from doing a "fake" protocol plugin that i
Hi All
Heres the first version of the NFS anonymizer as a tshark tap.
http://www.gelato.unsw.edu.au/~shehjart/patches/nfs_anonymizer_tap.diff
Its a huge 1900 line patch so I am willing to break it up into smaller
pieces but note that its all in one new file, so that might not be
necessary.
Her
Committed revision 20984.
Best regards
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Stig Bjørlykke
Skickat: den 6 mars 2007 21:32
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] [PATCH] packet-ber: dissect_unknown_ber fix
Hi.
Whe
Hi.
When dumping elements in a constructor in dissect_unknown_ber the
last element is not put in the correct subtree, because the while-
loop does not include the header length when checking for the end.
Attached a patch to fix this bug.
--
Stig Bjørlykke
packet-ber.patch.gz
Description
Hi all,
>> It was part of an effort to start refactoring the code so that it
>> would eventually become possible to multithread wireshark, but the
>> work required to implement everything required is just too massive to
>> be realistic.
>>
>>
>
> Well, my feeling about this is that this
Hi,
You'll have to provide a little more detail than this. What size are
header, message and data? Are they packed in a byte? format stuff like
that.
Thanx,
Jaap
On Tue, 6 Mar 2007, Steven Le wrote:
> I have to dissect this payload.
>
> Header | message | data
>
> After getting the first 3 bi
Hi All,
Last week I ran into bug 491 which describes the unexpected behaviour
of frame.time_delta. This filter is calculated as "Time delta since
previous displayed frame", where one could expect it to be calculated
as "Time delta since previous frame in the trace-file".
When you do a filter like
On Sat, Mar 03, 2007 at 07:44:32PM +0100, Sake Blok wrote:
>
> I hope this clears up the background of this patch. If not, feel
> free to ask me to clarify it some more :)
My patch has not been applied yet, is this because:
a) there is a question whether this functionality is wanted in wireshar
I have to dissect this payload.
Header | message | data
After getting the first 3 bits from header: 000 -> Header
010
-> Header|Message
001
-> Header|Bin
19 matches
Mail list logo
