Monitor mode is able to TX by using injected frames. We should
not allow injected frames to be sent unless allowed by regulatory
rules. Since AP mode uses a monitor interfaces to transmit
management frames we have to take care to not break AP mode as
well while resolving this. We can deal with this by allowing compliant
APs solutions to inform mac80211 if their monitor interface is
intended to be used for an AP by setting a cfg80211 flag for the
monitor interface. hostapd, for example, currently does its own
checks to ensure AP mode is not used on channels which require radar
detection. Once such solutions are available it can can add this
flag for monitor interfaces.
Acked-by: Johannes Berg <[email protected]>
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
This v6 leaves the AP flag out and removes the unused sdata..
net/mac80211/tx.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 7b013fb..f1c726d 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1433,10 +1433,31 @@ int ieee80211_monitor_start_xmit(struct sk_buff *skb,
struct net_device *dev)
{
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
+ struct ieee80211_channel *chan = local->hw.conf.channel;
struct ieee80211_radiotap_header *prthdr =
(struct ieee80211_radiotap_header *)skb->data;
u16 len_rthdr;
+ /*
+ * Frame injection is not allowed if beaconing is not allowed
+ * or if we need radar detection. Beaconing is usually not allowed when
+ * the mode or operation (Adhoc, AP, Mesh) does not support DFS.
+ * Passive scan is also used in world regulatory domains where
+ * your country is not known and as such it should be treated as
+ * NO TX unless the channel is explicitly allowed in which case
+ * your current regulatory domain would not have the passive scan
+ * flag.
+ *
+ * Since AP mode uses monitor interfaces to inject/TX management
+ * frames we can make AP mode the exception to this rule once it
+ * supports radar detection as its implementation can deal with
+ * radar detection by itself. We can do that later by adding a
+ * monitor flag interfaces used for AP support.
+ */
+ if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
+ IEEE80211_CHAN_PASSIVE_SCAN)))
+ goto fail;
+
/* check for not even having the fixed radiotap header part */
if (unlikely(skb->len < sizeof(struct ieee80211_radiotap_header)))
goto fail; /* too short to be possibly valid */
--
1.6.1.2.253.ga34a
On Fri, 2009-01-30 at 09:08 -0800, Luis R. Rodriguez wrote:
> Monitor mode is able to TX by using injected frames. We should
> not allow injected frames to be sent unless allowed by regulatory
> rules. Since AP mode uses a monitor interfaces to transmit
> management frames we have to take care to not break AP mode as
> well while resolving this. We can deal with this by allowing compliant
> APs solutions to inform mac80211 if their monitor interface is
> intended to be used for an AP by setting a cfg80211 flag for the
> monitor interface. hostapd, for example, currently does its own
> checks to ensure AP mode is not used on channels which require radar
> detection. Once such solutions are available it can can add this
> flag for monitor interfaces.
>
> Acked-by: Johannes Berg <[email protected]>
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
>
> This v6 leaves the AP flag out and removes the unused sdata..
Yeah, let's go with this until hostapd is fixed anyway.
johannes
On Mon, Feb 09, 2009 at 08:12:21AM -0800, Richard Farina wrote:
> Johannes Berg wrote:
> > On Fri, 2009-01-30 at 09:08 -0800, Luis R. Rodriguez wrote:
> >
> >> Monitor mode is able to TX by using injected frames. We should
> >> not allow injected frames to be sent unless allowed by regulatory
> >> rules. Since AP mode uses a monitor interfaces to transmit
> >> management frames we have to take care to not break AP mode as
> >> well while resolving this. We can deal with this by allowing compliant
> >> APs solutions to inform mac80211 if their monitor interface is
> >> intended to be used for an AP by setting a cfg80211 flag for the
> >> monitor interface. hostapd, for example, currently does its own
> >> checks to ensure AP mode is not used on channels which require radar
> >> detection. Once such solutions are available it can can add this
> >> flag for monitor interfaces.
> >>
> >> Acked-by: Johannes Berg <[email protected]>
> >> Signed-off-by: Luis R. Rodriguez <[email protected]>
> >>
> Tested-by: Rick Farina <[email protected]>
> Nacked-by: Rick Farina <[email protected]>
>
> Luis, when I requested this from you and you cranked out a patch in 30
> seconds what you gave me worked great, unfortunately this patch doesn't
> perform the intended function for me. If I use this patch and mark,
> say, everything as "PASSIVE-SCAN NO-IBSS" I can still send raw packets
> out of my interface
Can you provide the output of 'iw list'? What channel are you tuning
your monitor interface to? Also can you elaborate on how you are testing
transmitting over an injected monitor interface exactly?
For example I just tested with two wireless cards, an ath9k and an iwlagn
in two separate frequencies, 2412 and 5320 provided iw list lists on both
interfaces:
* 2412 MHz [1] (14.0 dBm)
* 5320 MHz [64] (15.0 dBm) (passive scanning, no IBSS, radar detection)
I use this script to create the monitor interfaces:
---
#!/bin/bash
FREQ="2412"
#FREQ="5320"
# Create the monitor interfaces
sudo iw phy phy0 interface add mon-ath9k type monitor
sudo iw phy phy1 interface add mon-iwlagn type monitor
# Bring the interfaces up
sudo ip link set mon-ath9k up
sudo ip link set mon-iwlagn up
# Tunes to desired freq
sudo iw dev mon-ath9k set freq $FREQ
sudo iw dev mon-iwlagn set freq $FREQ
---
Then on two separate screens I compiled and ran packetspammer [1] from
Andy Green. Which BTW andy can you post the link the actual git tree? I had
to download each blob to download this, and couldn't find the git URL heh,
will like to update the URL on Documentation/networking/mac80211-injection.txt.
[1] http://git.warmcat.com/cgi-bin/cgit.cgi?url=packetspammer.git/
On ath9k on freq 2412:
-------------------------------------------------------------------------------
mcgrof@mosca ~/devel/packetspammer $ sudo ./packetspammer mon-ath9k
Packetspammer (c)2007 Andy Green <[email protected]> GPL2
DLT_IEEE802_11_RADIO Encap
RX Filter applied
(delay between packets 100000us)
rtap: 0000: 00 00 0D 00 04 80 02 00 02 00 00 00 03 .............
RX: Rate: 1.0Mbps, Freq: 0.0GHz, Ant: 0, Flags: 0x0
0000: 50 61 63 6B 65 74 73 70 61 6D 6D 65 72 20 35 34 Packetspammer 54
0010: 62 72 6F 61 64 63 61 73 74 20 70 61 63 6B 65 74 broadcast packet
0020: 23 30 30 30 30 30 20 2D 2D 20 3A 2D 44 20 2D 2D #00000 -- :-D --
0030: 6D 6F 73 63 61 20 2D 2D 2D 2D mosca ----
rtap: 0000: 00 00 0D 00 04 80 02 00 02 00 00 00 03 .............
RX: Rate: 1.0Mbps, Freq: 0.0GHz, Ant: 0, Flags: 0x0
0000: 50 61 63 6B 65 74 73 70 61 6D 6D 65 72 20 34 38 Packetspammer 48
0010: 62 72 6F 61 64 63 61 73 74 20 70 61 63 6B 65 74 broadcast packet
0020: 23 30 30 30 30 31 20 2D 2D 20 3A 2D 44 20 2D 2D #00001 -- :-D --
0030: 6D 6F 73 63 61 20 2D 2D 2D 2D mosca ----
rtap: 0000: 00 00 0D 00 04 80 02 00 02 00 00 00 03 .............
RX: Rate: 1.0Mbps, Freq: 0.0GHz, Ant: 0, Flags: 0x0
0000: 50 61 63 6B 65 74 73 70 61 6D 6D 65 72 20 33 36 Packetspammer 36
0010: 62 72 6F 61 64 63 61 73 74 20 70 61 63 6B 65 74 broadcast packet
0020: 23 30 30 30 30 32 20 2D 2D 20 3A 2D 44 20 2D 2D #00002 -- :-D --
0030: 6D 6F 73 63 61 20 2D 2D 2D 2D mosca ----
-------------------------------------------------------------------------------
On iwlagn it similar so won't bother posting it. If I try to use freq 5320 on either
I get
-------------------------------------------------------------------------------
mcgrof@mosca ~/devel/packetspammer $ sudo ./packetspammer mon-ath9k
Packetspammer (c)2007 Andy Green <[email protected]> GPL2
DLT_IEEE802_11_RADIO Encap
RX Filter applied
(delay between packets 100000us)
-------------------------------------------------------------------------------
And it sits there without doing anything.
Luis
Johannes Berg wrote:
> On Fri, 2009-01-30 at 09:08 -0800, Luis R. Rodriguez wrote:
>
>> Monitor mode is able to TX by using injected frames. We should
>> not allow injected frames to be sent unless allowed by regulatory
>> rules. Since AP mode uses a monitor interfaces to transmit
>> management frames we have to take care to not break AP mode as
>> well while resolving this. We can deal with this by allowing compliant
>> APs solutions to inform mac80211 if their monitor interface is
>> intended to be used for an AP by setting a cfg80211 flag for the
>> monitor interface. hostapd, for example, currently does its own
>> checks to ensure AP mode is not used on channels which require radar
>> detection. Once such solutions are available it can can add this
>> flag for monitor interfaces.
>>
>> Acked-by: Johannes Berg <[email protected]>
>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>>
Tested-by: Rick Farina <[email protected]>
Nacked-by: Rick Farina <[email protected]>
Luis, when I requested this from you and you cranked out a patch in 30
seconds what you gave me worked great, unfortunately this patch doesn't
perform the intended function for me. If I use this patch and mark,
say, everything as "PASSIVE-SCAN NO-IBSS" I can still send raw packets
out of my interface (confirmed by capturing on another card). The
original patch is as follows:
+ if ((tx->channel->flags & (IEEE80211_CHAN_NO_IBSS |
+ IEEE80211_CHAN_RADAR)))
+ return TX_DROP;
TX_DROP seemed to successfully prevent raw packet transmission on the
channels marked NO_IBSS. Can someone please confirm my findings so we
can get this fixed properly?
Thanks,
Rick Farina
>> ---
>>
>> This v6 leaves the AP flag out and removes the unused sdata..
>>
>
> Yeah, let's go with this until hostapd is fixed anyway.
>
> johannes
>