Hello!
My iwl3945 device cannot associate to Linksys BEFW11S4. The AP reports
code 18 (unsupported rates).
I tried the current master branch from iwlwifi repository with the
current wireless-2.6/everything kernel patched by mac80211 10.0.0, and
it still exhibits the problem.
It turns out the driver sends CCK rates as extended and OFDM rates as
"non-extended":
Tagged parameters (23 bytes)
SSID parameter set: "WTEST"
Tag Number: 0 (SSID parameter set)
Tag length: 5
Tag interpretation: WTEST
Supported Rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
Tag Number: 1 (Supported Rates)
Tag length: 8
Tag interpretation: Supported rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 [Mbit/sec]
Extended Supported Rates: 1.0 2.0 5.5 11.0
Tag Number: 50 (Extended Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
The association request captured by WireShark is attached.
I tried swapping WLAN_EID_SUPP_RATES and WLAN_EID_EXT_SUPP_RATES in the
sources, but it didn't work. Maybe mac80211 rewrites the request, I
don't know.
Also, iwl3945 refuses to scan more than several times, and the only
workaround is to reload the module. Maybe the association failure
triggers that. If it's not a known problem, I can look closer.
--
Regards,
Pavel Roskin
Pavel Roskin wrote:
> Hello!
>
> My iwl3945 device cannot associate to Linksys BEFW11S4. The AP reports
> code 18 (unsupported rates).
>
> I tried the current master branch from iwlwifi repository with the
> current wireless-2.6/everything kernel patched by mac80211 10.0.0, and
> it still exhibits the problem.
>
> It turns out the driver sends CCK rates as extended and OFDM rates as
> "non-extended":
>
> Tagged parameters (23 bytes)
> SSID parameter set: "WTEST"
> Tag Number: 0 (SSID parameter set)
> Tag length: 5
> Tag interpretation: WTEST
> Supported Rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
> Tag Number: 1 (Supported Rates)
> Tag length: 8
> Tag interpretation: Supported rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 [Mbit/sec]
> Extended Supported Rates: 1.0 2.0 5.5 11.0
> Tag Number: 50 (Extended Supported Rates)
> Tag length: 4
> Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
>
> The association request captured by WireShark is attached.
>
> I tried swapping WLAN_EID_SUPP_RATES and WLAN_EID_EXT_SUPP_RATES in the
> sources, but it didn't work. Maybe mac80211 rewrites the request, I
> don't know.
>
> Also, iwl3945 refuses to scan more than several times, and the only
> workaround is to reload the module. Maybe the association failure
> triggers that. If it's not a known problem, I can look closer.
Using the latest git pull from Linus, I am able to associate with my BEFW11S4 AP using the b43
driver. The problem is probably not in mac80211.
Larry
On Mon, 2007-10-29 at 13:31 -0700, mabbas wrote:
> This might break rate scaling for 3945 adapter.
Yeah I was just going to say the same, the rate scaling is a bit
awkward.
> I look into rearrange
> the rate and do what ever needed to make rate scaling wont break.
Thanks.
johannes
> With disable_hw_scan=1, probe requests have the same problem as the
> association requests, namely they don't have CCK rates in the supported
> rates:
This is because mac80211 uses the order in which the rates are
registered, and with iwlwifi that is "OFDM, CCK". See
iwl_init_hw_rates() and iwl_init_geos().
I can't find any ordering requirement in the 802.11 documents but I
suppose the lower rates should be in the supported rates (rather than
the extended) element.
I'll keep this in mind for the pending redesign of the rate/mode
registration code; for now I suggest to change the registration order to
be "CCK, OFDM" in the driver, since there are only four CCK rates this
will work even with old APs that don't parse the "extended supported
rates" element.
All other drivers in wireless-2.6#everything behave that way, i.e. they
register CCK rates first and then OFDM rates, thus they can never run
into this problem; this explains why it works for Larry with b43.
dragoran: reproducing with a new AP will be futile since it will parse
the extended supported rates element even in backwards B compatible
mode, to reproduce you need, as far as I understand this problem, an AP
that doesn't understand that element yet.
johannes
Pavel Roskin wrote:
> On Sat, 2007-10-20 at 10:21 +0200, dragoran wrote:
>
>
>>> I don't know why iwl3945 composes the association request on its own
>>> and what happens to it later. Besides, mac80211 10.0.0 is something
>>> heavily patched by Intel AFAIK. I wanted to test the git version of
>>> Intel mac80211, but intellinuxwireless.org appears to be down or
>>> unreachable at the moment and I didn't have a recent clone. The
>>> kernel mac80211 is definitely not the suspect.
>>>
>>> I was aware of "error 18", and when I noticed some activity about
>>> rates in wireless-2.6/everything, so I decided to see how that problem
>>> would be affected.
>>>
>>>
>> does loading the module with disable_hw_scan=1 helps?
>>
>
> Sorry for delay. disable_hw_scan=1 makes no difference for association
> requests. However, it has the opposite effect on the probe requests.
> With disable_hw_scan=1, probe requests have the same problem as the
> association requests, namely they don't have CCK rates in the supported
> rates:
>
I tryed to reproduce it here using a wrt54gl. I switched it to "B only"
and was able to acciotate using iwl3945.
iwconfig was reporting 54Mb/s but that seems wrong I did a test with
iperf and got this:
0.0-10.1 sec 11.2 MBytes 9.31 Mbits/sec (=< 11Mb/s)
(also the scan result only reported 1, 2, 5.5 and 11
than I switched back to mixed mode, scan result showed the G rates too
and I did a iperf again and got:
0.0-10.1 sec 20.6 MBytes 17.2 Mbits/sec (> 11Mb/s)
(in both cases using WEP + broadcast ssid + ~50cm distance to AP, driver
version 1.1.17d; 2.6.23.1-10.fc7)
Can you tell me how you captured the assoc request using wireshark? I am
only able to capture the dhcp traffic but not the assoc request itself.
This might break rate scaling for 3945 adapter. I look into rearrange
the rate and do what ever needed to make rate scaling wont break.
Mohamed
dragoran wrote:
> On 10/29/07, Johannes Berg <[email protected]> wrote:
>
>>> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>> @@ -5414,10 +5414,10 @@ static int iwl_init_geos(struct iwl_priv *priv)
>>> * is supported by a mode -- and the first match is taken
>>> */
>>>
>>> - if (modes[G].num_channels)
>>> - ieee80211_register_hwmode(priv->hw, &modes[G]);
>>> if (modes[B].num_channels)
>>> ieee80211_register_hwmode(priv->hw, &modes[B]);
>>> + if (modes[G].num_channels)
>>> + ieee80211_register_hwmode(priv->hw, &modes[G]);
>>> if (modes[A].num_channels)
>>> ieee80211_register_hwmode(priv->hw, &modes[A]);
>>>
>> Huh no, you misunderstood my mail.
>>
>> This makes mac80211 always select 802.11B mode which is not what you
>> want. You want to change the order of rates within the G mode.
>>
>>
>
> shouldn't this one do it?
> (untested)
>
> ---
> diff --git a/origin/iwl-3945-rs.h b/origin/iwl-3945-rs.h
> index 09fa1a7..18b19a2 100644
> --- a/origin/iwl-3945-rs.h
> +++ b/origin/iwl-3945-rs.h
> @@ -39,7 +39,11 @@ struct iwl_rate_info {
> };
>
> enum {
> - IWL_RATE_6M_INDEX = 0,
> + IWL_RATE_1M_INDEX = 0,
> + IWL_RATE_2M_INDEX,
> + IWL_RATE_5M_INDEX,
> + IWL_RATE_11M_INDEX,
> + IWL_RATE_6M_INDEX,
> IWL_RATE_9M_INDEX,
> IWL_RATE_12M_INDEX,
> IWL_RATE_18M_INDEX,
> @@ -47,10 +51,6 @@ enum {
> IWL_RATE_36M_INDEX,
> IWL_RATE_48M_INDEX,
> IWL_RATE_54M_INDEX,
> - IWL_RATE_1M_INDEX,
> - IWL_RATE_2M_INDEX,
> - IWL_RATE_5M_INDEX,
> - IWL_RATE_11M_INDEX,
> IWL_RATE_COUNT,
> IWL_RATE_INVM_INDEX,
> IWL_RATE_INVALID = IWL_RATE_INVM_INDEX
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ipw3945-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
On Mon, 2007-10-29 at 15:12 +0100, Johannes Berg wrote:
> > With disable_hw_scan=1, probe requests have the same problem as the
> > association requests, namely they don't have CCK rates in the supported
> > rates:
>
> This is because mac80211 uses the order in which the rates are
> registered, and with iwlwifi that is "OFDM, CCK". See
> iwl_init_hw_rates() and iwl_init_geos().
Yes, it's working now! Thank you! That's the patch I actually applied:
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -5414,10 +5414,10 @@ static int iwl_init_geos(struct iwl_priv *priv)
* is supported by a mode -- and the first match is taken
*/
- if (modes[G].num_channels)
- ieee80211_register_hwmode(priv->hw, &modes[G]);
if (modes[B].num_channels)
ieee80211_register_hwmode(priv->hw, &modes[B]);
+ if (modes[G].num_channels)
+ ieee80211_register_hwmode(priv->hw, &modes[G]);
if (modes[A].num_channels)
ieee80211_register_hwmode(priv->hw, &modes[A]);
Should I submit it formally?
--
Regards,
Pavel Roskin
Quoting Larry Finger <[email protected]>:
> Using the latest git pull from Linus, I am able to associate with my
> BEFW11S4 AP using the b43
> driver. The problem is probably not in mac80211.
Sorry, I should have mentioned that. I tested bcm43xx-mac80211 from
the latest Fedora 7 kernel and it was fine with that router. ath5k
from wireless-2.6/everything was also fine. Current MadWifi is fine.
Current at76_usb (not mac80211 based yet) is fine. It's only the
Intel 3945 card that has problems with it.
I don't know why iwl3945 composes the association request on its own
and what happens to it later. Besides, mac80211 10.0.0 is something
heavily patched by Intel AFAIK. I wanted to test the git version of
Intel mac80211, but intellinuxwireless.org appears to be down or
unreachable at the moment and I didn't have a recent clone. The
kernel mac80211 is definitely not the suspect.
I was aware of "error 18", and when I noticed some activity about
rates in wireless-2.6/everything, so I decided to see how that problem
would be affected.
--
Regards,
Pavel Roskin
Pavel Roskin wrote:
> Quoting Larry Finger <[email protected]>:
>
>> Using the latest git pull from Linus, I am able to associate with my
>> BEFW11S4 AP using the b43
>> driver. The problem is probably not in mac80211.
>
> Sorry, I should have mentioned that. I tested bcm43xx-mac80211 from
> the latest Fedora 7 kernel and it was fine with that router. ath5k
> from wireless-2.6/everything was also fine. Current MadWifi is fine.
> Current at76_usb (not mac80211 based yet) is fine. It's only the
> Intel 3945 card that has problems with it.
>
> I don't know why iwl3945 composes the association request on its own
> and what happens to it later. Besides, mac80211 10.0.0 is something
> heavily patched by Intel AFAIK. I wanted to test the git version of
> Intel mac80211, but intellinuxwireless.org appears to be down or
> unreachable at the moment and I didn't have a recent clone. The
> kernel mac80211 is definitely not the suspect.
>
> I was aware of "error 18", and when I noticed some activity about
> rates in wireless-2.6/everything, so I decided to see how that problem
> would be affected.
>
does loading the module with disable_hw_scan=1 helps?
Quoting dragoran <[email protected]>:
> I tryed to reproduce it here using a wrt54gl. I switched it to "B only"
> and was able to acciotate using iwl3945.
I'm not surprised. Newer routers a very likely to understand the
extended rates even in 802.11b. It's not reasonable to dumb them down
as much as to ignore the extended rates.
I disabled the essid broadcast, and I still can reproduce the problem.
> Can you tell me how you captured the assoc request using wireshark? I
> am only able to capture the dhcp traffic but not the assoc request
> itself.
MadWifi captures everything in monitor mode. Please make sure to use
the latest trunk revision with Linux 2.6.24-rc1, which makes sysctl
check failures survivable.
I made a patch to disable OFDM rates, and the everything is working
now. The station associates, dhclient works, I can transfer data.
Actually, I remember that did something similar in bcm43xx_mac80211
several months ago to associate to the same router, so maybe the
problem is in mac80211.
And it's possible that there are different routers with the same model
number. Mine is Linksys BEFW11S4 ver 4, firmware version 1.52.02.
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c
b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 4f22a71..004e57c 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -5343,8 +5343,8 @@ static int iwl_init_geos(struct iwl_priv *priv)
modes[G].mode = MODE_IEEE80211G;
modes[G].channels = channels;
- modes[G].rates = rates;
- modes[G].num_rates = 12; /* OFDM & CCK */
+ modes[G].rates = &rates[8];
+ modes[G].num_rates = 4; /* OFDM & CCK */
modes[G].num_channels = 0;
priv->ieee_channels = channels;
--
Regards,
Pavel Roskin
On 10/29/07, Johannes Berg <[email protected]> wrote:
>
> > --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> > @@ -5414,10 +5414,10 @@ static int iwl_init_geos(struct iwl_priv *priv)
> > * is supported by a mode -- and the first match is taken
> > */
> >
> > - if (modes[G].num_channels)
> > - ieee80211_register_hwmode(priv->hw, &modes[G]);
> > if (modes[B].num_channels)
> > ieee80211_register_hwmode(priv->hw, &modes[B]);
> > + if (modes[G].num_channels)
> > + ieee80211_register_hwmode(priv->hw, &modes[G]);
> > if (modes[A].num_channels)
> > ieee80211_register_hwmode(priv->hw, &modes[A]);
>
> Huh no, you misunderstood my mail.
>
> This makes mac80211 always select 802.11B mode which is not what you
> want. You want to change the order of rates within the G mode.
>
shouldn't this one do it?
(untested)
---
diff --git a/origin/iwl-3945-rs.h b/origin/iwl-3945-rs.h
index 09fa1a7..18b19a2 100644
--- a/origin/iwl-3945-rs.h
+++ b/origin/iwl-3945-rs.h
@@ -39,7 +39,11 @@ struct iwl_rate_info {
};
enum {
- IWL_RATE_6M_INDEX = 0,
+ IWL_RATE_1M_INDEX = 0,
+ IWL_RATE_2M_INDEX,
+ IWL_RATE_5M_INDEX,
+ IWL_RATE_11M_INDEX,
+ IWL_RATE_6M_INDEX,
IWL_RATE_9M_INDEX,
IWL_RATE_12M_INDEX,
IWL_RATE_18M_INDEX,
@@ -47,10 +51,6 @@ enum {
IWL_RATE_36M_INDEX,
IWL_RATE_48M_INDEX,
IWL_RATE_54M_INDEX,
- IWL_RATE_1M_INDEX,
- IWL_RATE_2M_INDEX,
- IWL_RATE_5M_INDEX,
- IWL_RATE_11M_INDEX,
IWL_RATE_COUNT,
IWL_RATE_INVM_INDEX,
IWL_RATE_INVALID = IWL_RATE_INVM_INDEX
One more question: is your ssid hidden? If yes I can try to reproduce
with a hidden ssid.
On Sat, 2007-10-20 at 10:21 +0200, dragoran wrote:
> > I don't know why iwl3945 composes the association request on its own
> > and what happens to it later. Besides, mac80211 10.0.0 is something
> > heavily patched by Intel AFAIK. I wanted to test the git version of
> > Intel mac80211, but intellinuxwireless.org appears to be down or
> > unreachable at the moment and I didn't have a recent clone. The
> > kernel mac80211 is definitely not the suspect.
> >
> > I was aware of "error 18", and when I noticed some activity about
> > rates in wireless-2.6/everything, so I decided to see how that problem
> > would be affected.
> >
> does loading the module with disable_hw_scan=1 helps?
Sorry for delay. disable_hw_scan=1 makes no difference for association
requests. However, it has the opposite effect on the probe requests.
With disable_hw_scan=1, probe requests have the same problem as the
association requests, namely they don't have CCK rates in the supported
rates:
IEEE 802.11
Type/Subtype: Probe Request (0x04)
Frame Control: 0x0040 (Normal)
Version: 0
Type: Management frame (0)
Subtype: 4
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 0
Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
Source address: IntelCor_c8:77:a3 (00:13:02:c8:77:a3)
BSS Id: Broadcast (ff:ff:ff:ff:ff:ff)
Fragment number: 0
Sequence number: 5
Frame check sequence: 0x53ed0507 [correct]
[Good: True]
[Bad: False]
IEEE 802.11 wireless LAN management frame
Tagged parameters (23 bytes)
SSID parameter set: "WTEST"
Tag Number: 0 (SSID parameter set)
Tag length: 5
Tag interpretation: WTEST
Supported Rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
Tag Number: 1 (Supported Rates)
Tag length: 8
Tag interpretation: Supported rates: 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 [Mbit/sec]
Extended Supported Rates: 1.0 2.0 5.5 11.0
Tag Number: 50 (Extended Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 1.0 2.0 5.5 11.0 [Mbit/sec]
What's even worse, the radiotap header (I'm capturing with the current
MadWifi) indicates that the probe request is sent at 6 Mbps. Of course,
the AP doesn't reply, as it's 802.11b only.
Association requests are sent at 5.5 and 6 Mbps. The association
response is sent, but it's still code 18.
I'm using current wireless-2.6/everything now (it identifies itself as
2.6.24-rc1) and the driver from the kernel to avoid any problems with
Intel's mac80211.
--
Regards,
Pavel Roskin
On Sat, 2007-10-20 at 02:14 +0200, Tomas Winkler wrote:
> I've sent a patch that fixes that few days ago.It should be in the
> latest version 1.1.18 ''Fix rate setting in probe request for HW sacn'
> I did test it only with 4965 but it's a same code.
The problem is with association requests, not probe requests. Current
wireless-2.6/everything still has the problem, and if I use
disable_hw_scan=1, probe requests have incorrect rates as well, and they
are sent at 6 Mbps, so 802.11b only APs don't see them.
--
Regards,
Pavel Roskin
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -5414,10 +5414,10 @@ static int iwl_init_geos(struct iwl_priv *priv)
> * is supported by a mode -- and the first match is taken
> */
>
> - if (modes[G].num_channels)
> - ieee80211_register_hwmode(priv->hw, &modes[G]);
> if (modes[B].num_channels)
> ieee80211_register_hwmode(priv->hw, &modes[B]);
> + if (modes[G].num_channels)
> + ieee80211_register_hwmode(priv->hw, &modes[G]);
> if (modes[A].num_channels)
> ieee80211_register_hwmode(priv->hw, &modes[A]);
Huh no, you misunderstood my mail.
This makes mac80211 always select 802.11B mode which is not what you
want. You want to change the order of rates within the G mode.
johannes