iwl3945 lists supported rates backwards

iwl3945 lists supported rates backwards

[Pavel Roskin]

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

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

[-- Attachment #2: iwl3945assocreq --]
[-- Type: application/octet-stream, Size: 121 bytes --]

Re: iwl3945 lists supported rates backwards

[Larry Finger]

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

Re: iwl3945 lists supported rates backwards

[Pavel Roskin]

Quoting Larry Finger <larry.finger@lwfinger.net>:

> 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

Re: iwl3945 lists supported rates backwards

[dragoran]

Pavel Roskin wrote:
> Quoting Larry Finger <larry.finger@lwfinger.net>:
>
>> 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?

Re: iwl3945 lists supported rates backwards

[Pavel Roskin]

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

Re: iwl3945 lists supported rates backwards

[dragoran]

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.

Re: iwl3945 lists supported rates backwards

[Pavel Roskin]

Quoting dragoran <drago01@gmail.com>:

> 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

Re: iwl3945 lists supported rates backwards

[dragoran]

One more question: is your ssid hidden? If yes I can try to reproduce 
with a hidden ssid.

Re: iwl3945 lists supported rates backwards

[Johannes Berg]

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


> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: iwl3945 lists supported rates backwards

[Pavel Roskin]

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

Re: iwl3945 lists supported rates backwards

[Johannes Berg]

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


> --- 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: iwl3945 lists supported rates backwards

[dragoran]

On 10/29/07, Johannes Berg <johannes@sipsolutions.net> 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

Re: [ipw3945-devel] iwl3945 lists supported rates backwards

[mabbas]

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 <johannes@sipsolutions.net> 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
> Ipw3945-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>   

Re: [ipw3945-devel] iwl3945 lists supported rates backwards

[Johannes Berg]

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


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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: iwl3945 lists supported rates backwards

[Pavel Roskin]

Quoting Tomas Winkler <tomasw@gmail.com>:

> 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.

Yes, my copy of the repository has that.  It's the most recent commit.  
  And that patch is already in wireless-2.6/everything, because I  
tried to apply it manually and got a message that it's already applied.

I'm away from that router, but I remember that I checked carefully  
that I was testing the right driver.  Either I did something wrong  
anyway, or the fix for the rates was incomplete.

-- 
Regards,
Pavel Roskin

Re: iwl3945 lists supported rates backwards

[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