Re: [PATCH 0/4] Try #5: Radiotap on Monitor Mode interfaces for rx and tx

[Johannes Berg <johannes@sipsolutions.net>]

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

On Fri, 2007-03-23 at 08:57 +0000, Andy Green wrote:

> $ cd wireless-dev
> $ grep cfg80211 Documentation/* -R
> 
> As a Johnny-come-lately noob, how should I find out that cfg80211 either 
> exists or how it works?  Far from some kind of turf war initiating 
> gauntlet throwing, I was unaware cfg80211 was an option.

Yep, my mistake. I blame lack of time and cooperation, nobody but me
seems to be actually interested in working on cfg80211.

> My interest is being able to inject broadcast packets from userspace 
> with fine control over how it goes out.  I have now tried several ways 
> to get that to happen with varying success, patching drivers in the old 
> stack (worked but impractical for wide uptake), using the management 
> interface in the new stack (works but it is heading towards deprecation 
> and did not allow rate control) and finally the Monitor mode injection 
> (works perfectly but requires to convince you guys to include it).

Yep, I know.

> send()ing packets back up a Monitor Mode interface with the same 
> radiotap semantics as the came out of it with is the most natural and 
> portable (libpcap pcap_inject() just works with it on the same network 
> interface as it can capture on) way to do injection from a usermode and 
> architectural standpoint.

Right, and I'm not saying it doesn't make sense. I'm just trying to say
that before we add this interface we really need to figure out whether
it's feasible that this interface replaces all the wext/prism ioctl foo.

> I don't understand why Monitor Mode injection needs to fly under the 
> cfg80211 flag.  It seems to belong to mac80211 code and would continue 
> to work if cfg80211 was disabled.  Can you explain a bit more why it 
> logically belongs in that category?

Because of the userspace MLME that cfg80211 needs to support. At the
second wireless summit in London we have decided that the userspace MLME
should be transparent to users in that they still simply use nl80211 and
the kernel forwards the requests to the userspace MLME and also forwards
the responses. Therefore, most of the userspace MLME handling needs to
live in cfg80211, which makes cfg80211 also the logical point to define
injection at since the userspace MLME requires it.

johannes

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