Re: About pcap rules

[Gregor Maier <gregor () endace com>]

> If you're willing to dive below the libpcap interface and generate a custom BPF program, you may be able to 
> distinguish subrules, since the final result is actually not just "matches" or "doesn't match" but rather how many 
> bytes to capture, from 0 to 64K.

bpf_filter() in userspace might help here, since it directly returns the
 result from the BPF machine.

> If you know that all traffic of interest will be at least say 40 bytes you can have a BPF program that captures 38 
> bytes for one subrule and 39 bytes for another. This won't work, obviously, if you need to capture the entire packet, 
> or if packet lengths shorter than your BPF program returns are observed. It's also a bit tricky to do this coding, 
> and you may want to rely on the Linux "any" interface so that a single BPF program would work regardless of the 
> actual NIC interface type. (if you are using Linux).
>
> You can use tcpdump -d to see the BPF programs generated from pcap expressions, which helps, but this definitely 
> qualifies as a very advanced libpcap hack, and unless the performance gains will be significant, this approach is 
> probably unwise to use. I myself have considered this for a particular application, but have never actually 
> implemented it.

There's a bpfa (BPF Assembler) which one can use to generate BPF
programs from an assembly language.

Have a look at: http://www.bigw.org/~jcriswel/portfolio.html
The output is C Code that defines a bpf_prog struture with the BPF
instructions. I wrote a patch once that directly converted the assemlby
code to a bpf_prog struct. If you are interested I'll see if I can find
the patch again.


cu
Gregor
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.