Johannes Berg wrote:
On Wed, 2012-06-20 at 15:12 +0530, Vivek Natarajan wrote:
For P2P, the operating channel needs to be known before group negotiation starts.
This is true in case of P2P GO or client. It needs a separate p2p command from
wpa_cli to get the acs-based best channel information from the driver.
So .. is there any reason to not do only the second, and then pass that
channel back here instead?
So, what you recommend is, for both AP and P2P GO modes, the logic
should be to request the driver for best channel, then the best
channel information event to be passed to userspace and then starting
the AP/GO mode of operation.
That's what I'm thinking, yes.
The current ath6kl firmware has some limitation for getting this
channel information separately and hence not yet implemented this.
Moreover this needs to be a synchronous operation: to request and get
the event for best channel after a full cycle of channel assessment is
done.
Right, but if you're working on this surely you can do without this
particular patch for now?
The reason I'm talking about this is the channel concurrency framework
that Michal is working on, which would conflict somehow with this I
think.
Hmm.. we should be able to deal with it. I have a couple of ideas:
a) treat ACS AP as a non-fixed channel IBSS (i.e. reserve a single
channel resource); once channel notifications comes in we'd drop
the behaviour
b) trust the driver it won't do anything funny (we already trust it
with channel switch notification)
The a) requires more tricks to be done. Once we run out of channels to
run on we need to either:
1) reject it and leave it to userspace to handle (i.e. retry .start_ap
without ACS)
2) disable ACS implicitly and pick a channel ourselves (we'd need to
do a synthetic channel switch notification to userspace)
3) extend ACS to accept channel list, so we could implicitly reduce it
to channels we're already on (probably involves some nice hackery)
The b) seems to have an issue. Consider the following scenario:
[ no channels are used, max 1 channel concurrency, max 2 APs ]
1. wlan0: .start_ap with ACS
[ driver is starting ACS AP.. ]
2. wlan1: .start_ap on channel 1
[ the driver is probably locked right now
as it needs to complete (1); even if it's not locked
(1) probably can't be influenced by (2) anymore.
once it completes (1) it might end up on channel 6 on wlan0.
this means (2) fails kind of unexpectedly ]
--
Pozdrawiam / Best regards, Michal Kazior.
--
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
