Johannes Berg wrote:
On Tue, 2007-03-20 at 10:39 +0000, andy@xxxxxxxxxxx wrote:
For injecting packets, the you issue a packet using libpcap or a SOCK_PACKET
socket down an interface to the wireless device that is in Monitor Mode.
Ok so people don't want to have this in cfg80211, all the better for me
since it's less work.
$ 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.
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).
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.
I wouldn't say it is the "best" way to push the weirdo wext/prism Ioctls
out of the stack, I don't know enough about the details of it, but I
don't think this and the cfg80211 methods need to be in conflict. In a
real sense you can look at this patchset as intending to max out the
promise of libpcap to usermode. Sine they then have enough tools, if
someone wants to implement a userspace MLME or other unthinkable hacks
in userspace their way is open without any more kernelside cooperation
needed.
I urge you to solve the issues with this injection interface, we've
established that you can use packet filters to grab only management
frames but monitor interfaces definitely still interact very badly with
power management, and when the hardware has a BSS filter then this will
also be disabled with a monitor interface (if monitor during operation
is supported) which again puts more load on the host.
Those aren't issues with "this injection interface" but in optimizing
the receive action for the existing Monitor mode.
I have previously suggested to use the IFF_PROMISC bit for this, but
this will also need good driver/stack API since currently drivers that
support monitor during operation will just turn off BSS filters and such
when a monitor interface is added. That will have to be changed in
drivers as well.
Sure. Monitor mode can deliver sensible default results with
IFF_PROMISC off: it will just show traffic that was flying about inside
the associated connection with the client anyway. Just making the only
way to enable hardware promisc being via IFF_PROMISC ioctl handler will
allow control over whether you want to see everything with the power hit
(the power hit doesn't matter for a box wired to the mains) or you just
want to see things aimed at you. So it sounds like a good enhancement
exploiting an existing traditional attribute whatever way you look at it.
Also, and I'm going to reply to your patches as well, this is not
something that should be restricted to mac80211 since cfg80211
generically supports virtual interfaces and anybody could in theory use
a userspace MLME even with a full-mac card given a special no-management
firmware mode. Hence, this should be documented for cfg80211 users.
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?
-Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
