From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rodolphe Marques Date: Tue, 06 Jul 2010 13:36:03 +0100 Subject: [ath9k-devel] Questions about virtual managed interfaces. In-Reply-To: <4C322F23.4060002@candelatech.com> References: <4C2C2A05.4020208@candelatech.com> <4C2C94C4.4000706@ua.pt> <4C322F23.4060002@candelatech.com> Message-ID: <4C332333.6020001@ua.pt> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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 > >