2013-12-01 00:09:41

by Drasko DRASKOVIC

[permalink] [raw]
Subject: multi-wiphy (virtual radios that can be used with multiple channels)

Hi all,
can somebody please explain in some more details this possibility of
ath9k driver, mentioned here: http://lwn.net/Articles/321690/ and
specially here:
http://osdir.com/ml/linux-wireless/2009-03/msg00090.html in these
patches signed-off by Jouni.

Does this means that ath9k devices can be put in AP and STA modes
simultaneously (one virtual interface for each) over different
channels?

I am looking to solve this problem: I want to have always present AP
for user settings that I bring on boot, so I give it some
pre-configured channel. Via this AP user will configure other
interface in STA mode to connect to home network. However, this home
network can be over any channel, very potentially different of the one
I have chosen for AP.

Would these patches allow something like this, and how they should be
used (I saw here some use case -
http://www.mail-archive.com/[email protected]/msg03617.html,
but not clear enough)?

Best regards,
Drasko


2013-12-01 00:58:30

by Drasko DRASKOVIC

[permalink] [raw]
Subject: Re: multi-wiphy (virtual radios that can be used with multiple channels)

On Sun, Dec 1, 2013 at 1:27 AM, Sujith Manoharan <[email protected]> wrote:
> Multi Channel Concurrency is required to do this, but ath9k doesn't
> support it right now.

That would imply that HW is capable of doing this, but SW driver
components are missing (and can/will be added in the future)?

BR,
Drasko

2013-12-01 00:32:01

by Sujith Manoharan

[permalink] [raw]
Subject: Re: multi-wiphy (virtual radios that can be used with multiple channels)

Drasko DRASKOVIC wrote:
> Hi all,
> can somebody please explain in some more details this possibility of
> ath9k driver, mentioned here: http://lwn.net/Articles/321690/ and
> specially here:
> http://osdir.com/ml/linux-wireless/2009-03/msg00090.html in these
> patches signed-off by Jouni.

The virtual wiphy feature has been removed from ath9k.

> Does this means that ath9k devices can be put in AP and STA modes
> simultaneously (one virtual interface for each) over different
> channels?
>
> I am looking to solve this problem: I want to have always present AP
> for user settings that I bring on boot, so I give it some
> pre-configured channel. Via this AP user will configure other
> interface in STA mode to connect to home network. However, this home
> network can be over any channel, very potentially different of the one
> I have chosen for AP.

Multi Channel Concurrency is required to do this, but ath9k doesn't
support it right now.

Sujith

2013-12-01 11:39:17

by Sujith Manoharan

[permalink] [raw]
Subject: Re: multi-wiphy (virtual radios that can be used with multiple channels)

Johannes Berg wrote:
> Technically, it's not. Multi-channel support will *not* imply that you
> are able to put an AP and a client interface on two different channels -
> the AP wouldn't work correctly due to being absent when the client
> interface is being handled.
>
> I would recommend against a driver allowing such use case since there's
> no way to tell the user that it's a stupid idea.

I had P2P GO/Client in mind. I should have mentioned that.

Sujith

2013-12-01 04:22:22

by Sujith Manoharan

[permalink] [raw]
Subject: Re: multi-wiphy (virtual radios that can be used with multiple channels)

Drasko DRASKOVIC wrote:
> That would imply that HW is capable of doing this, but SW driver
> components are missing (and can/will be added in the future)?

Yep, that is correct.

Sujith

2013-12-01 09:39:57

by Johannes Berg

[permalink] [raw]
Subject: Re: multi-wiphy (virtual radios that can be used with multiple channels)

On Sun, 2013-12-01 at 09:47 +0530, Sujith Manoharan wrote:
> Drasko DRASKOVIC wrote:
> > That would imply that HW is capable of doing this, but SW driver
> > components are missing (and can/will be added in the future)?
>
> Yep, that is correct.

Technically, it's not. Multi-channel support will *not* imply that you
are able to put an AP and a client interface on two different channels -
the AP wouldn't work correctly due to being absent when the client
interface is being handled.

I would recommend against a driver allowing such use case since there's
no way to tell the user that it's a stupid idea.

johannes