Larry,
> commit c7ab5ef9bcd281135c21b4732c9be779585181be
> Author: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> Date: Wed Oct 29 20:02:12 2008 +0100
>
> b43: implement short slot and basic rate handling
> It seemed unlikely that the short slot handling was the cause, thus I have
> concentrated on the basic rate handling. I found that the returns from
> ieee80211_get_response_rate() were not what I expected. I'm not sure the routine
> is correct; however, the value for "brates" at entry to b43_update_basic_rates()
> is 0xF, thus only the CCK rates are enabled, but sband->n_bitrates is 12, which
> includes all the 802.11g rates.
It doesn't really depend on your supported rates, if your AP says that
only CCK rates are basic rates (you can see that in iw scan output, they
are marked with a *) then they need to be used for response frames, as
per 802.11-2007 9.6 paragraph 7:
To allow the transmitting STA to calculate the contents of the
Duration/ID field, a STA responding to a received frame shall
transmit its Control Response frame (either CTS or ACK), other
than the BlockAck control frame, at the highest rate in the
BSSBasicRateSet parameter that is less than or equal to the rate
of the immediately previous frame in the frame exchange sequence
(as defined in 9.12) and that is of the same modulation class
(see 9.6.1) as the received frame. If no rate contained in the
BSSBasicRateSet parameter meets these conditions, then the
control frame sent in response to a received frame shall be
transmitted at the highest mandatory rate of the PHY that is
less than or equal to the rate of the received frame, and that
is of the same modulation class as the received frame. In
addition, the Control Response frame shall be sent using the
same PHY options as the received frame, unless they conflict
with the requirement to use the BSSBasicRateSet parameter.
Then again, if I read that correctly, we should be checking the
modulation classes, will have to take a closer look at 9.6.1.
> Is b43 missing something needed to set the basic_rates member of struct
> ieee80211_bxx_conf to a more reasonable value when b43_op_bss_info_changed() is
> entered? I think it should be 0xFFF, not 0xF. I have tested with the larger
> value and found that this change did not improve transmit rates.
So you're saying it doesn't help anyway?
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
