* [ath9k-devel] Questions about virtual managed interfaces.
@ 2010-07-01 5:39 Ben Greear
2010-07-01 13:14 ` Rodolphe Marques
2010-07-01 13:17 ` pat-lkml
0 siblings, 2 replies; 6+ messages in thread
From: Ben Greear @ 2010-07-01 5:39 UTC (permalink / raw)
To: ath9k-devel
I'm trying to understand the features and limitations of the ath9k
virtual phy and virtual station support. I'm using the 2.6.34 kernel.
First, I was able to create new virtual phys with the
echo add > /debug/ath9k/phy1/wiphy
logic.
That seems to work OK, and a new wlanX interface is created.
The first potential problem I see is that the wlanX interfaces
have the same MAC. A previous post to this list made it appear
that they would be XORd with phy-id or similar to get a unique
MAC?
It does appear that I can set the MAC address using 'ip link set ...', but I'm
not sure if that is the right approach.
I also tried adding new managed interfaces using
iw phy phy1 interface add wlan1-1 type managed
This also seems to work in as far as a new interface is created.
Now, I am curious about configuring these things.
* If I have two managed wlans on the same phy, I assume they must
both be on the same channel? Is there any support in the driver
to make sure that once one interface is associated on a particular
channel that another interface cannot start scanning on different channels
(and thus disrupt the first one)?
In some previous hackings of virtual station interfaces on ath5k, we
had all sorts of issues getting a bunch of interfaces associated
when using wpa-supplicant because one would start scanning and that would
dis-associate the others..over and over.
* If I want, say, 128 virtual station interfaces, does it make sense to try
to use 128 virtual phys, or should I aim at multiple stations per phy?
If anyone has tested the upper limits of how many virtual phys and/or
stations can be supported, I'm interested to know!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread* [ath9k-devel] Questions about virtual managed interfaces. 2010-07-01 5:39 [ath9k-devel] Questions about virtual managed interfaces Ben Greear @ 2010-07-01 13:14 ` Rodolphe Marques 2010-07-05 19:14 ` Ben Greear 2010-07-01 13:17 ` pat-lkml 1 sibling, 1 reply; 6+ messages in thread From: Rodolphe Marques @ 2010-07-01 13:14 UTC (permalink / raw) To: ath9k-devel Hi Ben, I've been doing some work with ath9k virtual interfaces. Well first the MAC is different. It usually differs in the first and last byte. As for having 128 virtual interfaces I think that it is just impossible. For instance the default value for the scheduler is 500ms, which means that if you have 128 virtual interfaces each one will be served for 500ms each 64 seconds. At least I think this is how they work. I have been using only three virtual interfaces in managed mode and it works but the virtual interfaces get dissassociated a lot. Best Regards, Rodolphe Marques On 07/01/2010 06:39 AM, Ben Greear wrote: > I'm trying to understand the features and limitations of the ath9k > virtual phy and virtual station support. I'm using the 2.6.34 kernel. > > First, I was able to create new virtual phys with the > echo add> /debug/ath9k/phy1/wiphy > logic. > > That seems to work OK, and a new wlanX interface is created. > > The first potential problem I see is that the wlanX interfaces > have the same MAC. A previous post to this list made it appear > that they would be XORd with phy-id or similar to get a unique > MAC? > > It does appear that I can set the MAC address using 'ip link set ...', but I'm > not sure if that is the right approach. > > I also tried adding new managed interfaces using > iw phy phy1 interface add wlan1-1 type managed > > This also seems to work in as far as a new interface is created. > > Now, I am curious about configuring these things. > > * If I have two managed wlans on the same phy, I assume they must > both be on the same channel? Is there any support in the driver > to make sure that once one interface is associated on a particular > channel that another interface cannot start scanning on different channels > (and thus disrupt the first one)? > > In some previous hackings of virtual station interfaces on ath5k, we > had all sorts of issues getting a bunch of interfaces associated > when using wpa-supplicant because one would start scanning and that would > dis-associate the others..over and over. > > * If I want, say, 128 virtual station interfaces, does it make sense to try > to use 128 virtual phys, or should I aim at multiple stations per phy? > > If anyone has tested the upper limits of how many virtual phys and/or > stations can be supported, I'm interested to know! > > Thanks, > Ben > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Questions about virtual managed interfaces. 2010-07-01 13:14 ` Rodolphe Marques @ 2010-07-05 19:14 ` Ben Greear 2010-07-06 12:36 ` Rodolphe Marques 0 siblings, 1 reply; 6+ messages in thread From: Ben Greear @ 2010-07-05 19:14 UTC (permalink / raw) To: ath9k-devel On 07/01/2010 06:14 AM, Rodolphe Marques wrote: > Hi Ben, > > I've been doing some work with ath9k virtual interfaces. > Well first the MAC is different. It usually differs in the first and > last byte. How are you reading this MAC? They seem the same everywhere I look. [root at atom ~]# uname -a Linux atom 2.6.35-rc3-wl+ #1 SMP Mon Jul 5 11:36:08 PDT 2010 i686 i686 i386 GNU/Linux [root at atom ~]# ifconfig wlan1 wlan1 Link encap:Ethernet HWaddr 00:0E:8E:20:09:4E UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [root at atom ~]# ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:0E:8E:20:09:4E UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [root at atom ~]# cat /debug/ath9k/phy0/wiphy primary: phy0 (ACTIVE chan=0 ht=0) secondary: phy1 (ACTIVE chan=0 ht=0) secondary: phy2 (INACTIVE chan=0 ht=0) addr: ef:be:ad:de:ef:be addrmask: ef:be:ad:de:ef:be [root at atom ~]# cat /sys/class/ieee80211/phy0/macaddress 00:0e:8e:20:09:4e [root at atom ~]# cat /sys/class/ieee80211/phy1/macaddress 00:0e:8e:20:09:4e [root at atom ~]# cat /sys/class/ieee80211/phy2/macaddress 00:0e:8e:20:09:4e > As for having 128 virtual interfaces I think that it is just impossible. > For instance the default value for the scheduler is 500ms, which means > that if you have 128 virtual interfaces each one will be served for > 500ms each 64 seconds. At least I think this is how they work. > > I have been using only three virtual interfaces in managed mode and it > works but the virtual interfaces get dissassociated a lot. Ok, it would appear to me that the virtual phys are not really so useful for my purposes then. If you have a machine that is easy to power cycle, I'm curious if your system also crashes if you add a virtual phy and then rmmod ath9k (mine crashes every time). Using a somewhat hacked ath5k in 2.6.31 kernel, we were able to support 128+ virtual stations (on a single physical NIC). We basically put it into promisc mode and then added some logic to deal with lots of stations trying to scan and associate at once. (We let the first one win, and after it was associated, the rest of the stations could only scan that one channel). We used software encryption since the chip can't handle more than one set of keys at a time (as far as we could tell). Virtual APs were handled as well, with some logic to deal with lots of beacons. If we can't use lots of virtual phys, then we'll probably need to take the same approach and just use lots of virtual stations on ath9k too. Thanks, Ben > > Best Regards, > Rodolphe Marques > > On 07/01/2010 06:39 AM, Ben Greear wrote: >> I'm trying to understand the features and limitations of the ath9k >> virtual phy and virtual station support. I'm using the 2.6.34 kernel. >> >> First, I was able to create new virtual phys with the >> echo add> /debug/ath9k/phy1/wiphy >> logic. >> >> That seems to work OK, and a new wlanX interface is created. >> >> The first potential problem I see is that the wlanX interfaces >> have the same MAC. A previous post to this list made it appear >> that they would be XORd with phy-id or similar to get a unique >> MAC? >> >> It does appear that I can set the MAC address using 'ip link set ...', but I'm >> not sure if that is the right approach. >> >> I also tried adding new managed interfaces using >> iw phy phy1 interface add wlan1-1 type managed >> >> This also seems to work in as far as a new interface is created. >> >> Now, I am curious about configuring these things. >> >> * If I have two managed wlans on the same phy, I assume they must >> both be on the same channel? Is there any support in the driver >> to make sure that once one interface is associated on a particular >> channel that another interface cannot start scanning on different channels >> (and thus disrupt the first one)? >> >> In some previous hackings of virtual station interfaces on ath5k, we >> had all sorts of issues getting a bunch of interfaces associated >> when using wpa-supplicant because one would start scanning and that would >> dis-associate the others..over and over. >> >> * If I want, say, 128 virtual station interfaces, does it make sense to try >> to use 128 virtual phys, or should I aim at multiple stations per phy? >> >> If anyone has tested the upper limits of how many virtual phys and/or >> stations can be supported, I'm interested to know! >> >> Thanks, >> Ben >> >> > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Questions about virtual managed interfaces. 2010-07-05 19:14 ` Ben Greear @ 2010-07-06 12:36 ` Rodolphe Marques 2010-07-06 16:20 ` Ben Greear 0 siblings, 1 reply; 6+ messages in thread From: Rodolphe Marques @ 2010-07-06 12:36 UTC (permalink / raw) To: ath9k-devel Hi Ben, How are you creating the virtual interfaces? For me the mac addresses appear different for each vif. I haven't updated the drivers in a while so I don't know if something changed in the vif code. BR, Rodolphe Marques On 07/05/2010 08:14 PM, Ben Greear wrote: > On 07/01/2010 06:14 AM, Rodolphe Marques wrote: >> Hi Ben, >> >> I've been doing some work with ath9k virtual interfaces. >> Well first the MAC is different. It usually differs in the first and >> last byte. > > How are you reading this MAC? They seem the same everywhere I look. > > [root at atom ~]# uname -a > Linux atom 2.6.35-rc3-wl+ #1 SMP Mon Jul 5 11:36:08 PDT 2010 i686 i686 > i386 GNU/Linux > > [root at atom ~]# ifconfig wlan1 > wlan1 Link encap:Ethernet HWaddr 00:0E:8E:20:09:4E > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > [root at atom ~]# ifconfig wlan0 > wlan0 Link encap:Ethernet HWaddr 00:0E:8E:20:09:4E > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > [root at atom ~]# cat /debug/ath9k/phy0/wiphy > primary: phy0 (ACTIVE chan=0 ht=0) > secondary: phy1 (ACTIVE chan=0 ht=0) > secondary: phy2 (INACTIVE chan=0 ht=0) > addr: ef:be:ad:de:ef:be > addrmask: ef:be:ad:de:ef:be > > [root at atom ~]# cat /sys/class/ieee80211/phy0/macaddress > 00:0e:8e:20:09:4e > [root at atom ~]# cat /sys/class/ieee80211/phy1/macaddress > 00:0e:8e:20:09:4e > [root at atom ~]# cat /sys/class/ieee80211/phy2/macaddress > 00:0e:8e:20:09:4e > >> As for having 128 virtual interfaces I think that it is just impossible. >> For instance the default value for the scheduler is 500ms, which means >> that if you have 128 virtual interfaces each one will be served for >> 500ms each 64 seconds. At least I think this is how they work. >> >> I have been using only three virtual interfaces in managed mode and it >> works but the virtual interfaces get dissassociated a lot. > > Ok, it would appear to me that the virtual phys are not really so > useful for my purposes then. If you have a machine that is easy to > power cycle, I'm curious if your system also crashes if you add > a virtual phy and then rmmod ath9k (mine crashes every time). > > Using a somewhat hacked ath5k in 2.6.31 kernel, we were able to support > 128+ virtual stations (on a single physical NIC). We basically put it > into > promisc mode and then added some logic to deal with lots of stations > trying to scan and associate at once. (We let the first one win, and > after it was associated, the rest of the stations could only scan that > one channel). We used software encryption since the chip can't handle > more than one set of keys at a time (as far as we could tell). > > Virtual APs were handled as well, with some logic to deal with lots > of beacons. > > If we can't use lots of virtual phys, then we'll probably need to > take the same approach and just use lots of virtual stations on > ath9k too. > > Thanks, > Ben > > > >> >> Best Regards, >> Rodolphe Marques >> >> On 07/01/2010 06:39 AM, Ben Greear wrote: >>> I'm trying to understand the features and limitations of the ath9k >>> virtual phy and virtual station support. I'm using the 2.6.34 kernel. >>> >>> First, I was able to create new virtual phys with the >>> echo add> /debug/ath9k/phy1/wiphy >>> logic. >>> >>> That seems to work OK, and a new wlanX interface is created. >>> >>> The first potential problem I see is that the wlanX interfaces >>> have the same MAC. A previous post to this list made it appear >>> that they would be XORd with phy-id or similar to get a unique >>> MAC? >>> >>> It does appear that I can set the MAC address using 'ip link set >>> ...', but I'm >>> not sure if that is the right approach. >>> >>> I also tried adding new managed interfaces using >>> iw phy phy1 interface add wlan1-1 type managed >>> >>> This also seems to work in as far as a new interface is created. >>> >>> Now, I am curious about configuring these things. >>> >>> * If I have two managed wlans on the same phy, I assume they must >>> both be on the same channel? Is there any support in the driver >>> to make sure that once one interface is associated on a >>> particular >>> channel that another interface cannot start scanning on >>> different channels >>> (and thus disrupt the first one)? >>> >>> In some previous hackings of virtual station interfaces on >>> ath5k, we >>> had all sorts of issues getting a bunch of interfaces associated >>> when using wpa-supplicant because one would start scanning and >>> that would >>> dis-associate the others..over and over. >>> >>> * If I want, say, 128 virtual station interfaces, does it make >>> sense to try >>> to use 128 virtual phys, or should I aim at multiple stations >>> per phy? >>> >>> If anyone has tested the upper limits of how many virtual phys >>> and/or >>> stations can be supported, I'm interested to know! >>> >>> Thanks, >>> Ben >>> >>> >> >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Questions about virtual managed interfaces. 2010-07-06 12:36 ` Rodolphe Marques @ 2010-07-06 16:20 ` Ben Greear 0 siblings, 0 replies; 6+ messages in thread From: Ben Greear @ 2010-07-06 16:20 UTC (permalink / raw) To: ath9k-devel On 07/06/2010 05:36 AM, Rodolphe Marques wrote: > Hi Ben, > > How are you creating the virtual interfaces? > > For me the mac addresses appear different for each vif. > I haven't updated the drivers in a while so I don't know if something > changed in the vif code. I'm just echoing 'add' to the debugfs wiphy file. The code looks like it tries to change the MAC, but it doesn't seem like it really works. If someone is using the latest code and could confirm or deny this, that would help! Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Questions about virtual managed interfaces. 2010-07-01 5:39 [ath9k-devel] Questions about virtual managed interfaces Ben Greear 2010-07-01 13:14 ` Rodolphe Marques @ 2010-07-01 13:17 ` pat-lkml 1 sibling, 0 replies; 6+ messages in thread From: pat-lkml @ 2010-07-01 13:17 UTC (permalink / raw) To: ath9k-devel An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20100701/10799da8/attachment.htm ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-07-06 16:20 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-01 5:39 [ath9k-devel] Questions about virtual managed interfaces Ben Greear 2010-07-01 13:14 ` Rodolphe Marques 2010-07-05 19:14 ` Ben Greear 2010-07-06 12:36 ` Rodolphe Marques 2010-07-06 16:20 ` Ben Greear 2010-07-01 13:17 ` pat-lkml
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.