This set of patches brings in an initial step in adding support for
multiple virtual interfaces into ath9k both at the multi-vif (for
single channel only) and multi-wiphy (virtual radios that can be used
with multiple channels). The patches are on top of the current
wireless-testing tree, the beacon changes from Sujith and a setkey
patch from earlier today.
The first two patches clean up the multi-vif code and prepare the
driver for use of multiple MAC addresses. The third patch starts the
work on the concept of a virtual wiphy/radio (i.e., ath9k will be able
to register multiple "radios" with mac80211, but without mac80211
having to know about multi-channel operations). The fourth patch adds
support for multiple secondary wiphys. The patches 5-13 are completing
and improving the virtual interface operations.
The 14th patch file brings in a simple channel scheduler that is
enough for initial tests, but will be optimized in the future to take
into account various corner cases and different states of each virtual
radio to time the channel changes better.
The final patch in this series adds a debugfs interface that makes it
possible to control the virtual radios (e.g., add a new "radio"). For
now, this is enough to allow initial testing and experiments with the
new virtual wiphy concept. In the future, more official interface
(e.g., an nl80211 command passed through mac80211) is likely to remove
need for a debugfs interface.
Lot of the code here is still quite experimental, but taken into
account how many areas this touches, it would be helpful to get at
least parts of this merged in. I'm not aware of any regressions for
single-interface operations.
There are still some known limitations for the multi-interface
operations and one should be aware of these when running experiments
with the code. These will be worked on in the future to avoid the
extra complexity or compromises needed in the initial version.
Key cache configuration does not yet handle all combinations of
security policies in virtual interfaces. Consequently, the recommended
starting point is to use software crypto when using multiple
wiphys/vifs, i.e., use nohwcrypt=1 module parameter.
There is currently support for only a single beaconing interface,
i.e., not more than one AP wiphy can be added at a time. There is no
such limitation for station interfaces, i.e., arbitrary number of
virtual station wiphys can be added and used on arbitrary channels.
Though, the simple channel scheduler will start showing up its
simplicity with increased latency if there the wiphys end up on large
number of different channels.
Quick steps to start experiments:
modprobe ath9k nohwcrypt=1
# make sure debugfs is mounted somewhere (replace '/debug' in the
# command below with wherever the root directory is)
# wlan0 can now be used, e.g., with wpa_supplicant
echo add > /debug/ath9k/phy0/wiphy
# wlan1 can now be used, e.g., with wpa_supplicant
echo add > /debug/ath9k/phy0/wiphy
# wlan2 can now be used, e.g., with wpa_supplicant
and so on.. In theory, all the virtual wiphy interfaces could be used
as if they are real radios (run wpa_supplicant, hostapd, use iwconfig,
etc.).
When using virtual wiphys, the APs that the virtual interfaces are
associated with do not need to be on the same channel. One of the
wiphys could also be used with hostapd to bring up an AP. However, it
should be noted that most client implementation do not exactly like
the AP disappearing all the time, so using a virtual station interface
on another channel at the same time may not be that good of an idea
for most use cases now. This will hopefully improve somewhat with
future optimizations.
It would be useful to hear what others think about this sort of
functionality and how this should be integrated with Linux, including
the user space interface, applications managing the virtual interface
functionality, and user interface that the end users would see. This
is still quite an early step in the progress, but the goal here is to
get this functionality into mature state and provide something that
makes it easier to use wireless LAN in general for connecting devices
in various scenarios. All feedback would be welcome!
--
Jouni Malinen PGP id EFC895FA
On Tue, Mar 10, 2009 at 05:43:31AM -0700, Stephen Gutknecht (hilltx) wrote:
> I agree with Florian Fainelli. As a user of ath9k I would love to see
> these patches make it into the driver. I've not seen technical
> complaints of your patches. Time to rebase and get them included? Or
> at least some testing reports?
They went already in into wireless-testing git tree. I would certainly
be interested in see test reports if people are doing some experiments
with the new code. There are still number of areas that can benefit from
optimizations and combinations that do not probably work yet, so it will
be useful to know if these show up in a configuration that someone would
like to use.
--
Jouni Malinen PGP id EFC895FA
On Tue, 2009-03-10 at 19:03 +0200, Jouni Malinen wrote:
> They went already in into wireless-testing git tree. I would certainly
> be interested in see test reports if people are doing some experiments
> with the new code. There are still number of areas that can benefit from
> optimizations and combinations that do not probably work yet, so it will
> be useful to know if these show up in a configuration that someone would
> like to use.
Speaking of which -- has anyone ever tested WDS with mac80211?
johannes
On Sat, 2009-03-07 at 05:56 -0800, Florian Fainelli wrote:
> I am only commenting from a user point of view this feature. This definitively
> is very useful since quite a lot of people stick to madwifi instead of using
> ath5k or ath9k since there was not real support before this patch for virtual
> interfaces.
The set of patches that went in should take care of the virtual station
side. The patch I just sent out will add multi-BSSID support for AP mode
(it will require an update to hostapd, too), so this should provide
support for quite complete set of virtual interface configurations.
> One thing that I did not like with wlanconfig and I would like not to find
> with mac80211/cfg80211 is the incompatibility of some setups (i.e: AP should
> be created first, STA interface later with nosbeacon), not sure this is
> possible, but if it is, one should be able to add a virtual interface without
> knowing the state of the other interfaces before.
The goal is certainly to be able to add and remove virtual interfaces in
any order and at any time. There may be some limitations in the current
version, i.e., something might end up not working, but the configuration
part itself is not prevented. If someone finds a sequence that does not
work, I would hope it can be resolved.
> I really like the way we can create mesh point interfaces with iw, so this
> could be the user interface to configure virtual interfaces, say like this :
>
> iw dev wlan0 interface add sta0 type sta
> iw dev wlan0 interface add ap0 type master
The multi-channel operation with virtual radio (wiphy) is at somewhat
different layer than the mesh interface (vif). Anyway, if nl80211 is
extended with a command that can be used to add a new virtual wiphy,
similar iw command could be added for this use, too. Here standard
commands (iwconfig/wpa_supplicant/hostapd) can change the interface
mode, so it does not need to be specified at wiphy creation time.
As far as multi-BSSID configuration of AP mode on the same channel is
concerned, those virtual interfaces are vifs and hostapd generates them
dynamically using the same mechanism as the iw commands above.
- Jouni
Howdy Jouni,
I agree with Florian Fainelli. As a user of ath9k I would love to see
these patches make it into the driver. I've not seen technical
complaints of your patches. Time to rebase and get them included? Or
at least some testing reports?
I'm sure OpenWrt users would love this.
Hello Jouni,
Le Tuesday 03 March 2009 18:23:25 Jouni Malinen, vous avez =C3=A9crit=C2=
=A0:
> When using virtual wiphys, the APs that the virtual interfaces are
> associated with do not need to be on the same channel. One of the
> wiphys could also be used with hostapd to bring up an AP. However, it
> should be noted that most client implementation do not exactly like
> the AP disappearing all the time, so using a virtual station interfac=
e
> on another channel at the same time may not be that good of an idea
> for most use cases now. This will hopefully improve somewhat with
> future optimizations.
>
>
> It would be useful to hear what others think about this sort of
> functionality and how this should be integrated with Linux, including
> the user space interface, applications managing the virtual interface
> functionality, and user interface that the end users would see. This
> is still quite an early step in the progress, but the goal here is to
> get this functionality into mature state and provide something that
> makes it easier to use wireless LAN in general for connecting devices
> in various scenarios. All feedback would be welcome!
I am only commenting from a user point of view this feature. This defin=
itively=20
is very useful since quite a lot of people stick to madwifi instead of =
using=20
ath5k or ath9k since there was not real support before this patch for v=
irtual=20
interfaces.
One thing that I did not like with wlanconfig and I would like not to f=
ind=20
with mac80211/cfg80211 is the incompatibility of some setups (i.e: AP s=
hould=20
be created first, STA interface later with nosbeacon), not sure this is=
=20
possible, but if it is, one should be able to add a virtual interface w=
ithout=20
knowing the state of the other interfaces before.
I really like the way we can create mesh point interfaces with iw, so t=
his=20
could be the user interface to configure virtual interfaces, say like t=
his :
iw dev wlan0 interface add sta0 type sta
iw dev wlan0 interface add ap0 type master
On a broader perspective, I really hope other drivers will become capab=
le of=20
supporting virtual interfaces as well.
Thank you for your work.
--=20
Best regards, Florian Fainelli
Email : [email protected]
http://openwrt.org
-------------------------------