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

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933