Hello,
With latest compat, wpa_supplicant seems p2p_concurent is set for
car9170 driver based on information from driver.
So, next after p2p_group_add new virtual interface is created for that
- p2p-wlan0-0.
Next, carl9170_op_add_interface() return -EBUSY because there is
already main_vif (NL80211_IFTYPE_STATION) created by default on
startup.
Because of that p2p_group_add() always fail with such chipset and
p2p_concurent=1.
STEPS:
- run wpa_supplicant
- run wpa_cli
- p2p_group_add
FAIL
Is that chipset limitation we could add only new STA interface when
main_vif is also STA?
Where could I find HW documentation for carl9170?
I suspect lower change is not acceptable because of HW limitation?
main_vif = carl9170_get_main_vif(ar);
if (main_vif) {
switch (main_vif->type) {
case NL80211_IFTYPE_STATION:
- if (vif->type == NL80211_IFTYPE_STATION)
+ if ((vif->type == NL80211_IFTYPE_STATION) ||
+ (vif->type == NL80211_IFTYPE_AP))
break;
BR
Janusz
On Friday 06 April 2012 12:39:57 Janusz Dziedzic wrote:
> With latest compat, wpa_supplicant seems p2p_concurent is set for
> car9170 driver based on information from driver.
> So, next after p2p_group_add new virtual interface is created for that
> - p2p-wlan0-0.
>
> Next, carl9170_op_add_interface() return -EBUSY because there is
> already main_vif (NL80211_IFTYPE_STATION) created by default on
> startup.
> Because of that p2p_group_add() always fail with such chipset and
> p2p_concurent=1.
>
> STEPS:
> - run wpa_supplicant
> - run wpa_cli
> - p2p_group_add
> FAIL
>
> Is that chipset limitation we could add only new STA interface when
> main_vif is also STA?
<http://wireless.kernel.org/en/users/Drivers/carl9170#Multiple_Interfaces>
no, it's not. But you'll have to go through several hoops to extend
the driver to switch the "main" interface while the device is up and
running.
good luck!
> Where could I find HW documentation for carl9170?
HW documentation for carl9170? There's no such thing.
But Qualcomm has some docs about the AR9170.
> I suspect lower change is not acceptable because of HW limitation?
>
> main_vif = carl9170_get_main_vif(ar);
>
> if (main_vif) {
> switch (main_vif->type) {
> case NL80211_IFTYPE_STATION:
> - if (vif->type == NL80211_IFTYPE_STATION)
> + if ((vif->type == NL80211_IFTYPE_STATION) ||
> + (vif->type == NL80211_IFTYPE_AP))
> break;
No, it's just the driver can't guarantee that such a configuration
will be what you think it is.
Regards,
Chr
On Friday 06 April 2012 17:11:29 Johannes Berg wrote:
> On Fri, 2012-04-06 at 13:22 +0200, Christian Lamparter wrote:
>
> > > Is that chipset limitation we could add only new STA interface when
> > > main_vif is also STA?
> > <http://wireless.kernel.org/en/users/Drivers/carl9170#Multiple_Interfaces>
> > no, it's not. But you'll have to go through several hoops to extend
> > the driver to switch the "main" interface while the device is up and
> > running.
>
> So the driver has a concept of the order in which interfaces are added?
> That's something I never considered when writing the interface type
> combinations support.
Actually, it's more of a master/slave situation.
The MAC only has one security engine "mode" which can be either AP/IBSS/WDS.
[So, this setting will be shared with all virtual interfaces]
Next, the MAC only has one TSF counter, [beacon/tbtt timer, etc...] which
is also shared between the virtual interfaces [note: the TSF sync depends
on the mode as well, you see if the main interface is a station/ibss then
the TSF is automatically updated [by the hardware in fact] and there is
nothing a slave interface [e.g.: AP] can do!]. And then there is of
course the shared ERP, basic rates, slot time, multicast, QOS/WME, ... stuff.
Regards,
Christian
On Fri, 2012-04-06 at 13:22 +0200, Christian Lamparter wrote:
> > Is that chipset limitation we could add only new STA interface when
> > main_vif is also STA?
> <http://wireless.kernel.org/en/users/Drivers/carl9170#Multiple_Interfaces>
> no, it's not. But you'll have to go through several hoops to extend
> the driver to switch the "main" interface while the device is up and
> running.
So the driver has a concept of the order in which interfaces are added?
That's something I never considered when writing the interface type
combinations support.
johannes
Hi,
Conceptually it'd be feasible to reset the hardware to a new state
that supports whatever the new vif features are.
That however includes all the gotcha! issues that occur when doing a
reset whilst live traffic is occuring..
Adrian