Re: Multiple pcap filters on interface

[Fabian Schneider <schneifa () net in tum de>]

Hi Jim,

As the limitation really is in the kernel, and all your approaches turn 
out not to work as you expect you might want to consider other 
possibilities. E.g. it might be fairly easy to do something like you 
suggested via either in kernel firewalling solution (although i am not 
sure if those would actively send packets) or it might be worth taking a 
look at "click"[1] and writing a small click programm/module which can run 
in kernel (at least) on Linux boxes.

As you mentioned enterprise solution you might need to deal with a huge 
set of connections, therefore maybe some advice regarding the performance 
of the proposed solutions:

1) As you already mentioned this can easily get a bottleneck on commodity 
   hardware in Gigabit or faster environments. Maybe it would be worth 
   considering specialised hardware (e.g. I know that Endace DAG card 
   would be capable of doing want you what, although not out-of-the-box. 
   You would need a custom solution, which is possible with Endace).

2) I would not neccesarily say that the bpf filter expression is the 
   limiting factor, but again and again we experience short periods of no 
   packet being delivered to the pcap application or even drops when 
   changing the bpf expressions. Maybe this would not be a show stopper
   for your setting, if you do not care about few seconds out-of-order.

3) I would definitively not advise this solution as performance wise this 
   can be more harmful than solution 1. The problem is that due to the 
   increased neccessity of user space - kernel context changes the 
   performance might drop with to many capturing applications in parallel. 
   If you want to use this approach i would recommend Linux, as (Free)BSD 
   sets up a kernel buffer for every capturing application, where as Linux 
   has one big buffer for all packets and uses reference counting to 
   delete packets. (At least for me for the task at hand Linux looks more 
   suitable)

And yes, the 'one filter per interface per process' policy cannot be 
overcome with current OSes.

   best
   Fabian

[1] http://read.cs.ucla.edu/click/

-- 
Fabian Schneider (Dipl. Inf.), An-Institut Deutsche Telekom Laboratories
Technische Universitaet Berlin, Fakultaet IV -- E-Technik und Informatik
address: Sekr. TEL 4, Ernst-Reuter-Platz 7, 10587 Berlin
e-mail: fabian () net in tum de, WWW: http://www.net.in.tum.de/~schneifa
phone: +49 30 8353 - 58513, mobile: +49 179 242 76 71

On Tue, 7 Oct 2008, Jim Mellander wrote:

> Hi:
>
> I've working on a TCP connection-killer daemon that will receive
> requests of the following type:
>
> 'kill all connections between host x & host y'
>
> and craft response packets based on received packets.
>
> Of course, it will have a mechanism for removing such requests from its
> active list.
>
> There are a number of programs (tcpkill, couic) which take pcap
> expressions and send RST's in response to packets which match, but they
> are too limited for my purposes - I'm trying to develop an
> enterprise-capable tool.
>
> I've thought of several mechanisms to program this:
>
> 1. A master pcap filter of 'tcp', which would hoist all tcp packets to
> the user-level, then inspect IP's for match, either by direct packet
> inspection or by compiled pcap expressions in userland - maybe zero-copy
> bpf would help here.
>
> 2. Incrementally build a pcap filter 'tcp and ((host a and host b) or
> (host c and host d))' ... etc. and apply to interface - my problem with
> this approach is the limited number of host pairs this would be able to
> accommodate.
>
> 3. Have a manager program which forks off as needed separate processes
> to handle the requests individually.
>
> All of the above are attempts to overcome the 'one filter per interface
> per process' model that I believe libpcap imposes - or am I wrong?  Is
> there something I've overlooked?
>
> Any advice welcome - thanks in advance.
>
> -- 
> Jim Mellander
> Incident Response Manager
> Computer Protection Program
> Lawrence Berkeley National Laboratory
> (510) 486-7204
>
> The reason you are having computer problems is:
>
> Internet outage
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.