[PATCH 1/2] p2p: disable 11b rates only on p2p interface creation
j at w1.fi
Sat Oct 29 16:18:50 EDT 2011
On Thu, Oct 20, 2011 at 03:11:09PM +0200, Johannes Berg wrote:
> On Thu, 2011-10-20 at 18:35 +0530, Rajkumar Manoharan wrote:
> > > I just don't think it's reasonable to prevent this from working when
> > > it's really just an ath9k_htc bug? Not sure ...
> > >
> > So I thought of exporting driver caps to wpa_s to disable 11b at init.
> > so we do not break existing p2p functionality for split drivers. Am i right?
> I'd be more inclined to try to find a workaround in the driver.
I think I have to agree with this. Adding a new capability and the
extra code as a temporary workaround does not sound justified when we
can as well change the driver to just enforce whatever rules it needs to
for P2P operations. It is not like we already have such a capability
advertisement in the current nl80211 implementation, so either approach
would result in kernel code changes.
I changed wpa_supplicant to disable IEEE 802.11b rates based on iftype
to fix the issue where IEEE 802.11b APs could not be used with builds
that enable P2P support. The no-CCK rule is indicated both with scan
request commands and management frame TX commands for the interface that
may be used both for non-P2P and P2P management operations.
If someone wants to implement a temporary user space workaround for P2P,
iw can be used for this, i.e., just run "iw dev wlan0 set bitrates
legacy-2.4 6 9 12 18 24 36 48 54" before using P2P operations.
If a driver is unable to implement the per-scan and per-management frame
TX flag for no-CCK rates, a workaround in the driver (or firmware
change) looks like a reasonable approach to handle this since mac80211
does not have a concept of a P2P mode management interface.
wpa_supplicant supports such design, but even in that case, it is up to
the driver (or firmware) to decide when CCK rates should be disabled.
Jouni Malinen PGP id EFC895FA
More information about the HostAP