Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)

Vadim Goncharov wrote:
I hope that my explanation was helpful enough to understand :) Also, if you will be using
7.0, include BPF_JITTER in your kernel config as this will enable native code-compiling for
bpf and ng_bpf - this will speed things up.

Am I the only one, that thinks BPF_JITTER is a stupid name? It suggest
you add or enable jitter for the packet flow. No one wants jitter! It
sucks. Why isn't it called simply BPF_JIT? Everyone knows what JIT
stands for, JITTER on the other hand is to be avoided.

P.S. Here is quick-and-dirty primer how to convert ipp2p functions to ng_bpf(4) input
expression for tcpdump(1). Go to http://www.ipp2p.org/ and download source, unpack and open
file pt_ipp2p.c and find function for your P2P type, let it be BitTorrent for our example. So
look (I've formatted that bad Linux code a little to be a more style(9)'ish):
[snip]
We can give 1, 2 or 4 bytes to tcpdump for comarison at one time. The "payload" variable in
the source points to beginning of data in TCP packet. Remember from man ng_tag that tcpdump
assumes packets to have 14-byte Ethernet header for it's arrays like "tcp[]", but packets
come from ipfw to ng_bpf without this header, and that affects our offset calculations. So we
must give offsets from very beginning of packets, which is done through "ether[]" tcpdump's
prime, and parse headers manually. Let's assume (for simplicity and speed), however, that IP
and TCP headers have no any options and thus always have length 20 bytes each, then ipp2p's
"payload[0]" will be tcpdump's "ether[40]". Also, let's assume that ipfw checked packet len
for us so we don't do that in netgraph too.

Then, we simply take hex bytes in order hd(1) told us, as this is network byte order also,
and write them as tcpdump expressions (remember that first string ("...protocol") actually
have 0x13 prepended to it). So, we write follow in ng_bpf(4) script:
[snip]
Note the last OR block in expression - this is translation of that "not sure" checking
request packets. I've explicitly written packet length - plen=17 + 20 byte IP header len + 20
byte TCP header len, check at offset 2 in IP header, according to RFC 791. Construction
"get_u32 == __constant_htonl()" means comparing 4-byte values at given offset.

Great stuff, this should make it somewhere into /usr/share/examples!


Ulrich Spoerlein
--
PGP Key ID: 20FEE9DD Encrypted mail welcome!
Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD
Which is worse: ignorance or apathy?
Don't know. Don't care.

Attachment: pgpkkavFHiUzM.pgp
Description: PGP signature

Relevant Pages