Subject: 802.11 association requests in NetBSD 2.0
To: None <tech-net@netbsd.org>
From: David Hudak <dhudak@terabeam.com>
List: tech-net
Date: 12/14/2004 19:48:24
To the list,

(Sorry for the multiple posts if you get them.  My mail app is stupid...)

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

Thanks,
Dave