Re: libPcap -- Dynamic Filters Question...

[Ryan Mooney <ryan () pcslink com>]

What about if you did it as a threaded program and spawned new threads
to match the new sessions.  This would likely require some cleverness
to get decent performance (thread pre-spawning, maybe some sort of session
grouping so that if N sessions arrive in close sucession you could
bundle them into one thread).  A simular alternative would be to hack
go into a big select loop on N bpf's (which really end up being just
filehandles) and pre-opening new ones as nessecary (do non blocking
opens, so you always have a spare bpf or two floating around...).
Ugly - yes, complicated - probably.

On Thu, Feb 06, 2003 at 05:48:16PM -0800, Guy Harris wrote:
> 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

-- 
> -=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-<
Ryan Mooney                                      ryan () pcslink com 
<-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=-> 
-
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