On 11/16/2010 02:36 PM, Jouni Malinen wrote:
On Tue, Nov 16, 2010 at 11:57:09AM -0800, Ben Greear wrote:
I earlier attempted to put this sharing/propagation directly into
the kernel (instead of -EBUSY, the kernel would just keep a list of
interested interfaces and then send results to all interested parties).
However, Johannes didn't like this approach, so I'm trying to do a
similar thing in user-space.
Johannes is not the only one having something against the kernel
approach.. ;-)
Well, this is all good for supplicant, but same problem exists for
un-encrypted interfaces that use the built-in kernel scanning. However,
I can carry my own patch if needed..it's still useful to get this
working with supplicant.
My understanding is that you cannot
read scan results from the kernel for one VIF if they were initiated on another
VIF. I might be wrong about that, however. At any rate, you certainly can't
have two VIFS on the same phy scanning at the same time, as you get -EBUSY instead.
That makes wpa_supplicant take a long time to scan& associate lots
of VIFS, and speeding that up is my primary goal at this point.
Hmm.. Maybe I'm missing something in your patch, but it seems to be
doing exactly what you are describing it should not be doing.. It seems
Ok, I think I mis-understood your original question. You can read shared results
from wpa_supplicant data structures..but not directly from the kernel.
to share the scan-done event with all interfaces that are from the same
radio and then each interface would try to read the scan result from
their own VIF which would be different from the one that actually
initiated the scan.. Similarly, I did not notice any changes that would
actually restrict requesting new scans when there is a known scan
request pending on another interface that shares the same radio.
Are these still waiting to be implemented or did I miss something in
your patch? Anyway, they approach in the newer version looked reasonable
to me based on what I believe you are now trying to do.
I wasn't planning to add further restrictions. Currently, other vifs
making requests would get EBUSY, and that seems to be handled fine.
It's *possible* that someday multiple VIFs can scan simultaneously
in the kernel, so I don't think it's worth adding extra checks in supplicant.
One other thing I was worried about: My patch is going to send scan results
to interfaces that have not successfully requested them (they may have not
requested at all, or they may have tried and received EBUSY). Will that be
an issue?
If your assumption above is correct, yes. Instead of sharing the
scan-done event, this change should like share the scan_res from
wpa_supplicant_get_scan_results() for all interfaces sharing the radio.
Something is needed to kick the other VIFs and tell them there are
scan results available. That is why I put the logic in events.c
as I did.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
