netdev level filtering? perhaps pushing socket filters down?

netdev level filtering? perhaps pushing socket filters down?

[Johannes Berg]

Hi all,

Occasionally - we just had another case - people want to hook into
packets received and processed by the mac80211 stack, but because they
don't need all of them (e.g. not data packets), even adding a monitor
interface and bringing it up has too high a cost because SKBs need to
be prepared to send them to the monitor interface, even if no socket is
consuming them.

Ideally, we'd be able to detect that there are filter programs attached
to the socket(s) that are looking at the frames coming in on the
monitor interface, and we could somehow magically run those before we
create a new SKB.
One problem here is that we wouldn't really want to prepare all the
radiotap header just to throw it away, so we'd have to be able to
analyse the filter program to make sure it doesn't access anything but
the radiotap header length, and that only in order to jump over it.
That seems ... difficult, but we don't even know the header length -
although we could fudge that and make a very long constant-size header,
which might make it possible to do such analysis, or handle it by
trapping on such access. But it seems rather difficult to implement
this.

The next best thing would be to install a filter program on the virtual
monitor *interface* (netdev), but say that it doesn't get frames with
radiotap, but pure 802.11 frames. We already have those in SKB format
at this point, so it'd be simple to run such a program and only pass
the SKB to the monitor netdev's RX when the program asked to do that.

This now seems a bit like XDP, but for XDP this header difference
doesn't seem appropriate either.

Anyone have any other thoughts?

Thanks,
johannes

Re: netdev level filtering? perhaps pushing socket filters down?

[Ben Greear]

On 03/16/2017 03:33 PM, Johannes Berg wrote:
> Hi all,
>
> Occasionally - we just had another case - people want to hook into
> packets received and processed by the mac80211 stack, but because they
> don't need all of them (e.g. not data packets), even adding a monitor
> interface and bringing it up has too high a cost because SKBs need to
> be prepared to send them to the monitor interface, even if no socket is
> consuming them.
>
> Ideally, we'd be able to detect that there are filter programs attached
> to the socket(s) that are looking at the frames coming in on the
> monitor interface, and we could somehow magically run those before we
> create a new SKB.
> One problem here is that we wouldn't really want to prepare all the
> radiotap header just to throw it away, so we'd have to be able to
> analyse the filter program to make sure it doesn't access anything but
> the radiotap header length, and that only in order to jump over it.
> That seems ... difficult, but we don't even know the header length -
> although we could fudge that and make a very long constant-size header,
> which might make it possible to do such analysis, or handle it by
> trapping on such access. But it seems rather difficult to implement
> this.
>
> The next best thing would be to install a filter program on the virtual
> monitor *interface* (netdev), but say that it doesn't get frames with
> radiotap, but pure 802.11 frames. We already have those in SKB format
> at this point, so it'd be simple to run such a program and only pass
> the SKB to the monitor netdev's RX when the program asked to do that.
>
> This now seems a bit like XDP, but for XDP this header difference
> doesn't seem appropriate either.
>
> Anyone have any other thoughts?

Attach at just above the driver, before it ever gets to stations/vdevs,
and ignore radiotap headers and/or add special processing for metadata like
rx-info?

Thanks,
Ben

>
> Thanks,
> johannes
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: netdev level filtering? perhaps pushing socket filters down?

[Johannes Berg]

> Attach at just above the driver, before it ever gets to
> stations/vdevs, and ignore radiotap headers and/or add special
> processing for metadata like rx-info?

That'd be a different feature, perhaps more like XDP.

There anyway is no radiotap header at that point, but not changing
whether or not it makes it to other virtual interfaces is actually not
what we're looking for here at all.

johannes