Re: compat-wireless and minstrel

[Adam Wozniak <awozniak@irobot.com>]

I was hoping for more of an "ah-ha!" response. =)

It worked well initially, but when I let it run overnight it fell back 
into that same failure mode.

Derek Smithies wrote:
> Hi,
>
>> Is it possible this is the problem? (note supp_rates is used at the 
>> bottom of the function, outside the "if")
>
> Could be. Did it fix your problem?
>
> Derek.
>
> On Tue, 10 Nov 2009, Adam Wozniak wrote:
>
>> Is it possible this is the problem? (note supp_rates is used at the 
>> bottom of the function, outside the "if")
>>
>> *** a/net/mac80211/ibss.c    2009-11-02 09:11:36.000000000 -0800
>> --- b/net/mac80211/ibss.c    2009-11-10 16:31:46.291563951 -0800
>> ***************
>> *** 246,254 ****
>>     if (!channel || channel->flags & IEEE80211_CHAN_DISABLED)
>>         return;
>>
>>     if (sdata->vif.type == NL80211_IFTYPE_ADHOC && elems->supp_rates &&
>>         memcmp(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN) == 0) {
>> -         supp_rates = ieee80211_sta_get_rates(local, elems, band);
>>
>>         rcu_read_lock();
>>
>> --- 246,255 ----
>>     if (!channel || channel->flags & IEEE80211_CHAN_DISABLED)
>>         return;
>>
>> +     supp_rates = ieee80211_sta_get_rates(local, elems, band);
>> +
>>     if (sdata->vif.type == NL80211_IFTYPE_ADHOC && elems->supp_rates &&
>>         memcmp(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN) == 0) {
>>
>>         rcu_read_lock();
>>
>>
>>
>> Derek Smithies wrote:
>>> Hi,
>>>> Do you know which frames in the mac80211 code are missing this 
>>>> required information?  Or was that conjecture?
>>>
>>> it was mostly conjecture. I had done some work with an earlier pull 
>>> of compat wireless in adhoc. the rates tried by minstrel were bad - 
>>> it was stuck at the slowest rate.
>>>
>>> I too had found that the fix was to adjust the array so that all 
>>> rates were marked as supported.
>>>
>>> Derek
>>>
>>> On Tue, 10 Nov 2009, Adam Wozniak wrote:
>>>
>>>> Reading through the 802.11 spec, it appears to me that "Supported 
>>>> rates" (and "Extended Supported Rates" when number of rates > 8) is 
>>>> REQUIRED for all management frames except authentication, 
>>>> deauthentication, and action frames. (IEEE 802.11-2007, 7.2.3)
>>>>
>>>> Do you know which frames in the mac80211 code are missing this 
>>>> required information?  Or was that conjecture?
>>>>
>>>> Looking at mac80211/tx.c ieee80211_beacon_get_tim, it is not clear 
>>>> to me how (or if) this rate information is being set for ad-hoc 
>>>> beacons.
>>>>
>>>> Derek Smithies wrote:
>>>>> Some management frames don't contain a full report of the rates 
>>>>> supported by the sender.
>>>>> My view is that node A (in this example) is incorrectly 
>>>>> determining that B only supports the 1mb/sec rate. Consequently, 
>>>>> node A fills the rate_supported  array with one rate - 1mb/sec.
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>