[ath9k-devel] vifs management

[ath9k-devel] vifs management

[João Maurício]

Hi there,

What I'm trying to accomplish is the creation of multiple virtual interfaces
(to use as stations) where I can control which interface is able to transmit
(sending the rest of them into PS mode) at each time (explicitly or using a
scheduler). That said and from what I've been playing, correct me if I'm
wrong, the best way to do it is to use the "echo add > /.../wiphy"
mechanism. However, I wasn't able to make it work, every time that I create
a new interface, none of them (the "original" and the virtual) can get
associated with the AP (I already played around with the pause, unpause,
select, etc..). On the other hand, with the "iw wlan0 interface add ... type
managed" feature, everything seems to work fine, except that I don't know
how to "control" the interfaces transmission timings.

With this in mind, some questions arise:

- Is there anyone out there that can successfully do what I'm trying to
accomplish or that is a "master" using the wiphy mechanism, that can point
me the right direction?? (I really can't figure if I'm doing something
wrong, or if it's my ar9285 chipset problem)

- What's the difference between having two interfaces, wlan0 and wlan1,
"linked" to phy0 ("interface add" way) and having wlan0 "linked" to phy0 and
wlan1 to phy1 (wiphy way)?

- Is it possible to have my desired level of control over the virtual
interfaces, using the "iw wlan0 interface add ... type managed"?

Thanks,

Jo?o Maur?cio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101101/a1465f34/attachment.htm 

[ath9k-devel] vifs management

[Ben Greear]

On 11/01/2010 11:38 AM, Jo?o Maur?cio wrote:
> Hi there,
>
> What I'm trying to accomplish is the creation of multiple virtual
> interfaces (to use as stations) where I can control which interface is
> able to transmit (sending the rest of them into PS mode) at each time
> (explicitly or using a scheduler). That said and from what I've been
> playing, correct me if I'm wrong, the best way to do it is to use the
> "echo add > /.../wiphy" mechanism. However, I wasn't able to make it
> work, every time that I create a new interface, none of them (the
> "original" and the virtual) can get associated with the AP (I already
> played around with the pause, unpause, select, etc..). On the other
> hand, with the "iw wlan0 interface add ... type managed" feature,
> everything seems to work fine, except that I don't know how to "control"
> the interfaces transmission timings.
>
> With this in mind, some questions arise:
>
> - Is there anyone out there that can successfully do what I'm trying to
> accomplish or that is a "master" using the wiphy mechanism, that can
> point me the right direction?? (I really can't figure if I'm doing
> something wrong, or if it's my ar9285 chipset problem)
>
> - What's the difference between having two interfaces, wlan0 and wlan1,
> "linked" to phy0 ("interface add" way) and having wlan0 "linked" to phy0
> and wlan1 to phy1 (wiphy way)?
>
> - Is it possible to have my desired level of control over the virtual
> interfaces, using the "iw wlan0 interface add ... type managed"?

Don't use virtual wiphys if you can help it..it doesn't scale as well
and has some fundamental issues with scheduling physical resources,
and there are ongoing comments about removing this code someday 'soon'.

We have had good luck (assuming you are running the latest code +
the tx-side locking that is yet to make it into wireless-testing)
with creating and using lots of virtual stations on a single
phy.

We are actually disabling PS as that was previously suggested
it might cause problems with multiple interfaces.

Maybe you can explain a bit more about what you are trying to
accomplish with the power-save logic?

Thanks,
Ben

>
> Thanks,
>
> Jo?o Maur?cio
>
>
>
> _______________________________________________
> 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

[ath9k-devel] vifs management

[Peter Stuge]

Ben Greear wrote:
> We are actually disabling PS as that was previously suggested
> it might cause problems with multiple interfaces.

Power saving has caused severe problems also with just a single
interface.


//Peter

[ath9k-devel] vifs management

[João Maurício]

Without PS, how can the client stay associated with each of the different
APs?

What I'm trying to do is create, for instance, 2 vifs, each one associated
to a different AP and manually (or not) control which is "active" at a time.
In my mind, in order to stay associated with the 2 APs without packet loss,
1 of the vifs should send a fake PS=1 frame to its AP and the other should
operate normally. Then, if a "switching order" comes in, the operating vif
should send its own fake PS=1 frame to the corresponding AP and the
"sleeping" one should send a PS=0 frame to its AP, receiving all the
buffered packets.
Isn't that the logic? I'm really getting confused :S.

Ben Greear wrote:
> We have had good luck (assuming you are running the latest code +
> the tx-side locking that is yet to make it into wireless-testing)
> with creating and using lots of virtual stations on a single
> phy.

Yup, I'm running the latest code, but what do you mean about "tx-side
locking"?
Also, I don't want to use lots of virtual stations, I guess that 3 would be
nice.


On Mon, Nov 1, 2010 at 10:59 PM, Peter Stuge <peter@stuge.se> wrote:

> Ben Greear wrote:
> > We are actually disabling PS as that was previously suggested
> > it might cause problems with multiple interfaces.
>
> Power saving has caused severe problems also with just a single
> interface.
>
>
> //Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101102/3cc809fb/attachment-0001.htm 

[ath9k-devel] vifs management

[Ben Greear]

On 11/02/2010 11:43 AM, Jo?o Maur?cio wrote:
> Without PS, how can the client stay associated with each of the
> different APs?
>
> What I'm trying to do is create, for instance, 2 vifs, each one
> associated to a different AP and manually (or not) control which is
> "active" at a time. In my mind, in order to stay associated with the 2
> APs without packet loss, 1 of the vifs should send a fake PS=1 frame to
> its AP and the other should operate normally. Then, if a "switching
> order" comes in, the operating vif should send its own fake PS=1 frame
> to the corresponding AP and the "sleeping" one should send a PS=0 frame
> to its AP, receiving all the buffered packets.
> Isn't that the logic? I'm really getting confused :S.

My method assumes that all your stations will be on the same
frequency.  When that is the case, two different VIFS can communicate
to two different APs concurrently.  You do not have to play any
special tricks.

If you want your VIFs to function on different channels, then you
are going to have to attempt virtual wiphys probably..and my initial
attempt at using them went poorly.

> Ben Greear wrote:
>  > We have had good luck (assuming you are running the latest code +
>  > the tx-side locking that is yet to make it into wireless-testing)
>  > with creating and using lots of virtual stations on a single
>  > phy.
>
> Yup, I'm running the latest code, but what do you mean about "tx-side
> locking"?
> Also, I don't want to use lots of virtual stations, I guess that 3 would
> be nice.

Sure...we've been testing with 100+ to flush out bugs, but a smaller number is certainly
valid.

I'm not sure all of the tx DMA patches are upstream yet, but they should
be there soon.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] vifs management

[João Maurício]

>
> My method assumes that all your stations will be on the same
> frequency.  When that is the case, two different VIFS can communicate
> to two different APs concurrently.  You do not have to play any
> special tricks.
>
> If you want your VIFs to function on different channels, then you
> are going to have to attempt virtual wiphys probably..and my initial
> attempt at using them went poorly.


Ok, I'll try again to make it work with virtual wiphys and report the
outcome later. Shouldn't it be "straightforward" with just 2 virtual
interfaces?? Is there any known major issues (my NIC's chipset is the
ar9285)?

A log with a successful attempt would be marvelous.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101104/4b6953c1/attachment.htm 

[ath9k-devel] vifs management

[João Maurício]

After some testing, I've got the some results as before: when I issue the
"echo add > ... wiphy" command while I'm associated with some AP on wlan0, I
get deassociated after a few seconds. Also, no interface can get associated
before I issue "echo del=phy ... wiphy" until I've just my primary
interface. Long story short, I can't make wiphys work. Any thoughts?

What's the real difference between creating wlan0, wlan1, ... wlanN "based"
on phy0, phy1... phyN and wlan0, wlan1, ..., wlanN always "based" on phy0??

Thanks

2010/11/4 Jo?o Maur?cio <joao.goncalves.mauricio@gmail.com>

>  My method assumes that all your stations will be on the same
>> frequency.  When that is the case, two different VIFS can communicate
>> to two different APs concurrently.  You do not have to play any
>> special tricks.
>>
>> If you want your VIFs to function on different channels, then you
>> are going to have to attempt virtual wiphys probably..and my initial
>> attempt at using them went poorly.
>
>
> Ok, I'll try again to make it work with virtual wiphys and report the
> outcome later. Shouldn't it be "straightforward" with just 2 virtual
> interfaces?? Is there any known major issues (my NIC's chipset is the
> ar9285)?
>
> A log with a successful attempt would be marvelous.
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101107/74c1847f/attachment.htm 

[ath9k-devel] vifs management

[Ben Greear]

On 11/06/2010 05:33 PM, Jo?o Maur?cio wrote:
> After some testing, I've got the some results as before: when I issue the "echo add > ... wiphy" command while I'm associated with some AP on wlan0, I get
> deassociated after a few seconds. Also, no interface can get associated before I issue "echo del=phy ... wiphy" until I've just my primary interface. Long story
> short, I can't make wiphys work. Any thoughts?

There is no way (as far as I know) for a radio to be on two channels at once.  Using
wiphys lets the virtual phys switch every 500ms or so between channels, but that means
any VIF on the other channel cannot do anything useful.

I think that if you need to be on two different channels at the same time you are going
to have to get multiple NICs.

If you put multiple VIFS on the same phy, then they can all work together
without too much interference with each other.  The restriction is that they
must all be on the same channel (scanning on different channels is OK, but
the eventual association must be on the same channel as the other VIFs).

Thanks,
Ben


>
> What's the real difference between creating wlan0, wlan1, ... wlanN "based" on phy0, phy1... phyN and wlan0, wlan1, ..., wlanN always "based" on phy0??
>
> Thanks
>
> 2010/11/4 Jo?o Maur?cio <joao.goncalves.mauricio at gmail.com <mailto:joao.goncalves.mauricio@gmail.com>>
>
>         My method assumes that all your stations will be on the same
>         frequency.  When that is the case, two different VIFS can communicate
>         to two different APs concurrently.  You do not have to play any
>         special tricks.
>
>         If you want your VIFs to function on different channels, then you
>         are going to have to attempt virtual wiphys probably..and my initial
>         attempt at using them went poorly.
>
>
>     Ok, I'll try again to make it work with virtual wiphys and report the outcome later. Shouldn't it be "straightforward" with just 2 virtual interfaces?? Is
>     there any known major issues (my NIC's chipset is the ar9285)?
>
>     A log with a successful attempt would be marvelous.
>
>     Thanks
>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] vifs management

[João Maurício]

Thanks Ben, now I understand! :-)

