Re: Stateless Dissection

[Evan Huus <eapache () gmail com>]

I tried a different approach in [1]. This simply resets state every time
the ringbuffer cycles. This has the advantage that the only state,
reassembly etc that you won't see is the same stuff you won't see when
opening the files individually after the fact.

Thoughts? Potential gotchas? Should we default to this (if ringbuffering is
enabled) or should it be an additional flag? If so, which flag?

Evan

[1] https://code.wireshark.org/review/2669


On Sun, Jun 22, 2014 at 8:47 PM, Evan Huus <eapache () gmail com> wrote:

> On Sun, Jun 22, 2014 at 7:34 PM, Jakub Zawadzki <darkjames-ws () darkjames pl
> > wrote:
>
> > On Sun, Jun 22, 2014 at 05:45:45PM -0400, Evan Huus wrote:
> > > On Sun, Jun 22, 2014 at 5:25 PM, Jakub Zawadzki <
> > darkjames-ws () darkjames pl>
> > > wrote:
> > >
> > > > On Sun, Jun 22, 2014 at 05:07:19PM -0400, Evan Huus wrote:
> > > > > The implementation is a bit of a hack in that stateless dissection
> > still
> > > > > does all the stateful work, it just throws it away after each
> > packet (so
> > > > > stateless is actually slightly slower than stateful) but it seems
> > to work
> > > > > in my simple tests.
> > > >
> > > > Great, but I'd like to see also something working for *given* frame
> > number,
> > > > this would also fix issues with -R (like remove all conversations,
> > > > reassemblies created by *given* frame number).
> > >
> > > I don't think I understand?
> >
> > If you have the -R "somefilter" and later you drop this frame, frame
> > number will be reused by
> > next one, and this really confuses the libwireshark.
> >
> > It'd be really nice to have posibility to 'undo' operations done after
> > dissecting current frame.
>
> Ah, ya, but that is much harder than what I'm doing here. You'd need to
> touch every dissector that stores state :(
>
> Would it be better to increment frame numbers even when a packet doesn't
> pass the -R filter? Or does that cause its own problems when e.g. iterating
> through the frames a second time?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe