[Evan Huus <eapache@xxxxxxxxx>]

On Sun, Nov 4, 2012 at 3:34 AM, Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx> wrote:

On Sat, Nov 03, 2012 at 07:55:51PM -0400, Evan Huus wrote:
> On Mon, Oct 8, 2012 at 7:12 AM, Jakub Zawadzki
> <darkjames-ws@xxxxxxxxxxxx> wrote:

> > +  if (cf->count < frames_count && framenum <= cf->count) {
> > +    /* XXX, what we should do when new frames were received during rescaning but user clicked abort?
> > +     *   - call packet_list_append() for all new frames?
> > +     *   - just warn user?
> > +     */
> > +  }
>
> Just looking at this for the first time, but shouldn't the first part
> of the conditional be "cf->count > frames_count"?

Yes, thanks.

> To answer the actual question though - I don't think we should do
> anything. Existing frames that we haven't processed yet are simply not
> displayed when the user hits abort, so I think it's perfectly sane for
> us to not display any new frames in that case either.

But if we don't call packet_list_append() on them, these packets won't
show up on packet list, even if user refilter again and this time he/she
won't abort the process.

Ah, right. In this case (based only on reading the code) I believe it would be sane to set fdata->flags.passed_dfilter to FALSE on all the new frames and then call packet_list_append_record() directly. That should add them to the list without touching any of the GUI stuff.

On the other hand - I'm not sure if they'll have been dissected by this point. It might be necessary to call add_packet_to_packet_list() instead, so that they get dissected even if they're hidden. It would have to be called with some faked dfilter_t that returns false on all packets - does such a thing exist?

You're right, this is a more complicated question that it first appears to be.

Evan