On 09/15/2010 02:04 PM, Luis R. Rodriguez wrote:
On Wed, Sep 15, 2010 at 1:31 PM, Jouni Malinen<j@xxxxx> wrote:
On Tue, Sep 14, 2010 at 10:30:04PM -0700, Ben Greear wrote:
I think for the multi-VIF scenario, it should scan the single associated
channel by default, but it would be nice to allow full scans on demand.
(I would very much like to work with standard wpa_supplicant, but if hacking it
is the only way, then I can attempt that.)
"Standard wpa_supplicant" needs to become more aware of multiple users
of the same radio, so it is certainly fine to add changes there. For
example, a mechanism for noticing that interfaces are sharing a radio
would be useful. With that, it should also be possible to share the BSS
table and scan results (and requests!) within wpa_supplicant.
Depending on how this is implementing, sharing of the physical radio
may require some kernel synchronization between the different
interfaces using the same radio. It may also be possible to share the
same radio between an 802.11 device and a wimax device, for example.
Long ago we thought up of a frequency broker [1] but never really
wrote it as we have had no usage case for it yet. If we implement the
frequency broker we could also technically add a scheduler to sharing
the same radio between separate interfaces / technologies, this could
just be done in userspace as well, although I am not sure if the
timing considerations for doing it in userspace would suffice.
At least for my use, I hope to be able to fully utilize the bandwidth for
a particular channel, and emulate as close as possible a bunch of wireless
devices sharing an AP or set of APs. So, I don't want to be switching off the main
channel for any significant amount of time. I think as long as you stick
to the main channel, there are no significant scheduling issues with
the hardware, but I could be wrong about that.
Also, I want to be able to run one supplicant per interface, so while
wpa_supplicant could become clever if it manages multiple devices, I
want them to be able to run independently as well.
As for figuring out what hardware a VIF belongs to, you can deduce this
by following links in sysfs to find it's phyX device. It is a pain
when the phyX changes name due to module reload or something, but it can still
be dealt with.
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