Anyway, do you know what might be causing my previously described wiphy
problem?

Thanks again.

2010/11/7 Ben Greear <greearb@candelatech.com>

> On 11/06/2010 05:33 PM, Jo?o Maur?cio wrote:
>
>> After some testing, I've got the some results as before: when I issue the
>> "echo add > ... wiphy" command while I'm associated with some AP on wlan0, I
>> get
>> deassociated after a few seconds. Also, no interface can get associated
>> before I issue "echo del=phy ... wiphy" until I've just my primary
>> interface. Long story
>> short, I can't make wiphys work. Any thoughts?
>>
>
> There is no way (as far as I know) for a radio to be on two channels at
> once.  Using
> wiphys lets the virtual phys switch every 500ms or so between channels, but
> that means
> any VIF on the other channel cannot do anything useful.
>
> I think that if you need to be on two different channels at the same time
> you are going
> to have to get multiple NICs.
>
> If you put multiple VIFS on the same phy, then they can all work together
> without too much interference with each other.  The restriction is that
> they
> must all be on the same channel (scanning on different channels is OK, but
> the eventual association must be on the same channel as the other VIFs).
>
> Thanks,
> Ben
>
>
>
>> What's the real difference between creating wlan0, wlan1, ... wlanN
>> "based" on phy0, phy1... phyN and wlan0, wlan1, ..., wlanN always "based" on
>> phy0??
>>
>> Thanks
>>
>> 2010/11/4 Jo?o Maur?cio <joao.goncalves.mauricio@gmail.com <mailto:
>> joao.goncalves.mauricio at gmail.com>>
>>
>>
>>        My method assumes that all your stations will be on the same
>>        frequency.  When that is the case, two different VIFS can
>> communicate
>>        to two different APs concurrently.  You do not have to play any
>>        special tricks.
>>
>>        If you want your VIFs to function on different channels, then you
>>        are going to have to attempt virtual wiphys probably..and my
>> initial
>>        attempt at using them went poorly.
>>
>>
>>    Ok, I'll try again to make it work with virtual wiphys and report the
>> outcome later. Shouldn't it be "straightforward" with just 2 virtual
>> interfaces?? Is
>>    there any known major issues (my NIC's chipset is the ar9285)?
>>
>>    A log with a successful attempt would be marvelous.
>>
>>    Thanks
>>
>>
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101108/7d4c65ab/attachment.htm