[Evan Huus <eapache@xxxxxxxxx>]

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@xxxxxxxxx> wrote:

On Sun, Jun 22, 2014 at 7:34 PM, Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> 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?