Reported from a user:

- I've noticed that the Supported Rates element starts with an 0x80
octet, which is not valid (it would indicate that support for zero Mbps
is mandatory)

- I think the problem is that the code is passing in the HT BSS
membership selector value (127, HT_PHY) into SupportedRates but
this promptly gets divided by 500k (in AddSupportedRate/SetBasicRate)
so ends up as 0

- I tried to fix that by special-casing values < 128, so that the
SupportedRates element would correctly start with the octet 0xff,
indicating that support for HT was mandatory in the BSS

- However, this promptly caused assertions in mac-low.cc, to do
with the MAC duration (NAV) being less than 0

- Looking at the pcap output, I can indeed see some oddness, specifically
that some control responses (Acks) are being sent at 54 Mbps rather
than 24 Mbps (the highest basic rate) in one direction.  So I think
the problem happens when one end assumes the control response will come
back at 54 Mbps, but it actually comes back at 24 Mbps, taking more time
than allowed by the TXOP holder (in the NAV, i.e. here the Duration field
of the frame sent by the TXOP holder)

- This is where I got stuck.  The presence of a BSS membership selector
(HT_PHY) in the supported rates does not change the basic rate set and
so does not change the rates that are valid for control responses.
Both sides should still be assuming that control responses will come
back at 24 Mbps

So I think there's something wrong with the code which works out the
rate to use for control responses based on the basic rate set, which
in turn comes from the Supported Rates element (and corresponding
object), when the element contains a BSS membership selector.