BPF code generation for radiotap

BPF code generation for radiotap

[David Young]

Can I help someone with BPF know-how to write a radiotap code generator?
It would be great if we could use BPF to filter out packets with, say,
an RSSI below a certain threshold.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: BPF code generation for radiotap

[Guy Harris]

David Young wrote:
> Can I help someone with BPF know-how to write a radiotap code generator?
> It would be great if we could use BPF to filter out packets with, say,
> an RSSI below a certain threshold.

That will be possible only if the RSSI can be found without a loop, or 
if you're willing to have all the filtering done in userland.  The 
kernel BPF interpreter doesn't support backwards branches; the userland 
one does, to support chasing IPv6 protocol headers, but backward 
branches completely screw up the optimizer (so it gets turned off).

Re: BPF code generation for radiotap

[David Young]

On Fri, May 11, 2007 at 04:49:56PM -0700, Guy Harris wrote:
> David Young wrote:
> >Can I help someone with BPF know-how to write a radiotap code generator?
> >It would be great if we could use BPF to filter out packets with, say,
> >an RSSI below a certain threshold.
> 
> That will be possible only if the RSSI can be found without a loop, or 
> if you're willing to have all the filtering done in userland.  The 

Right now, all radiotap fields can be found without a loop.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: BPF code generation for radiotap

[Guy Harris]

David Young wrote:

> Right now, all radiotap fields can be found without a loop.

I.e., can be found with a completely unrolled loop.

I might have to work on the optimizer to handle code such as

	if (field XXX is present)
		add AAA to the offset into the packet;
	if (field YYY is present)
		add BBB to the offset into the packet;

etc. - I remember seeing problems such as that when trying to handle 
either the token ring header (which is variable-length, with source 
routing stuff) or the 802.11 header in full generality (some frames have 
4 MAC addresses - those are frames being sent from one access point to 
another access point, right?).

Re: BPF code generation for radiotap

[David Young]

On Fri, May 11, 2007 at 06:50:59PM -0700, Guy Harris wrote:
> David Young wrote:
> 
> >Right now, all radiotap fields can be found without a loop.
> 
> I.e., can be found with a completely unrolled loop.

Correct.

*snip snip*
> or the 802.11 header in full generality (some frames have 
> 4 MAC addresses - those are frames being sent from one access point to 
> another access point, right?).

Right.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: BPF code generation for radiotap

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Fri, 2007-05-11 at 18:50 -0700, Guy Harris wrote:

> I might have to work on the optimizer to handle code such as
> 
> 	if (field XXX is present)
> 		add AAA to the offset into the packet;
> 	if (field YYY is present)
> 		add BBB to the offset into the packet;

I don't think that is completely correct, the radiotap header says that
fields are naturally aligned and this code doesn't handle that. In many
scenarios alignment will not be needed but I wouldn't want to rely on
that.

It'd have to look something like

if (field XXX is present)
	add A-1 to the offset
	mask offset with ~A
	/* do whatever with field XXX */
	add AAA to the offset into the packet
...
where A is the alignment of the field XXX.

This should be correct, but I can't seem to find an authoritative
statement on how exactly alignment is to be treated and whether it is
with respect to the beginning of the header (as it must be!)

Out of curiosity; what could be optimised with above code, and what does
that optimiser do?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]