Re: [RFC] design discussion: Collecting information for (non-peer) stations

From: Antonio Quartulli <antonio@open-mesh.com>
To: Felix Fietkau <nbd@openwrt.org>
Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Thomas Pedersen <thomas@cozybit.com>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
	Marek Lindner <marek@open-mesh.com>,
	Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Subject: Re: [RFC] design discussion: Collecting information for (non-peer) stations
Date: Fri, 22 Feb 2013 17:36:44 +0100	[thread overview]
Message-ID: <20130222163643.GB3757@open-mesh.com> (raw)
In-Reply-To: <51279AFA.3000608@openwrt.org>

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

On Fri, Feb 22, 2013 at 08:21:14AM -0800, Felix Fietkau wrote:
> Hi,
> 
> Since this is a rare special case, I think it really does not belong
> into the mac80211 data path. How about creating a monitor mode device
> and claiming it from within the kernel in your own module via rx_handler
> (the same mechanism that the bridge code uses to hook into the data path
> of a normal net_device). You can extract relevant information from the
> radiotap headers.

I think this would increase the complexity given the fact that each and every
packet needs to be encapsulated into the radiotap header..
Then, most of the information that people wants to grab does not appear in
such header.

Other than that, by hooking into the mac80211 rx_path, in an early point, packets can
then be dropped as usual (all those packets not going to this device), while
with this monitor-like solution all of them have to be carried up to the virtual
interface.

Imho this introduces a not negligible complexity that it is better to avoid.

And what about 802.11s? I don't think this is a good solution for them..

Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]