Re: [Madwifi-users] kernel panic in presence of updated Cisco 1231 APs

[John C. <jc...@me...>]

Konstantin KABASSANOV wrote:

>Hello,
>
>I updated the firmware of my Cisco wireless AP to its current version. In
>particular it allows multiple BSSID. So I have an open (not encrypted and
>broadcasted) ssid and another one with encryption and not broadcasted with
>different BSSID.
>
>The problem is that now all my linux boxes using atheros driver crash...
>Here you can find the manually copied trace:
>
>Ath_rate_newstate+0x3d/0xac [ath_rate_onoe]
>Ath_newstate+0x1ba/0x312 [ath_pci]
>Ieee80211_recv_mgmt+0x1875/0x18e8 
>


I have had a problem with the 'onoe' rate control function. Below is my 
last detailed post on the
subject. Basically the rate adjustment function is given an argument 
'rate' and then a series of tables
are used to find the actual rate value to send to the HAL. During this 
process, in my case, an unitialized
index, indicated by the value '0xFF' is used to index into the next 
level of tables. This causes the address
that is calculated to go off the end of a kernel page, causing a kernel 
panic.

My 'quick fix' was:
diff -r onoe/onoe.c 
/projects/kernel/madwifi-bsd-cvs-20050425/ath_rate/onoe/onoe.c
217a218,220
 >
 > /* XXXX */    if ( on->on_tx_rix0 >= 32 ) goto done;
 >
219d221
<

But I have not had time to investigate further and find why the initial 
rs_rate table which normally has a number
of entries, becomes reduce to essentially the rates available to 11b 
(initially it seems to have the rates associated
with 11g).

John Clark wrote:

 > John Clark wrote:
 >
 > I added an additional printk argument to print out:
 >
 > ni->ni_rates.rs_nrates
 >
 > I presume this should be the number of 'valid' rates. In the case where
 > a value of 0xff is selected, 'rs_nrates' is 4, while the 'rate' to 
select is 8.
 >
 > This indicates that 1) an illegal rate is calculated, 8, and then 
used as an
 > index in to rs_rates incorrectly. 2) there should be more than 4 
elements in
 > rs_rates, but for some reason is only filled to 4.
 >
 > The dump of the array, rs_rates, suggests that it is in fact only 
filled with for
 > non-zero values, and so rs_nrates is correct.
 >
 > Unfortunately I don't have time this week to go further in finding 
out exactly why
 > there's a mismatch in number of rs_rates, relative to the rate index 
used to update
 > the rate used.
 >
 > John
 >
 >
 >> ------------------ dump of rate arrays and the values for some of 
the indices used -----------------
 >>
 >> rate = 8
 >> (ni->ni_rates.rs_rates[rate] & IEEE80211_RATE_VAL) = 0
 >> (on->on_tx_rix0) = ff
 >>
 >> rs_rates:: 000f
 >> 82 84 8b 96 00 00 00 00 -- 00 00 00 00 00 00 00 00 !................!
 >>
 >> sc_rixmap:: 0100
 >> ff ff 00 ff 01 ff ff ff -- ff ff ff 02 04 ff ff ff !................!
 >> ff ff 05 ff ff ff 03 ff -- 06 ff ff ff ff ff ff ff !................!
 >> ff ff ff ff 07 ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> 08 ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- 09 ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> 0a ff ff ff ff ff ff ff -- ff ff ff ff 0b ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >> ff ff ff ff ff ff ff ff -- ff ff ff ff ff ff ff ff !................!
 >>