[Andriy Beregovenko <jet@xxxxxxxxxxx>]

Hi Jaap,

On Mon, Dec 19, 2011 at 03:42:05PM +0100, Jaap Keuter wrote:
> On 2011-12-18 14:17, Andriy Beregovenko wrote:
> 
> >Hi,
> >
> >Now i'm writing dissector for some kind of traffic. I'm already
> >got basic
> >knowledge in dissector writing, so first primitive version was
> >already done.
> >But now, when I try to complete fully featured version of
> >dissector I got
> >many trobles with routine. So I'm looking for good advice from
> >experienced
> >developers.
> >First of all, let me describe my traffic a little:
> >- most part of traffic is crypted(with rc4)+compressed(with mppc),
> >not
> >crypted is only few start frames;
> >- few start frames(or packets) have rc4 key inside itself;
> >
> >So I do next. When I dissect traffic, i looking for first frames,
> >reads rc4
> >keys from it and put it into static variable, so all other
> >frames(packets)
> >now can be correct decrypted. But I need to decompress(with MPPC),
> >and here
> >I got my troubles, cause I can decompress only 'linearly' incoming
> >data
> >(this is MPPC specific feature), so I'm stuck here. Please, point
> >me to
> >right way to implement such type of dissector.
> >-- Best regards, Andriy 0xBDDBDAE3
> 
> Hi,
> 
> Two things to be aware of:
> 1. Using statics to store dissection related data (key material in
> your case) is bad style. Why? Image what happens when there are two
> streams in your capture. Which key are you going to store?
Yes, I understand this issue, but I do not care about this, cause at this
time it does not matter. While develop I use only one session that stored 
in pcap-file.

> 2. You have to be aware that Wireshark accesses frames in random
> order all all the time. Only the first pass is sequential.
Oh yes, this is my main problem. Because I can't proccess data from frame
separately from the rest of the data, that comes before.
 
> Because of 1. there is the notion of 'conversations'. Per
> conversation you
> can store protocol related data (your key). Every time you are asked to
> dissect a packet (remember, this can be in random order!), you have
> access to
> this stored data, in your conversation data.
Thanks a lot, btw I already implement something like this that based on 
'key' - 'value', there key is compilation of src/dst ipport, and 'value' 
is session related data.

> Because of 2. you can setup your conversation data (your key) on the
> first
> pass (see PINFO_FD_VISITED macro) and use it later on.
Super, I implement same thing and name is as 'caching'. I noticed that when
I scroll packets list in wireshark window, it pass any new packet that will
be shown in window through dissector. And I do some kind of caching: i store
all decrypted and decompressed packets in dynamic allocated structure(linked
list) and all next calls check in this cache 'is frame number N already
dissected?'. If not - dissect it and put into cache.

Basicly this was a main question, what wireshark way better for such type of
packets processing. And now question is 'Is my way right ?'.

> Read through doc/README.developer for these subjects.
> 
> Thanks,
> Jaap
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

-- 
Best regards,
Andriy
0xBDDBDAE3

Attachment: signature.asc
Description: Digital signature