Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jun 2006 20:57:51 +0200
From:      Ulrich Spoerlein <uspoerlein@gmail.com>
To:        Vadim Goncharov <vadim_nuclight@mail.ru>
Cc:        freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
Message-ID:  <20060612185751.GB1226@roadrunner.aventurien.local>
In-Reply-To: <opta09vodb17d6mn@nuclight.avtf.net>
References:  <optax2g7jq4fjv08@nuclight.avtf.net> <70e8236f0606110836j38f7ca33wa3058eaecf386fb5@mail.gmail.com> <optazz26kn17d6mn@nuclight.avtf.net> <d3ea75b30606111534q337aa27aj87baa1f20550ac1c@mail.gmail.com> <opta09vodb17d6mn@nuclight.avtf.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--Yylu36WmvOXNoKYn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Vadim Goncharov wrote:
> I hope that my explanation was helpful enough to understand :) Also, if y=
ou will be using=20
> 7.0, include BPF_JITTER in your kernel config as this will enable native =
code-compiling for=20
> 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=20
> expression for tcpdump(1). Go to http://www.ipp2p.org/ and download sourc=
e, unpack and open=20
> file pt_ipp2p.c and find function for your P2P type, let it be BitTorrent=
 for our example. So=20
> look (I've formatted that bad Linux code a little to be a more style(9)'i=
sh):
> [snip]
> We can give 1, 2 or 4 bytes to tcpdump for comarison at one time. The "pa=
yload" variable in=20
> the source points to beginning of data in TCP packet. Remember from man n=
g_tag that tcpdump=20
> assumes packets to have 14-byte Ethernet header for it's arrays like "tcp=
[]", but packets=20
> come from ipfw to ng_bpf without this header, and that affects our offset=
 calculations. So we=20
> must give offsets from very beginning of packets, which is done through "=
ether[]" tcpdump's=20
> prime, and parse headers manually. Let's assume (for simplicity and speed=
), however, that IP=20
> and TCP headers have no any options and thus always have length 20 bytes =
each, then ipp2p's=20
> "payload[0]" will be tcpdump's "ether[40]". Also, let's assume that ipfw =
checked packet len=20
> for us so we don't do that in netgraph too.
>=20
> Then, we simply take hex bytes in order hd(1) told us, as this is network=
 byte order also,=20
> and write them as tcpdump expressions (remember that first string ("...pr=
otocol") actually=20
> 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 s=
ure" checking=20
> request packets. I've explicitly written packet length - plen=3D17 + 20 b=
yte IP header len + 20=20
> byte TCP header len, check at offset 2 in IP header, according to RFC 791=
=2E Construction=20
> "get_u32 =3D=3D __constant_htonl()" means comparing 4-byte values at give=
n offset.

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


Ulrich Spoerlein
--=20
 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.

--Yylu36WmvOXNoKYn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEjbkv524iJyD+6d0RAsCmAJ9TnrhmRItXr/duWMSv2sIkdq6NVgCgmA9S
EWI/jDS2ECluq4ww7LT7k6I=
=YXjO
-----END PGP SIGNATURE-----

--Yylu36WmvOXNoKYn--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060612185751.GB1226>