[PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection

[PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection

[David Gnedt]

If necessary enable the tx path in monitor mode for packet injection using
the JOIN command with BSS_TYPE_STA_BSS and zero BSSID.

Signed-off-by: David Gnedt <david.gnedt@davizone.at>
---
Sorry for the partly broken patches, I thought I configured my client the
right way. I tried to stop the mails at my mailserver, but it was mostly
already too late.
---
 drivers/net/wireless/wl1251/main.c   |    5 +++++
 drivers/net/wireless/wl1251/tx.c     |   17 +++++++++++++++++
 drivers/net/wireless/wl1251/wl1251.h |    1 +
 3 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/wl1251/main.c b/drivers/net/wireless/wl1251/main.c
index c931a3a..bb2d40d 100644
--- a/drivers/net/wireless/wl1251/main.c
+++ b/drivers/net/wireless/wl1251/main.c
@@ -480,6 +480,7 @@ static void wl1251_op_stop(struct ieee80211_hw *hw)
 	wl->rssi_thold = 0;
 	wl->channel = WL1251_DEFAULT_CHANNEL;
 	wl->monitor_present = false;
+	wl->joined = false;
 
 	wl1251_debugfs_reset(wl);
 
@@ -536,6 +537,7 @@ static void wl1251_op_remove_interface(struct ieee80211_hw *hw,
 	mutex_lock(&wl->mutex);
 	wl1251_debug(DEBUG_MAC80211, "mac80211 remove interface");
 	wl->vif = NULL;
+	memset(wl->bssid, 0, ETH_ALEN);
 	mutex_unlock(&wl->mutex);
 }
 
@@ -618,6 +620,7 @@ static int wl1251_op_config(struct ieee80211_hw *hw, u32 changed)
 		 * at firmware level.
 		 */
 		if (wl->vif == NULL) {
+			wl->joined = false;
 			ret = wl1251_cmd_data_path_rx(wl, wl->channel, 1);
 		} else {
 			ret = wl1251_join(wl, wl->bss_type, wl->channel,
@@ -1588,7 +1591,9 @@ struct ieee80211_hw *wl1251_alloc_hw(void)
 	INIT_DELAYED_WORK(&wl->elp_work, wl1251_elp_work);
 	wl->channel = WL1251_DEFAULT_CHANNEL;
 	wl->monitor_present = false;
+	wl->joined = false;
 	wl->scanning = false;
+	wl->bss_type = MAX_BSS_TYPE;
 	wl->default_key = 0;
 	wl->listen_int = 1;
 	wl->rx_counter = 0;
diff --git a/drivers/net/wireless/wl1251/tx.c b/drivers/net/wireless/wl1251/tx.c
index 3cc82fd..1de4ccb 100644
--- a/drivers/net/wireless/wl1251/tx.c
+++ b/drivers/net/wireless/wl1251/tx.c
@@ -28,6 +28,7 @@
 #include "tx.h"
 #include "ps.h"
 #include "io.h"
+#include "event.h"
 
 static bool wl1251_tx_double_buffer_busy(struct wl1251 *wl, u32 data_out_count)
 {
@@ -298,6 +299,22 @@ static int wl1251_tx_frame(struct wl1251 *wl, struct sk_buff *skb)
 		}
 	}
 
+	/* Enable tx path in monitor mode for packet injection */
+	if ((wl->vif == NULL) && !wl->joined) {
+		ret = wl1251_cmd_join(wl, BSS_TYPE_STA_BSS, wl->channel,
+				      wl->beacon_int, wl->dtim_period);
+		if (ret < 0)
+			wl1251_warning("join failed");
+		else {
+			ret = wl1251_event_wait(wl, JOIN_EVENT_COMPLETE_ID,
+						100);
+			if (ret < 0)
+				wl1251_warning("join timeout");
+			else
+				wl->joined = true;
+		}
+	}
+
 	ret = wl1251_tx_path_status(wl);
 	if (ret < 0)
 		return ret;
diff --git a/drivers/net/wireless/wl1251/wl1251.h b/drivers/net/wireless/wl1251/wl1251.h
index 184ceff..fddafe2 100644
--- a/drivers/net/wireless/wl1251/wl1251.h
+++ b/drivers/net/wireless/wl1251/wl1251.h
@@ -303,6 +303,7 @@ struct wl1251 {
 	u8 listen_int;
 	int channel;
 	bool monitor_present;
+	bool joined;
 
 	void *target_mem_map;
 	struct acx_data_path_params_resp *data_path;
-- 
1.7.0.4

Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection

[Kalle Valo]

David Gnedt <david.gnedt@davizone.at> writes:

> If necessary enable the tx path in monitor mode for packet injection using
> the JOIN command with BSS_TYPE_STA_BSS and zero BSSID.

Ok, this answers my question, you send TX_ENABLE command during the
first frame transmission. I have to admit that it sounds a bit
hackish. I would prefer to keep the driver as simple as possible,
makes it easier to maintain it that way.

I would like to step back and first look at the problem you are trying
to solve and maybe there's a way we can fix the join command. Was it
something to do with firmware sending extra frames? Unfortunately TI
firmwares are notorious for that.

-- 
Kalle Valo

Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection

[David Gnedt]

Am 2011-01-31 17:02, schrieb Kalle Valo:
> David Gnedt <david.gnedt@davizone.at> writes:
> 
>> If necessary enable the tx path in monitor mode for packet injection using
>> the JOIN command with BSS_TYPE_STA_BSS and zero BSSID.
> 
> Ok, this answers my question, you send TX_ENABLE command during the
> first frame transmission. I have to admit that it sounds a bit
> hackish. I would prefer to keep the driver as simple as possible,
> makes it easier to maintain it that way.
> 
> I would like to step back and first look at the problem you are trying
> to solve and maybe there's a way we can fix the join command. Was it
> something to do with firmware sending extra frames? Unfortunately TI
> firmwares are notorious for that.

Yeah, you are right, but I don't think the JOIN command can be fixed. Even if we
use it with a zero BSSID and zero SSID, it sends some frames. Then there are not
much parameters left, which can influence it's behaviour.

All in all I think the JOIN command was only meant to be used when you really
want to associate.

It would be really unpleasant if the firmware keeps sending frames while channel
hopping (through user-space software) in monitor mode.
That's why I use RX_ENABLE to switch channels in monitor mode, but that again
results in a disabled TX path. My testing showed that it also can't be enabled
again with TX_ENABLE, only a JOIN command enables the TX path again.

By the way, I only split up RX_ENABLE and TX_ENABLE to reduce the amount of
firmware commands sent.

So summing up, I think the JOIN command is the only command which enables the TX
path, but with the drawback of also transmitting some extra frames.

Nevertheless I am going to experiment with the JOIN command again, maybe I have
overlooked something.

Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection

[Kalle Valo]

David Gnedt <david.gnedt@davizone.at> writes:

> Am 2011-01-31 17:02, schrieb Kalle Valo:
>
>> I would like to step back and first look at the problem you are trying
>> to solve and maybe there's a way we can fix the join command. Was it
>> something to do with firmware sending extra frames? Unfortunately TI
>> firmwares are notorious for that.
>
> Yeah, you are right, but I don't think the JOIN command can be
> fixed. Even if we use it with a zero BSSID and zero SSID, it sends
> some frames.

What frames are we talking about exactly? (I can't test this right now.)

> All in all I think the JOIN command was only meant to be used when you really
> want to associate.

Yes, that has been my impression as well. But I really don't know if
we have any better options. Adding the hack you did to tx path is
really awkward as well.

> It would be really unpleasant if the firmware keeps sending frames
> while channel hopping (through user-space software) in monitor mode.

I don't see it as that bad really, but of course it depends what
frames are sent.

-- 
Kalle Valo

Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection

[David Gnedt]

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

Am 2011-02-01 23:47, schrieb Kalle Valo:
> What frames are we talking about exactly? (I can't test this right now.)

They look to me like CTS-to-Self frames. I have attached a sample of them. There
is no other RTS/CTS traffic on the same channel.
I have done further testing for channel switching in monitor mode and there are
some promising results. It looks like the CTS-to-self frames are not sent if
JOIN is used as usual but DISABLE_TX is issued first. Moreover the TX path
remains enabled with this combination.

I thought it would be best to implement it in the following way:
Start with disabled TX path. I found that enabling TX path at least once is
necessary, so it will be ENABLE_TX followed by DISABLE_TX.
It looks to me like managed mode also works after DISABLE_TX, but just to be
sure I will add a ENABLE_TX in wl1251_op_add_interface and a DISABLE_TX in
wl1251_op_remove_interface.

You can find the complete results here: http://wiki.maemo.org/Wl1251/Development

[-- Attachment #2: wl1251_join_cts_frames.cap --]
[-- Type: application/cap, Size: 148 bytes --]

Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection

[Kalle Valo]

David Gnedt <david.gnedt@davizone.at> writes:

> Am 2011-02-01 23:47, schrieb Kalle Valo:
>> What frames are we talking about exactly? (I can't test this right now.)
>
> They look to me like CTS-to-Self frames. I have attached a sample of
> them. There is no other RTS/CTS traffic on the same channel.

IIRC correctly bluetooth coexistance sends CTS-to-Self frames before
firmware is giving airtime to bluetooth. I'm guessing that's the
reason why you are seeing these frames.

-- 
Kalle Valo