* [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection [not found] <4D45A79A.1030102@davizone.at> @ 2011-01-30 19:11 ` David Gnedt 2011-01-31 16:02 ` Kalle Valo 0 siblings, 1 reply; 6+ messages in thread From: David Gnedt @ 2011-01-30 19:11 UTC (permalink / raw) To: John W. Linville Cc: linux-wireless, Kalle Valo, Grazvydas Ignotas, Denis 'GNUtoo' Carikli 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection 2011-01-30 19:11 ` [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection David Gnedt @ 2011-01-31 16:02 ` Kalle Valo 2011-01-31 23:00 ` David Gnedt 0 siblings, 1 reply; 6+ messages in thread From: Kalle Valo @ 2011-01-31 16:02 UTC (permalink / raw) To: David Gnedt Cc: John W. Linville, linux-wireless, Grazvydas Ignotas, Denis 'GNUtoo' Carikli 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection 2011-01-31 16:02 ` Kalle Valo @ 2011-01-31 23:00 ` David Gnedt 2011-02-01 22:47 ` Kalle Valo 0 siblings, 1 reply; 6+ messages in thread From: David Gnedt @ 2011-01-31 23:00 UTC (permalink / raw) To: Kalle Valo Cc: John W. Linville, linux-wireless, Grazvydas Ignotas, Denis 'GNUtoo' Carikli 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection 2011-01-31 23:00 ` David Gnedt @ 2011-02-01 22:47 ` Kalle Valo 2011-02-18 21:01 ` David Gnedt 0 siblings, 1 reply; 6+ messages in thread From: Kalle Valo @ 2011-02-01 22:47 UTC (permalink / raw) To: David Gnedt Cc: John W. Linville, linux-wireless, Grazvydas Ignotas, Denis 'GNUtoo' Carikli 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection 2011-02-01 22:47 ` Kalle Valo @ 2011-02-18 21:01 ` David Gnedt 2011-03-08 7:39 ` Kalle Valo 0 siblings, 1 reply; 6+ messages in thread From: David Gnedt @ 2011-02-18 21:01 UTC (permalink / raw) To: Kalle Valo Cc: John W. Linville, linux-wireless, Grazvydas Ignotas, Denis 'GNUtoo' Carikli [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection 2011-02-18 21:01 ` David Gnedt @ 2011-03-08 7:39 ` Kalle Valo 0 siblings, 0 replies; 6+ messages in thread From: Kalle Valo @ 2011-03-08 7:39 UTC (permalink / raw) To: David Gnedt Cc: John W. Linville, linux-wireless, Grazvydas Ignotas, Denis 'GNUtoo' Carikli 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-08 7:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4D45A79A.1030102@davizone.at>
2011-01-30 19:11 ` [PATCH 17/18] wl1251: enable tx path in monitor mode if necessary for packet injection David Gnedt
2011-01-31 16:02 ` Kalle Valo
2011-01-31 23:00 ` David Gnedt
2011-02-01 22:47 ` Kalle Valo
2011-02-18 21:01 ` David Gnedt
2011-03-08 7:39 ` Kalle Valo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).