To the list,

We (Steve, Bora and me) found something interesting on netbsd with=20
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=20
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 =3D 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.

Thanks,
Dave
---
David E. Hudak, Ph.D.=A0=A0 dhudak@terabeam.com
Terabeam Wireless
525 Metro Place North, Suite 100
Dublin, OH=A0 43017
Office:=A0 614-822-5275
Fax:=A0=A0=A0=A0 614-822-0024
www.terabeam.com