* Re: pull request: wireless-2.6 2009-08-21
From: David Miller @ 2009-08-21 20:13 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090821170324.GC8532@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 21 Aug 2009 13:03:25 -0400
> One more straggler for 2.6.31...without this rtl8187b devices simply
> don't work. :-(
>
> The patch is small and isolated to rtl8187. I think we should take
> it for 2.6.31.
>
> Please let me know if there are problems!
Pulled, and I'll push out to kernel.org after a test build.
Thanks!
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-08-20
From: David Miller @ 2009-08-21 20:12 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090820172611.GE2657@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 20 Aug 2009 13:26:11 -0400
> The relentless march of wireless patches for 2.6.32 continues... In
> this batch, further implementation of the LP-PHY support for b43 along
> with the usual batches of driver updates and the like -- iwlwifi, ath9k,
> rt2x00, mwl8k, and others.
>
> Please let me know if there are problems!
Pulled and pushed back out to kernel.org, thanks!
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Gábor Stefanik @ 2009-08-21 19:57 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4A8EF031.4050604@cs.ucla.edu>
2009/8/21 Rafael Laufer <rlaufer@cs.ucla.edu>:
> Gábor Stefanik wrote:
>> 2009/8/21 Rafael Laufer <rlaufer@cs.ucla.edu>:
>>
>>> Gábor Stefanik wrote:
>>>
>>>> Maybe a new IEEE80211_TX_CTL_ or IEEE80211_TX_RC_ flag will also be
>>>> needed, so Radiotap can indicate whether rate_control_get_rate needs
>>>> to be called.
>>>>
>>> ok, I am resending the patch. I included a new flag called
>>> IEEE80211_TX_CTL_RATE_RADIOTAP to indicate if the rate has
>>> been set in the radiotap header. If not, then the rate control
>>> algorithm is called.
>>>
>>
>> Isn't it easier to check whether we already have a rate configured?
>> (info->control.rates[0].idx is set to an invalid value before the
>> rate_control_get_rate call AFAIK, unless you set it in the radiotap
>> decoding function before.)
>>
>
> I guess it is also possible, but in that case you rely on the assumption
> that the rate is invalid before rate_control_get_rate(). If in the
> future this assumption does not hold, the code will break. If, however,
> this is always gonna be true, I can change the code to use your
> suggestion. Personally, I prefer to use another flag so that future
> changes do not affect this code, but let me know what is best.
>
> Rafael
>
Actually, that's a good point.
One thing to watch out for is that the actual rate index is not the
only thing the rate controller sets - it is also responsible for
things like retry count & RTS/CTS usage. Those are controlled by other
radiotap fields. So, if any of these values is unset in radiotap, you
will need to call rate control for them, or auto-generate them in
other ways. Otherwise you may end up with e.g. an incorrect retry
count.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Rafael Laufer @ 2009-08-21 19:06 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <69e28c910908211152k4423d098i92b25078139ee827@mail.gmail.com>
Gábor Stefanik wrote:
> 2009/8/21 Rafael Laufer <rlaufer@cs.ucla.edu>:
>
>> Gábor Stefanik wrote:
>>
>>> Maybe a new IEEE80211_TX_CTL_ or IEEE80211_TX_RC_ flag will also be
>>> needed, so Radiotap can indicate whether rate_control_get_rate needs
>>> to be called.
>>>
>> ok, I am resending the patch. I included a new flag called
>> IEEE80211_TX_CTL_RATE_RADIOTAP to indicate if the rate has
>> been set in the radiotap header. If not, then the rate control
>> algorithm is called.
>>
>
> Isn't it easier to check whether we already have a rate configured?
> (info->control.rates[0].idx is set to an invalid value before the
> rate_control_get_rate call AFAIK, unless you set it in the radiotap
> decoding function before.)
>
I guess it is also possible, but in that case you rely on the assumption
that the rate is invalid before rate_control_get_rate(). If in the
future this assumption does not hold, the code will break. If, however,
this is always gonna be true, I can change the code to use your
suggestion. Personally, I prefer to use another flag so that future
changes do not affect this code, but let me know what is best.
Rafael
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Gábor Stefanik @ 2009-08-21 18:52 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4A8EE182.6040709@cs.ucla.edu>
2009/8/21 Rafael Laufer <rlaufer@cs.ucla.edu>:
> Gábor Stefanik wrote:
>>
>> Maybe a new IEEE80211_TX_CTL_ or IEEE80211_TX_RC_ flag will also be
>> needed, so Radiotap can indicate whether rate_control_get_rate needs
>> to be called.
>
> ok, I am resending the patch. I included a new flag called
> IEEE80211_TX_CTL_RATE_RADIOTAP to indicate if the rate has
> been set in the radiotap header. If not, then the rate control
> algorithm is called.
Isn't it easier to check whether we already have a rate configured?
(info->control.rates[0].idx is set to an invalid value before the
rate_control_get_rate call AFAIK, unless you set it in the radiotap
decoding function before.)
>
> Note that in the future there must be other flags like this to
> indicate if other parameters, such as power, was also set in
> the radiotap header.
>
>
> Signed-off-by: Rafael Laufer <rlaufer@cs.ucla.edu>
> ---
> Implementation of the IEEE80211_RADIOTAP_RATE
> option when parsing radiotap headers to allow
> rate selection on a per-packet basis. A new
> flag IEEE80211_TX_CTL_RATE_RADIOTAP is also
> included to indicate that the rate was set in
> the radiotap header and therefore the rate
> control algorithm should not change it.
>
> include/net/mac80211.h | 4 ++++
> net/mac80211/tx.c | 22 +++++++++++++++++++++-
> 2 files changed, 25 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index aac84d7..819b01e 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -272,6 +272,9 @@ struct ieee80211_bss_conf {
> * transmit function after the current frame, this can be used
> * by drivers to kick the DMA queue only if unset or when the
> * queue gets full.
> + * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
> + * used to indicate that the rate was defined in the received radiotap
> + * header and therefore the rate control algorithm should not change it.
> */
> enum mac80211_tx_control_flags {
> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
> @@ -293,6 +296,7 @@ enum mac80211_tx_control_flags {
> IEEE80211_TX_INTFL_DONT_ENCRYPT = BIT(16),
> IEEE80211_TX_CTL_PSPOLL_RESPONSE = BIT(17),
> IEEE80211_TX_CTL_MORE_FRAMES = BIT(18),
> + IEEE80211_TX_CTL_RATE_RADIOTAP = BIT(19),
> };
>
> /**
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 10a1099..f675844 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -549,7 +549,12 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
> * If we're associated with the sta at this point we know we can at
> * least send the frame at the lowest bit rate.
> */
> - rate_control_get_rate(tx->sdata, tx->sta, &txrc);
> +
> + /* In monitor mode, if the IEEE80211_RADIOTAP_RATE option is set in
> + * the received radiotap header, do not call the rate control algorithm.
> + */
> + if (likely(!(info->flags & IEEE80211_TX_CTL_RATE_RADIOTAP)))
> + rate_control_get_rate(tx->sdata, tx->sta, &txrc);
>
> if (unlikely(info->control.rates[0].idx < 0))
> return TX_DROP;
> @@ -972,6 +977,21 @@ static bool __ieee80211_parse_tx_radiotap(struct ieee80211_tx_data *tx,
> tx->flags |= IEEE80211_TX_FRAGMENTED;
> break;
>
> + /* Get the rate parameter from the radiotap header,
> + * allowing rate selection on a per-packet basis
> + */
> + case IEEE80211_RADIOTAP_RATE:
> + bitrate = (*iterator.this_arg) * 5;
> + for (i = 0; i < sband->n_bitrates; i++) {
> + if (sband->bitrates[i].bitrate == bitrate)
> + break;
> + }
> + if (i != sband->n_bitrates) {
> + info->control.rates[0].idx = i;
> + info->flags |= IEEE80211_TX_CTL_RATE_RADIOTAP;
> + }
> + break;
> +
> /*
> * Please update the file
> * Documentation/networking/mac80211-injection.txt
> --
> 1.6.0.4
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH v2] iwlwifi: Make injection of non-broadcast frames work again
From: Gábor Stefanik @ 2009-08-21 18:44 UTC (permalink / raw)
To: John Linville, Reinette Chatre, Zhu Yi
Cc: Wey-Yi Guy, Rafael Laufer, ipw3945-devel, linux-wireless
Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
broke injection of non-broadcast frames to unassociated stations
(causing a SYSASSERT for all such injected frames), due to injected
frames no longer automatically getting a broadcast station ID assigned.
This patch restores the old behavior, fixing the aforementioned
regression.
Also, consistently check for IEEE80211_TX_CTL_INJECTED instead of
iwl_is_monitor_mode in the TX path, as TX_CTL_INJECTED specifically
means that a given packet is coming from a monitor interface, while
iwl_is_monitor_mode only shows whether a monitor interface exists
on the device.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
V2: Use a totally new approach to fixing this bug.
Also fix a few more cases where iwl_is_monitor_mode was incorrectly
used to check whether a given packet comes from a monitor interface.
(For that, IEEE80211_TX_CTL_INJECTED should be used.)
drivers/net/wireless/iwlwifi/iwl-tx.c | 10 ++++++----
drivers/net/wireless/iwlwifi/iwl3945-base.c | 9 ++++++---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 9b76bd4..8eba9e9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -718,10 +718,9 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
IWL_DEBUG_TX(priv, "Sending REASSOC frame\n");
#endif
- /* drop all data frame if we are not associated */
+ /* drop all non-injected data frame if we are not associated */
if (ieee80211_is_data(fc) &&
- (!iwl_is_monitor_mode(priv) ||
- !(info->flags & IEEE80211_TX_CTL_INJECTED)) && /* packet injection */
+ !(info->flags & IEEE80211_TX_CTL_INJECTED) &&
(!iwl_is_associated(priv) ||
((priv->iw_mode == NL80211_IFTYPE_STATION) && !priv->assoc_id) ||
!priv->assoc_station_added)) {
@@ -732,7 +731,10 @@ int iwl_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
hdr_len = ieee80211_hdrlen(fc);
/* Find (or create) index into station table for destination station */
- sta_id = iwl_get_sta_id(priv, hdr);
+ if (info->flags & IEEE80211_TX_CTL_INJECTED)
+ sta_id = priv->hw_params.bcast_sta_id;
+ else
+ sta_id = iwl_get_sta_id(priv, hdr);
if (sta_id == IWL_INVALID_STATION) {
IWL_DEBUG_DROP(priv, "Dropping - INVALID STATION: %pM\n",
hdr->addr1);
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index e617411..d0debdf 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -518,9 +518,9 @@ static int iwl3945_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
IWL_DEBUG_TX(priv, "Sending REASSOC frame\n");
#endif
- /* drop all data frame if we are not associated */
+ /* drop all non-injected data frame if we are not associated */
if (ieee80211_is_data(fc) &&
- (!iwl_is_monitor_mode(priv)) && /* packet injection */
+ !(info->flags & IEEE80211_TX_CTL_INJECTED) &&
(!iwl_is_associated(priv) ||
((priv->iw_mode == NL80211_IFTYPE_STATION) && !priv->assoc_id))) {
IWL_DEBUG_DROP(priv, "Dropping - !iwl_is_associated\n");
@@ -532,7 +532,10 @@ static int iwl3945_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
hdr_len = ieee80211_hdrlen(fc);
/* Find (or create) index into station table for destination station */
- sta_id = iwl_get_sta_id(priv, hdr);
+ if (info->flags & IEEE80211_TX_CTL_INJECTED)
+ sta_id = priv->hw_params.bcast_sta_id;
+ else
+ sta_id = iwl_get_sta_id(priv, hdr);
if (sta_id == IWL_INVALID_STATION) {
IWL_DEBUG_DROP(priv, "Dropping - INVALID STATION: %pM\n",
hdr->addr1);
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: Gábor Stefanik @ 2009-08-21 18:37 UTC (permalink / raw)
To: reinette chatre
Cc: John Linville, Zhu, Yi, Guy, Wey-Yi W, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <1250879069.30019.14482.camel@rc-desk>
2009/8/21 reinette chatre <reinette.chatre@intel.com>:
> Hi Gábor,
>
> On Fri, 2009-08-21 at 11:10 -0700, Gábor Stefanik wrote:
>
>> That can be done, yes. It is also a good idea to convert
>> iwl_is_monitor_mode(priv) calls with TX_CTL_INJECTED checks, as
>> mac80211 will set IEEE80211_TX_CTL_INJECTED if and only if the packet
>> arrived from a monitor interface.
>
> I don't think that is the intention of that function.
> iwl_is_monitor_mode() needs to return whether the interface is in
> monitor mode or not and being in monitor mode is specifically when some
> filter flags are set up. This is what is tested in this function.
Thanks for the clarification. Will submit a corrected patch soon.
>
>> (However, when I submitted the first
>> patches to iwlwifi to enable injection, they were rejected
>> specifically because I checked INJECTED in iwl_tx_skb/iwl394_tx_skb,
>> rather than adding a monitor mode case to iwl_get_sta_id... times
>> change I guess.) I'll submit a patch for this.
>
> Sure - you can move the check to iwl_get_sta_id. You will need to
> indicate to that function that the frame is being injected.
>
> Reinette
>
>
>
>
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: reinette chatre @ 2009-08-21 18:24 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Zhu, Yi, Guy, Wey-Yi W, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <69e28c910908211110h5a326f4cw7e21cc424bc5fbdc@mail.gmail.com>
Hi Gábor,
On Fri, 2009-08-21 at 11:10 -0700, Gábor Stefanik wrote:
> That can be done, yes. It is also a good idea to convert
> iwl_is_monitor_mode(priv) calls with TX_CTL_INJECTED checks, as
> mac80211 will set IEEE80211_TX_CTL_INJECTED if and only if the packet
> arrived from a monitor interface.
I don't think that is the intention of that function.
iwl_is_monitor_mode() needs to return whether the interface is in
monitor mode or not and being in monitor mode is specifically when some
filter flags are set up. This is what is tested in this function.
> (However, when I submitted the first
> patches to iwlwifi to enable injection, they were rejected
> specifically because I checked INJECTED in iwl_tx_skb/iwl394_tx_skb,
> rather than adding a monitor mode case to iwl_get_sta_id... times
> change I guess.) I'll submit a patch for this.
Sure - you can move the check to iwl_get_sta_id. You will need to
indicate to that function that the frame is being injected.
Reinette
^ permalink raw reply
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: Gábor Stefanik @ 2009-08-21 18:10 UTC (permalink / raw)
To: reinette chatre
Cc: John Linville, Zhu, Yi, Guy, Wey-Yi W, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <1250877589.30019.14474.camel@rc-desk>
2009/8/21 reinette chatre <reinette.chatre@intel.com>:
> Hi Gábor,
>
> On Fri, 2009-08-21 at 10:24 -0700, Gábor Stefanik wrote:
>
>> For some odd reason, reverting Wei-Yi Guy's patch makes the bug go
>> away
>
> ah - now I see. The driver defaulted to monitor mode in iwl_mac_start.
> This is not correct and this patch rightly removed that code.
>
>> ... should we do that instead for 2.6.31? (I'm all for it, if this
>> patch is not the right thing to do, as Wey-Yi's patch was not a bug
>> fix, just a cleanup.)
>
> No, this patch was more than code cleanup - it changed the driver to
> behave correctly wrt monitor interface type. Unfortunately the
> workaround to get packet injection working was not apparent enough and
> was missed.
>
>
>> My guess is that the "default to MONITOR mode"
>> change is the culprit.
>
> yeah ...
>
>
>> Maybe we should check info->flags & IEEE80211_TX_CTL_INJECTED
>> instead... is there a way to access the ieee80211_tx_info structure
>> from this function (e.g. through priv)?
>
> No, but it may not be necessary. Why is is necessary to call this
> function in the first place if you know this is an injection packet?
> Specifically, in iwl_tx_skb and iwl3945_tx_skb (where ieee80211_tx_info)
> is known) there could just be a test if this is an injected packet, if
> it is, then do not call iwl_get_sta_id, but just use "bcast_sta_id"
> directly. Would this work? Is a test for monitor mode still needed in
> this case?
That can be done, yes. It is also a good idea to convert
iwl_is_monitor_mode(priv) calls with TX_CTL_INJECTED checks, as
mac80211 will set IEEE80211_TX_CTL_INJECTED if and only if the packet
arrived from a monitor interface. (However, when I submitted the first
patches to iwlwifi to enable injection, they were rejected
specifically because I checked INJECTED in iwl_tx_skb/iwl394_tx_skb,
rather than adding a monitor mode case to iwl_get_sta_id... times
change I guess.) I'll submit a patch for this.
>
> Reinette
>
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Rafael Laufer @ 2009-08-21 18:03 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <69e28c910908210630m47eda1eegcd502c212736decd@mail.gmail.com>
Gábor Stefanik wrote:
>
> Maybe a new IEEE80211_TX_CTL_ or IEEE80211_TX_RC_ flag will also be
> needed, so Radiotap can indicate whether rate_control_get_rate needs
> to be called.
ok, I am resending the patch. I included a new flag called
IEEE80211_TX_CTL_RATE_RADIOTAP to indicate if the rate has
been set in the radiotap header. If not, then the rate control
algorithm is called.
Note that in the future there must be other flags like this to
indicate if other parameters, such as power, was also set in
the radiotap header.
Signed-off-by: Rafael Laufer <rlaufer@cs.ucla.edu>
---
Implementation of the IEEE80211_RADIOTAP_RATE
option when parsing radiotap headers to allow
rate selection on a per-packet basis. A new
flag IEEE80211_TX_CTL_RATE_RADIOTAP is also
included to indicate that the rate was set in
the radiotap header and therefore the rate
control algorithm should not change it.
include/net/mac80211.h | 4 ++++
net/mac80211/tx.c | 22 +++++++++++++++++++++-
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index aac84d7..819b01e 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -272,6 +272,9 @@ struct ieee80211_bss_conf {
* transmit function after the current frame, this can be used
* by drivers to kick the DMA queue only if unset or when the
* queue gets full.
+ * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
+ * used to indicate that the rate was defined in the received radiotap
+ * header and therefore the rate control algorithm should not change it.
*/
enum mac80211_tx_control_flags {
IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
@@ -293,6 +296,7 @@ enum mac80211_tx_control_flags {
IEEE80211_TX_INTFL_DONT_ENCRYPT = BIT(16),
IEEE80211_TX_CTL_PSPOLL_RESPONSE = BIT(17),
IEEE80211_TX_CTL_MORE_FRAMES = BIT(18),
+ IEEE80211_TX_CTL_RATE_RADIOTAP = BIT(19),
};
/**
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 10a1099..f675844 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -549,7 +549,12 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
* If we're associated with the sta at this point we know we can at
* least send the frame at the lowest bit rate.
*/
- rate_control_get_rate(tx->sdata, tx->sta, &txrc);
+
+ /* In monitor mode, if the IEEE80211_RADIOTAP_RATE option is set in
+ * the received radiotap header, do not call the rate control algorithm.
+ */
+ if (likely(!(info->flags & IEEE80211_TX_CTL_RATE_RADIOTAP)))
+ rate_control_get_rate(tx->sdata, tx->sta, &txrc);
if (unlikely(info->control.rates[0].idx < 0))
return TX_DROP;
@@ -972,6 +977,21 @@ static bool __ieee80211_parse_tx_radiotap(struct ieee80211_tx_data *tx,
tx->flags |= IEEE80211_TX_FRAGMENTED;
break;
+ /* Get the rate parameter from the radiotap header,
+ * allowing rate selection on a per-packet basis
+ */
+ case IEEE80211_RADIOTAP_RATE:
+ bitrate = (*iterator.this_arg) * 5;
+ for (i = 0; i < sband->n_bitrates; i++) {
+ if (sband->bitrates[i].bitrate == bitrate)
+ break;
+ }
+ if (i != sband->n_bitrates) {
+ info->control.rates[0].idx = i;
+ info->flags |= IEEE80211_TX_CTL_RATE_RADIOTAP;
+ }
+ break;
+
/*
* Please update the file
* Documentation/networking/mac80211-injection.txt
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: reinette chatre @ 2009-08-21 17:59 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Zhu, Yi, Guy, Wey-Yi W, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <69e28c910908211024n1c255b3p160839c60ae0b3a@mail.gmail.com>
Hi Gábor,
On Fri, 2009-08-21 at 10:24 -0700, Gábor Stefanik wrote:
> For some odd reason, reverting Wei-Yi Guy's patch makes the bug go
> away
ah - now I see. The driver defaulted to monitor mode in iwl_mac_start.
This is not correct and this patch rightly removed that code.
> ... should we do that instead for 2.6.31? (I'm all for it, if this
> patch is not the right thing to do, as Wey-Yi's patch was not a bug
> fix, just a cleanup.)
No, this patch was more than code cleanup - it changed the driver to
behave correctly wrt monitor interface type. Unfortunately the
workaround to get packet injection working was not apparent enough and
was missed.
> My guess is that the "default to MONITOR mode"
> change is the culprit.
yeah ...
> Maybe we should check info->flags & IEEE80211_TX_CTL_INJECTED
> instead... is there a way to access the ieee80211_tx_info structure
> from this function (e.g. through priv)?
No, but it may not be necessary. Why is is necessary to call this
function in the first place if you know this is an injection packet?
Specifically, in iwl_tx_skb and iwl3945_tx_skb (where ieee80211_tx_info)
is known) there could just be a test if this is an injected packet, if
it is, then do not call iwl_get_sta_id, but just use "bcast_sta_id"
directly. Would this work? Is a test for monitor mode still needed in
this case?
Reinette
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-08-21
From: Larry Finger @ 2009-08-21 17:25 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20090821170324.GC8532@tuxdriver.com>
John W. Linville wrote:
> Dave,
>
> One more straggler for 2.6.31...without this rtl8187b devices simply
> don't work. :-(
>
> The patch is small and isolated to rtl8187. I think we should take
> it for 2.6.31.
Note: This patch should fix Bugzilla #13960, which is a regression
since 2.6.30. The OP has not yet reported back, but it fixed the same
condition on my computer.
^ permalink raw reply
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: Gábor Stefanik @ 2009-08-21 17:24 UTC (permalink / raw)
To: reinette chatre
Cc: John Linville, Zhu, Yi, Guy, Wey-Yi W, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <1250872433.30019.14430.camel@rc-desk>
2009/8/21 reinette chatre <reinette.chatre@intel.com>:
> Hi Gábor,
>
> On Thu, 2009-08-20 at 15:08 -0700, Gábor Stefanik wrote:
>> Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
>> ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
>> broke injection of non-broadcast frames to unassociated stations
>> (causing a SYSASSERT for all such injected frames), due to injected
>> frames no longer automatically getting a broadcast station ID assigned,
>> and instead ending up with invalid station IDs.
>> This patch restores the old behavior, fixing the aforementioned
>> regression.
>
> The patch you are quoting cannot be the culprit here. As that commit
> message indicates we never set NL80211_IFTYPE_MONITOR for the interface
> type, so when that code removed the test for this interface type in
> iwl_get_sta_id it essentially removed dead code.
For some odd reason, reverting Wei-Yi Guy's patch makes the bug go
away... should we do that instead for 2.6.31? (I'm all for it, if this
patch is not the right thing to do, as Wey-Yi's patch was not a bug
fix, just a cleanup.) My guess is that the "default to MONITOR mode"
change is the culprit.
>
>> /* If this frame is broadcast or management, use broadcast station id */
>> - if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1))
>> + if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
>> + iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
>> return priv->hw_params.bcast_sta_id;
>
> I think my comment ties in with what Johannes said. When we are
> associated (whether in station, adhoc, or AP mode) we want this function
> to return the correct station ID. We also know that an interface can be
> in monitor mode while it is in any of these other modes. When this
> happens we do not want to return the broadcast station id ... we still
> want to return the station id. Your patch changes this behavior and will
> in this case always return the broadcast station id.
Maybe we should check info->flags & IEEE80211_TX_CTL_INJECTED
instead... is there a way to access the ieee80211_tx_info structure
from this function (e.g. through priv)?
>
> Reinette
>
>
>
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* pull request: wireless-2.6 2009-08-21
From: John W. Linville @ 2009-08-21 17:03 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
One more straggler for 2.6.31...without this rtl8187b devices simply
don't work. :-(
The patch is small and isolated to rtl8187. I think we should take
it for 2.6.31.
Please let me know if there are problems!
John
---
Patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 08fdef99342955a62884fb5c49ab43431a1cafbf:
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Herton Ronaldo Krzesinski (1):
rtl8187: always set MSR_LINK_ENEDCA flag with RTL8187B
drivers/net/wireless/rtl818x/rtl8187_dev.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index 294250e..87a9558 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -869,6 +869,9 @@ static int rtl8187b_init_hw(struct ieee80211_hw *dev)
priv->aifsn[3] = 3; /* AIFSN[AC_BE] */
rtl818x_iowrite8(priv, &priv->map->ACM_CONTROL, 0);
+ /* ENEDCA flag must always be set, transmit issues? */
+ rtl818x_iowrite8(priv, &priv->map->MSR, RTL818X_MSR_ENEDCA);
+
return 0;
}
@@ -1173,13 +1176,16 @@ static void rtl8187_bss_info_changed(struct ieee80211_hw *dev,
rtl818x_iowrite8(priv, &priv->map->BSSID[i],
info->bssid[i]);
+ if (priv->is_rtl8187b)
+ reg = RTL818X_MSR_ENEDCA;
+ else
+ reg = 0;
+
if (is_valid_ether_addr(info->bssid)) {
- reg = RTL818X_MSR_INFRA;
- if (priv->is_rtl8187b)
- reg |= RTL818X_MSR_ENEDCA;
+ reg |= RTL818X_MSR_INFRA;
rtl818x_iowrite8(priv, &priv->map->MSR, reg);
} else {
- reg = RTL818X_MSR_NO_LINK;
+ reg |= RTL818X_MSR_NO_LINK;
rtl818x_iowrite8(priv, &priv->map->MSR, reg);
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: John W. Linville @ 2009-08-21 16:43 UTC (permalink / raw)
To: reinette chatre
Cc: Gábor Stefanik, Zhu, Yi, Guy, Wey-Yi W, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <1250872433.30019.14430.camel@rc-desk>
On Fri, Aug 21, 2009 at 09:33:53AM -0700, reinette chatre wrote:
> Hi Gábor,
>
> On Thu, 2009-08-20 at 15:08 -0700, Gábor Stefanik wrote:
> > Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
> > ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
> > broke injection of non-broadcast frames to unassociated stations
> > (causing a SYSASSERT for all such injected frames), due to injected
> > frames no longer automatically getting a broadcast station ID assigned,
> > and instead ending up with invalid station IDs.
> > This patch restores the old behavior, fixing the aforementioned
> > regression.
>
> The patch you are quoting cannot be the culprit here. As that commit
> message indicates we never set NL80211_IFTYPE_MONITOR for the interface
> type, so when that code removed the test for this interface type in
> iwl_get_sta_id it essentially removed dead code.
>
> > /* If this frame is broadcast or management, use broadcast station id */
> > - if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1))
> > + if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
> > + iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
> > return priv->hw_params.bcast_sta_id;
>
> I think my comment ties in with what Johannes said. When we are
> associated (whether in station, adhoc, or AP mode) we want this function
> to return the correct station ID. We also know that an interface can be
> in monitor mode while it is in any of these other modes. When this
> happens we do not want to return the broadcast station id ... we still
> want to return the station id. Your patch changes this behavior and will
> in this case always return the broadcast station id.
Dropping on the basis of this. Please repost when/if this is resolved.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: reinette chatre @ 2009-08-21 16:33 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Zhu, Yi, Guy, Wey-Yi W, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <4A8DC955.9060100@gmail.com>
Hi Gábor,
On Thu, 2009-08-20 at 15:08 -0700, Gábor Stefanik wrote:
> Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
> ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
> broke injection of non-broadcast frames to unassociated stations
> (causing a SYSASSERT for all such injected frames), due to injected
> frames no longer automatically getting a broadcast station ID assigned,
> and instead ending up with invalid station IDs.
> This patch restores the old behavior, fixing the aforementioned
> regression.
The patch you are quoting cannot be the culprit here. As that commit
message indicates we never set NL80211_IFTYPE_MONITOR for the interface
type, so when that code removed the test for this interface type in
iwl_get_sta_id it essentially removed dead code.
> /* If this frame is broadcast or management, use broadcast station id */
> - if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1))
> + if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
> + iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
> return priv->hw_params.bcast_sta_id;
I think my comment ties in with what Johannes said. When we are
associated (whether in station, adhoc, or AP mode) we want this function
to return the correct station ID. We also know that an interface can be
in monitor mode while it is in any of these other modes. When this
happens we do not want to return the broadcast station id ... we still
want to return the station id. Your patch changes this behavior and will
in this case always return the broadcast station id.
Reinette
^ permalink raw reply
* Re: Plans for an online meeting regarding Radiotap
From: Johannes Berg @ 2009-08-21 15:11 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Richard Farina, Mike Kershaw, Sam Leffler, Rafael Laufer,
Damien Bergamini, Sepherosa Ziehau, Thomas d'Otreppe,
Dave Young, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <69e28c910908210804h6181aab1w4a864392239aa1ac@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
On Fri, 2009-08-21 at 17:04 +0200, Gábor Stefanik wrote:
> I've reworked RTS/CTS since then, just haven't got to sending a new
> proposal yet. The current plan is as follows:
>
> TX_FLAGS & 0x0002: Use CTS
> TX_FLAGS & 0x0004: Use RTS
> TX_FLAGS & 0x0020: Disable RTS/CTS usage
Seems a bit strange, wouldn't setting neither RTS nor CTS have the
effect? Seems like 0x20 should rather be "use automatic and ignore the
other bits". Anyway, not appropriate here, you should just bring a new
proposal.
> If I remember correctly, I made an implementation for the Linux kernel
> (a generator-side implementation) and one for Wireshark (a parser-side
> implementation). Or should I make two generator-side implementations
> according to the requirement (e.g. one for Linux, another for
> OpenBSD)?
No, that was ok, I just meant that therefore by definition it can't be a
problem of lack of implementations.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Plans for an online meeting regarding Radiotap
From: Gábor Stefanik @ 2009-08-21 15:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Richard Farina, Mike Kershaw, Sam Leffler, Rafael Laufer,
Damien Bergamini, Sepherosa Ziehau, Thomas d'Otreppe,
Dave Young, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <1250865918.4600.9.camel@johannes.local>
2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2009-08-21 at 16:41 +0200, Gábor Stefanik wrote:
>
>> My intention with the meeting is to form an actual proposal that all
>> implementors can agree on. We can produce proposals, and even new
>> standardized fields to no avail, as some implementors (especially
>> OpenBSD) appear to be stuck with implementations that collide with the
>> standard. These implementors need to be "awakened" and entered into
>> the discussions before anything can be done.
>
> There's nothing the standard can do about that. Like I said, we've
> talked about that enough in my opinion.
>
>> > Your own proposal had technical flaws (and in my opinion tried to do too
>> > much at a time) that you haven't addressed -- doing that would be much
>> > more productive than any such meeting.
>>
>> What technical flaws are you trying to point out exactly? (The TX
>> flags field? My point is that it's worthless to "standardize" TX flags
>> by extending it and moving to "Defined fields" if noone is willing to
>> implement it.)
>
> But people are already implementing it, and if they do something else
> that's their problem. The flaw I'm thinking of was over the RTS/CTS
> handling where some people (including myself) had comments.
I've reworked RTS/CTS since then, just haven't got to sending a new
proposal yet. The current plan is as follows:
TX_FLAGS & 0x0002: Use CTS
TX_FLAGS & 0x0004: Use RTS
TX_FLAGS & 0x0020: Disable RTS/CTS usage
Or, in more C++-like notation:
switch (TX_FLAGS & 0x0026) {
case 0x0002:
Use CTS;
break;
case 0x0004:
case 0x0006:
Use RTS;
break;
case 0x0020:
Disable RTS/CTS usage;
break;
default:
fall back to automatic selection
}
> Besides,
> you're supposed to make at least two implementations when proposing a
> standard field.
If I remember correctly, I made an implementation for the Linux kernel
(a generator-side implementation) and one for Wireshark (a parser-side
implementation). Or should I make two generator-side implementations
according to the requirement (e.g. one for Linux, another for
OpenBSD)?
>
> johannes
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Plans for an online meeting regarding Radiotap
From: Johannes Berg @ 2009-08-21 14:45 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Richard Farina, Mike Kershaw, Sam Leffler, Rafael Laufer,
Damien Bergamini, Sepherosa Ziehau, Thomas d'Otreppe,
Dave Young, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <69e28c910908210741wd3bc391x311523f5b55fd4f1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On Fri, 2009-08-21 at 16:41 +0200, Gábor Stefanik wrote:
> My intention with the meeting is to form an actual proposal that all
> implementors can agree on. We can produce proposals, and even new
> standardized fields to no avail, as some implementors (especially
> OpenBSD) appear to be stuck with implementations that collide with the
> standard. These implementors need to be "awakened" and entered into
> the discussions before anything can be done.
There's nothing the standard can do about that. Like I said, we've
talked about that enough in my opinion.
> > Your own proposal had technical flaws (and in my opinion tried to do too
> > much at a time) that you haven't addressed -- doing that would be much
> > more productive than any such meeting.
>
> What technical flaws are you trying to point out exactly? (The TX
> flags field? My point is that it's worthless to "standardize" TX flags
> by extending it and moving to "Defined fields" if noone is willing to
> implement it.)
But people are already implementing it, and if they do something else
that's their problem. The flaw I'm thinking of was over the RTS/CTS
handling where some people (including myself) had comments. Besides,
you're supposed to make at least two implementations when proposing a
standard field.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Plans for an online meeting regarding Radiotap
From: Gábor Stefanik @ 2009-08-21 14:41 UTC (permalink / raw)
To: Johannes Berg
Cc: Richard Farina, Mike Kershaw, Sam Leffler, Rafael Laufer,
Damien Bergamini, Sepherosa Ziehau, Thomas d'Otreppe,
Dave Young, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <1250865255.4600.6.camel@johannes.local>
2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2009-08-21 at 16:31 +0200, Gábor Stefanik wrote:
>
>> Hope to see you on Freenode at the set date. Again, if the time is a
>> problem, respond, and I will try to find a better time.
>
> I don't think there's any need to have an IRC meeting. We've hashed out
> the way forward multiple times on the radiotap list. What is missing now
> isn't a consensus of how do things, but proposals and implementations.
My intention with the meeting is to form an actual proposal that all
implementors can agree on. We can produce proposals, and even new
standardized fields to no avail, as some implementors (especially
OpenBSD) appear to be stuck with implementations that collide with the
standard. These implementors need to be "awakened" and entered into
the discussions before anything can be done.
>
> Your own proposal had technical flaws (and in my opinion tried to do too
> much at a time) that you haven't addressed -- doing that would be much
> more productive than any such meeting.
What technical flaws are you trying to point out exactly? (The TX
flags field? My point is that it's worthless to "standardize" TX flags
by extending it and moving to "Defined fields" if noone is willing to
implement it.)
>
> johannes
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH] libertas: clean up and clarify get_common_rates
From: Dan Williams @ 2009-08-21 14:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Andrey Yurovsky, John W. Linville, Roel Kluin
Clarify what the heck the function is doing with better variable names
and less indirection and better comments. Also ensure callers use the
proper minimum size, even though all rates arrays should be size
MAX_RATES anyway. Reverts part of Andrey's dynamic alloc patch since we
don't really need it. Also leaves the passed-in rates array alone on
errors.
Signed-off-by: Dan Williams <dcbw@redhat.com>
diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index e9b2731..bf16212 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -35,7 +35,8 @@ static const u8 bssid_off[ETH_ALEN] __attribute__ ((aligned (2))) =
*
* @param priv A pointer to struct lbs_private structure
* @param rates the buffer which keeps input and output
- * @param rates_size the size of rate1 buffer; new size of buffer on return
+ * @param rates_size the size of rates buffer; new size of buffer on return,
+ * which will be less than or equal to original rates_size
*
* @return 0 on success, or -1 on error
*/
@@ -43,46 +44,41 @@ static int get_common_rates(struct lbs_private *priv,
u8 *rates,
u16 *rates_size)
{
- u8 *card_rates = lbs_bg_rates;
int i, j;
- u8 *tmp;
- size_t tmp_size = 0;
+ u8 intersection[MAX_RATES];
+ u16 intersection_size;
+ u16 num_rates = 0;
- tmp = kzalloc(MAX_RATES * ARRAY_SIZE(lbs_bg_rates), GFP_KERNEL);
- if (!tmp)
- return -1;
+ intersection_size = min_t(u16, *rates_size, ARRAY_SIZE(intersection));
- /* For each rate in card_rates that exists in rate1, copy to tmp */
- for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && card_rates[i]; i++) {
- for (j = 0; j < *rates_size && rates[j]; j++) {
- if (rates[j] == card_rates[i])
- tmp[tmp_size++] = card_rates[i];
- }
- }
+ /* Allow each rate from 'rates' that is supported by the hardware */
+ for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && lbs_bg_rates[i]; i++) {
+ for (j = 0; j < intersection_size && rates[j]; j++) {
+ if (rates[j] == lbs_bg_rates[i])
+ intersection[num_rates++] = rates[j];
+ }
+ }
lbs_deb_hex(LBS_DEB_JOIN, "AP rates ", rates, *rates_size);
- lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates,
+ lbs_deb_hex(LBS_DEB_JOIN, "card rates ", lbs_bg_rates,
ARRAY_SIZE(lbs_bg_rates));
- lbs_deb_hex(LBS_DEB_JOIN, "common rates", tmp, tmp_size);
+ lbs_deb_hex(LBS_DEB_JOIN, "common rates", intersection, num_rates);
lbs_deb_join("TX data rate 0x%02x\n", priv->cur_rate);
- memset(rates, 0, *rates_size);
- *rates_size = min_t(u16, tmp_size, *rates_size);
- memcpy(rates, tmp, *rates_size);
-
if (!priv->enablehwauto) {
- for (i = 0; i < tmp_size; i++) {
- if (tmp[i] == priv->cur_rate)
- break;
- }
- if (i == tmp_size) {
- lbs_pr_alert("Previously set fixed data rate %#x isn't "
- "compatible with the network.\n",
- priv->cur_rate);
- return -1;
+ for (i = 0; i < num_rates; i++) {
+ if (intersection[i] == priv->cur_rate)
+ goto done;
}
+ lbs_pr_alert("Previously set fixed data rate %#x isn't "
+ "compatible with the network.\n", priv->cur_rate);
+ return -1;
}
- kfree(tmp);
+
+done:
+ memset(rates, 0, *rates_size);
+ *rates_size = num_rates;
+ memcpy(rates, intersection, num_rates);
return 0;
}
@@ -325,7 +321,7 @@ static int lbs_associate(struct lbs_private *priv,
rates = (struct mrvl_ie_rates_param_set *) pos;
rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
- tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
+ tmplen = min_t(u16, ARRAY_SIZE(bss->rates), MAX_RATES);
memcpy(&rates->rates, &bss->rates, tmplen);
if (get_common_rates(priv, rates->rates, &tmplen)) {
ret = -1;
@@ -600,7 +596,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
/* Copy Data rates from the rates recorded in scan response */
memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
- ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
+ ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), ARRAY_SIZE (bss->rates));
memcpy(cmd.bss.rates, bss->rates, ratesize);
if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.\n");
^ permalink raw reply related
* Re: Plans for an online meeting regarding Radiotap
From: Johannes Berg @ 2009-08-21 14:34 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Richard Farina, Mike Kershaw, Sam Leffler, Rafael Laufer,
Damien Bergamini, Sepherosa Ziehau, Thomas d'Otreppe,
Dave Young, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <4A8EAFA6.9010608@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 614 bytes --]
On Fri, 2009-08-21 at 16:31 +0200, Gábor Stefanik wrote:
> Hope to see you on Freenode at the set date. Again, if the time is a
> problem, respond, and I will try to find a better time.
I don't think there's any need to have an IRC meeting. We've hashed out
the way forward multiple times on the radiotap list. What is missing now
isn't a consensus of how do things, but proposals and implementations.
Your own proposal had technical flaws (and in my opinion tried to do too
much at a time) that you haven't addressed -- doing that would be much
more productive than any such meeting.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Plans for an online meeting regarding Radiotap
From: Gábor Stefanik @ 2009-08-21 14:31 UTC (permalink / raw)
To: Johannes Berg, Richard Farina, Mike Kershaw, Sam Leffler,
Rafael Laufer, Damien Bergamini, Sepherosa Ziehau,
Thomas d'Otreppe, Dave Young
Cc: radiotap, linux-wireless, freebsd-mobile, misc-openbsd,
tech-openbsd, netbsd-net, wireshark-dev
Radiotap is a de-facto standard for 802.11 frame injection and reception.
Up to field ID 13, it can truly considered a standard (all current
implementations
agree on fields 1-13), but after that, implementations diverge widely.
Here is a map of how current implementations define field IDs 14 and up:
Linux (both mac80211 & madwifi, not sure about libertas) & NetBSD:
Field 14: RX flags (standardized field)
Field 15: TX flags
Field 16: RTS retries
Field 17: Data retries
FreeBSD:
Fields 14...17 skipped (incliding standardized field 14), field 18:
Extended channel
OpenBSD:
Field 14: FCS of the frame (clashes with standard - field 14 is defined
as RX flags!)
Field 15: Hardware queue
Field 16: RSSI
DragonFly BSD: No fields above 13 implemented.
Aircrack-ng:
Field 14: RX flags (as in the standard)
Field 15: TX flags
CACE AirPcap software:
Field 14: FCS of the frame (clashes with standard; the FCS is also appended
to the end of the packet, so this usage is unneeded)
Wireshark:
Field 14: RX flags, with option to decode FCS instead
Fields 15...17 skipped
Field 18: Extended channel
Radiotap fields 14 and up need to be sorted out to allow further
advancements
of the standard. In the current state, essentially no fields can be
added without
risking a collision between implementations. To remedy this, I would
like to propose
an online mini-summit to be held on Freenode, with the goal of defining
a standard
way to use fields 14 and up.
The summit is to be held in IRC channel #radiotap, where interested
parties can join
the discussion and propose changes. My preferred time for this event is
August 25, 2009, 18:00 GMT; please let me know if this date is
unsuitable for any of
you, and I will try to find a better time for the summit when everyone
interested can attend.
My current proposal for the future standard field ordering beyond field 14:
Field 14: RX flags (as defined by the standard)
Field 15: TX flags (as used by Linux, NetBSD and aircrack-ng)
Field 16: RTS retry count (as used by Linux and NetBSD)
Field 17: Data retry count (as used by Linux and NetBSD)
Field 18: Extended channel (as used by FreeBSD and Wireshark)
Field 19: RSSI (OpenBSD's field 16 moved to field ID 19 to avoid collisions)
In addition, the following new fields may be worth addition to the standard:
RTS threshold, Fragmentation threshold, Extended rate (with MCS index
support).
I'm deliberately not assigning field numbers to these proposed fields
yet to prevent
early, divergent implementations of them; the field IDs for these should
be decided
during the summit.
I'm for dropping the following fields, please let me know during the summit
if there are any use cases for them:
-FCS of the frame (if we have FCS data, then it should be appended to the
end of the frame, not put into the header)
-Hardware queue (I don't see the point of this... maybe a full QoS
control field
would be needed instead)
Hope to see you on Freenode at the set date. Again, if the time is a
problem,
respond, and I will try to find a better time.
Sincerely,
Gábor Stefanik <netrolller.3d@gmail.com>
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Bob Copeland @ 2009-08-21 14:19 UTC (permalink / raw)
To: Fabio Comolli; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b6c5339f0908191442j6b5733f3rb28967060abdbace@mail.gmail.com>
On Wed, Aug 19, 2009 at 5:42 PM, Bob Copeland<me@bobcopeland.com> wrote:
> On Wed, Aug 19, 2009 at 4:47 PM, Fabio Comolli<fabio.comolli@gmail.com> wrote:
>> Hi all.
>> I see the following warning on an eeePC 900 (AR5001) running
>> 2.6.31-rc6 after a suspend/resume cycle:
>>
>> [ 292.377941] ------------[ cut here ]------------
>> [ 292.377976] WARNING: at net/mac80211/mlme.c:2292
>> ieee80211_sta_work+0x89/0xc39 [mac80211]()
>
> if (WARN_ON(local->suspended)) ...
Okay, I think I see what is going on here.
suspend
ieee80211_scan_cancel
ieee80211_notify_scan_completed
ieee80211_mlme_scan_completed
ieee80211_ibss_scan_completed
ieee80211_mesh_scan_completed
All of these completed() notifications queue work. That's not a problem
because we flush the workqueue shortly thereafter. However, flushing the
workqueue runs the scheduled work, which can queue _more_ work (sometimes
on a timer with queue_delayed_work), and none of the work functions in
2.6.31 currently check for local->quiesced.
Repeat this process once more and we eventually hit the warning.
Can we just replace the last flush_workqueue() with cancel_delayed_work_sync()
or will that break something?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] mac80211: Remove unnused throughput field from minstrel_rate.
From: Arnd Hannemann @ 2009-08-21 14:11 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Arnd Hannemann
I noticed that the throughput field of the minstrel_rate struct is never used,
so remove it.
Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
---
net/mac80211/rc80211_minstrel.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index 869fe0e..38bf416 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -33,7 +33,6 @@ struct minstrel_rate {
/* per-rate throughput */
u32 cur_tp;
- u32 throughput;
u64 succ_hist;
u64 att_hist;
--
1.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox