Hi folks -
This set of patches change the Monitor Mode wireless interfaces to use radiotap
both for monitoring and for packet injection. The monitoring side is done by a patch
from Michael Wu. Tcpdump knows how to handle the result.
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. The packet
has a normal radiotap header prepended to the IEEE80211 header. The radiotap header
is variable length depending on what the user wants to specify, currently the
transmit rate, power and antenna can be specified using normal radiotap semantics.
Any other entries are skipped.
A usermode app packetspammer is available from here
http://penumbra.warmcat.com/_twk/tiki-index.php?page=packetspammer
which allows easy injection of these packets from the commandline. At the moment it
loops issuing packets at a variety of rates which can be seen from another
machine's monitor mode interface on the same channel. There are instructions for
build and using it on the page above.
Currently it has been tested for both rx and tx using zd1211rw-mac80211.
The patches should be based against wireless-dev.
I also added a documentation file patch which explains how to use the injection
functionality.
--
On Wednesday 21 March 2007 14:10, Johannes Berg wrote:
> Ok so people don't want to have this in cfg80211, all the better for me
> since it's less work.
>
> 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.
>
> 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.
>
Note that my patch predates the suggestion that IFF_PROMISC be used to turn on
monitor mode on the hardware. (2006-12-18) I merely updated it so that
monitor interfaces output radiotap whether or not the driver supports.
This patch series is not meant to replace the management interface. I just
gave Andy Green the radiotap RX patch so he could do some work in the right
direction, but that patch isn't complete by itself. (That's why I didn't sign
off on it) In particular, patches doing these things in addition to what this
current patch series does will be needed to finally remove the management
interface:
1. Make it easy to flip monitor mode on and off in drivers and support your
IFF_PROMISC suggestion.
2. Make the use of radiotap by drivers configurable independently of monitor
mode.
3. Report the result of a TX through monitor interfaces after
ieee80211_tx_status is called. This requires new radiotap definitions.
4. Move things like radar detection and the rest of ieee80211_msg_* to
cfg/nl80211 if they are necessary.
5. Port hostap and wpa_supplicant to the new interface. Will require some fun
with packet filtering..
6. Kill the mgmt interface once and for all.
We don't need to replace the mgmt interface at once however. Addressing the
first two issues should be sufficient to merge the radiotap RX/TX patches.
After that, 3-6 can be done one by one.
-Michael Wu
Hi,
Here are some more issues using monitor interfaces for management that
will need to be addressed before I'm convinced that doing injection on
monitor interfaces is viable.
If the driver does not support radiotap, ieee80211_rx_monitor needs to
expand the head for each packet. Currently, this is also true, but since
currently no non-management frames are sent down the management
interface, this is not an issue. If each data packet needs to be first
reallocated though, it quickly becomes a problem for low-power embedded
access points running hostapd.
Additionally, the overhead of tacking on radiotap headers to each
received frame is also rather high if you're only interested in
receiving the information for management frames.
johannes
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
On Tue, 2007-03-20 at 10:39 +0000, [email protected] 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.
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.
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.
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.
Please work out these issues before adding this interface to the kernel.
johannes
On Thu, 2007-03-22 at 18:58 -0400, Michael Wu wrote:
> Note that my patch predates the suggestion that IFF_PROMISC be used to turn on
> monitor mode on the hardware. (2006-12-18) I merely updated it so that
> monitor interfaces output radiotap whether or not the driver supports.
Right.
> This patch series is not meant to replace the management interface.
I know. However, ultimately something that will grow out of this patch
series will replace the management interface, otherwise this just adds
redundant API.
> 1. Make it easy to flip monitor mode on and off in drivers and support your
> IFF_PROMISC suggestion.
> 2. Make the use of radiotap by drivers configurable independently of monitor
> mode.
> 3. Report the result of a TX through monitor interfaces after
> ieee80211_tx_status is called. This requires new radiotap definitions.
> 4. Move things like radar detection and the rest of ieee80211_msg_* to
> cfg/nl80211 if they are necessary.
> 5. Port hostap and wpa_supplicant to the new interface. Will require some fun
> with packet filtering..
> 6. Kill the mgmt interface once and for all.
>
> We don't need to replace the mgmt interface at once however. Addressing the
> first two issues should be sufficient to merge the radiotap RX/TX patches.
> After that, 3-6 can be done one by one.
Those are all good points, and 1 isn't even required for just this
injection stuff that Andy is after, but I don't like adding this API
without having a clear plan of how it can replace the management
interface. One of the things you haven't convinced me of is that you
will be able to convince the BSD people to add new radiotap definitions
that we need. Also, if we can't have a good way to know exactly and
easily which frame we have when we see one on ACK (the cookie thing
about mapping injected frames to status updates) then I don't see how
this can possibly replace the management interface.
johannes
On Wednesday 21 March 2007 14:46, Johannes Berg wrote:
> If the driver does not support radiotap, ieee80211_rx_monitor needs to
> expand the head for each packet. Currently, this is also true, but since
> currently no non-management frames are sent down the management
> interface, this is not an issue. If each data packet needs to be first
> reallocated though, it quickly becomes a problem for low-power embedded
> access points running hostapd.
>
That's why drivers should be modified to support radiotap.
> Additionally, the overhead of tacking on radiotap headers to each
> received frame is also rather high if you're only interested in
> receiving the information for management frames.
>
It's really not that much overhead.
-Michael Wu
Johannes Berg wrote:
> On Tue, 2007-03-20 at 10:39 +0000, [email protected] 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