Re: libPcap -- Dynamic Filters Question...

[Guy Harris <guy () netapp com>]

On Thu, Feb 06, 2003 at 04:41:31PM -0800, Cuzens, Jarrod wrote:
>       What I would like to be able to do is track this session by
> essentially adding a pcap filter (to a new instance of pcap) to monitor
> srcIP:srcPort and dstIP:dstPort for this new session (disregarding sequence
> numbers (I just need the naive case :) ) ) on the fly. This way pcap would
> now pass me up anything related to this session. Extending this idea a
> little further the original pcap instance would still detect new sessions
> and I would continue to add new rules to the session filter and remove them
> when either the session stales or I get a FIN.
>
>       Basically, what I am trying to get at is that I would like to be
> able to dynamically add a remove rules from a filter on the fly. I have read
> a few documents about BPF+ that seem to indicate that this is the direction
> for BPF+ (although I have also read documents that state the contrary).

I didn't see anything obvious about that in the BPF+ paper.

> Is there any functionality like this in libpcap?

Well, one could, in theory, generate a new filter and install that new
filter.

However:

        1) on platforms where filtering is done in user mode, and where
           more than one packet is delivered on a read/receive/whatever
           from the underlying kernel mechanism, the loop that processes
           packets in a buffer gets a pointer to the filter program into
           a local variable and uses that pointer, so that if the filter
           is changed in the middle of the loop by a callback routine,
           the loop will continue to use the old filter for all packets
           in the buffer (which means that it could be using a filter
           program that's in freed memory, which is Not Good);

        2) on packets where filtering is done in the kernel, setting a
           filter expression causes any packets buffered in the kernel
           to be flushed, so that if there are packets that would pass
           the old filter but not the new one, you don't see them.

1) is easy to fix.

2), however, would require kernel changes on BSD.  It wouldn't require
kernel changes on Linux, it would just require *removing* the change
that causes the buffered packets to be flushed - however, that change
was put in because people didn't want to see packets that wouldn't have
passed the new filter, so, for many people, removing that change would
reintroduce a bug that they wanted fixed.

Furthermore, although you can prevent packets that would have passed the
old filter but wouldn't have passed the new filter from being seen by
flushing the buffer, you can't retroactively un-filter-out packets that
would *not* have passed the old filter but *would* have passed the new
filter - but that's what you'd want, as your new filter would pass
*more* packets up, rather than passing *fewer* packets up.

There would need to be some way of specifying, on systems that do packet
filtering in the kernel, that, somehow, if a packet that matches a given
filter - or perhaps a given rule in a filter - is seen, the kernel
packet filtering code should, perhaps, temporarily buffer *all* packets
but not deliver *any* of them until a new filter is set, at which point
it should run all the buffered packets through the filter and deliver
the ones that pass.

That would, however, cause you to run the risk of overrunning the
buffer, as it would put *all* packets into the buffer.

It would, in theory, be possible to do that on most of the OSes running
on PC hardware, namely Windows (as the mechanism isn't built into
Windows, but is supplied by the open-source WinPcap add on), Linux (as
it's open-source), and the free-software BSDs (as they're open-source);
it'd also be possible, presumably, on MacOS X, as the part of Darwin
that includes BPF is open-source.

The other OSes on which libpcap currently supports in-kernel packet
filter, however, are closed-source (Digital UNIX, AIX when BPF is being
used), so you'd be out of luck on them.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe