[PATCH] ng_tag - new netgraph node,
please test (L7 filtering possibility)
uspoerlein at gmail.com
Mon Jun 12 19:51:40 UTC 2006
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):
> 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" will be tcpdump's "ether". 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:
> 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!
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20060612/7e7282ac/attachment.pgp
More information about the freebsd-net