On Sat, 2011-09-17 at 22:54 +0000, Alexander Simon wrote:
> I came to the conclusion that the old patch was way too complicated and
> confusing. Too much cases have to be taken into account when trying to
> homogenize the HT mode.
> I changed the code now that only mode given by iw is considered.
>
> This yields in a way smaller patch and less refactoring as we don't need to
> manipulate the beacon skb and match additionally for HT mode in scan results.
>
> I think it's better that way.
Hmm. 10.3.2.2.2 seems to indicate that HT operation parameters should be
adopted, and 11.14.2 says:
"An HT STA that is a member of an IBSS adopts the value of the Secondary
Channel Offset field in received frames according to the rules in 11.1.4
and shall not transmit a value for the Secondary Channel Offset field
that differs from the most recently adopted value."
Also, are you handling the following?
1. 9.13.3.1: In an IBSS, the HT Protection field is reserved, but
an HT STA shall protect HT transmissions as though the HT
Protection field were set to non-HT mixed mode.
2. In an IBSS, the RIFS Mode field of the HT Operation element is
also reserved, but an HT STA shall operate as though this field
were set to 1.
3. 11.5.1.1: If the initiating STA is an HT STA, is a member of an
IBSS, and has no other existing Block Ack agreement with the
recipient STA, then the initiating STA shall transmit a Probe
Request frame to the recipient STA and shall not transmit an
ADDBA Request frame unless it receives a Probe Response frame
from the recipient within dot11ADDBAFailureTimeout.
I'd like to at least give consideration to standards-compliance and make
it clear where we don't want to be compliant.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
