David,

Exactly.  Should I file a PR?

Dave

David Young wrote:
> On Tue, Dec 14, 2004 at 07:13:36PM -0500, Dave Hudak wrote:
> 
>>To the list,
>>
>>We (Steve, Bora and me) found something interesting on netbsd with 
>>madwifi...
>>
>>Bora got packet traces of a NetBSD 2.0RC3 802.11b madwifi station
>>associating with a NetBSD 2.0RC3 802.11g madwifi AP.  The station sends
>>an association request to the AP containing extended (802.11g) rates.
>>
>>Steve found in ieee80211_send_mgmt() (in ieee80211_output.c), in the 
>>case where it
>>is sending an association request, it calls ieee80211_add_rates to
>>insert the rate information into the association request it is building
>>up as:
>>        ieee80211_add_rates(frm, &ni->ni_rates);
>>where ni is passed in from ieee80211_newstate() (in ieee80211_proto.c),
>>and ni was assigned with:
>>        ni = ic->ic_bss;
>>
>>HOWEVER, in the probe request case (in ieee80211_send_mgmt() in
>>ieee80211_output.c), ieee80211_add_rates() was called as:
>>        ieee80211_add_rates(frm, &ic->ic_sup_rates[mode]);
>>
>>In this case, it's not using the bss info, but the supported rates for
>>the current mode (11a/b/g).  Now, I don't know if there is a good reason
>>for it to be calling the add_rates function in this different way for
>>association requests than it does for probe requests, but if this seems
>>to be a problem.  We changed the add_rates call in the association
>>request generation to use ic->ic_sup_rates.  Afterwords, the madwifi
>>station sends the appropriate association request.
>>
>>Has anyone seen anything like this before?  It looks like a bug to us.
> 
> 
> Saying that back to you: the station sends its Association Request
> containing the rateset in the AP's Beacon or Probe Response, which is
> wrong; it sends the Probe Request containing its supported rates, which
> is correct.
> 
> Sounds like a bug to me, too.
> 
> Dave
>