ath10k to ath9k IBSS, ath9k has interface-combinations issue

ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Ben Greear]

Has anyone tried running ath10k to ath9k IBSS?

I'm trying this with a somewhat hacked 4.0-rc6 kernel,
and latest wpa_supplicant.

ath9k to ath9k works with and without encryption, and ath10k to ath10k works (w/out encryption at least).

But, if I try to tell ath10k to connect to ath9k, then the ath9k reports interface combinations
issues and will not associate.  I've added some debug, and the issue is the 'num==0' part here:


int cfg80211_check_combinations(struct wiphy *wiphy,
				const int num_different_channels,
				const u8 radar_detect,
				const int iftype_num[NUM_NL80211_IFTYPES])
{
	int err, num = 0;

	err = cfg80211_iter_combinations(wiphy, num_different_channels,
					 radar_detect, iftype_num,
					 cfg80211_iter_sum_ifcombs, &num);
	if (err) {
		pr_info("cfg-comb-check: failed to iterate combinations\n");
		return err;
	}
	if (num == 0) {
		pr_info("cfg-comb-check: iter-combinations returned num==0\n");
		return -EBUSY;
	}

	return 0;
}
EXPORT_SYMBOL(cfg80211_check_combinations);

There should be exactly one interface on this radio that is admin-up, and it is the
one that I am trying to make run in adhoc mode.

Any ideas on this?

Thanks,
Ben


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

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Michal Kazior]

On 7 April 2015 at 02:39, Ben Greear <greearb@candelatech.com> wrote:
> Has anyone tried running ath10k to ath9k IBSS?
>
> I'm trying this with a somewhat hacked 4.0-rc6 kernel,
> and latest wpa_supplicant.
>
> ath9k to ath9k works with and without encryption, and ath10k to ath10k works
> (w/out encryption at least).
>
> But, if I try to tell ath10k to connect to ath9k, then the ath9k reports
> interface combinations
> issues and will not associate.  I've added some debug, and the issue is the
> 'num==0' part here:
>
>
> int cfg80211_check_combinations(struct wiphy *wiphy,
>                                 const int num_different_channels,
>                                 const u8 radar_detect,
>                                 const int iftype_num[NUM_NL80211_IFTYPES])
> {
>         int err, num = 0;
>
>         err = cfg80211_iter_combinations(wiphy, num_different_channels,
>                                          radar_detect, iftype_num,
>                                          cfg80211_iter_sum_ifcombs, &num);
>         if (err) {
>                 pr_info("cfg-comb-check: failed to iterate combinations\n");
>                 return err;
>         }
>         if (num == 0) {
>                 pr_info("cfg-comb-check: iter-combinations returned
> num==0\n");
>                 return -EBUSY;
>         }
>
>         return 0;
> }
> EXPORT_SYMBOL(cfg80211_check_combinations);
>
> There should be exactly one interface on this radio that is admin-up, and it
> is the
> one that I am trying to make run in adhoc mode.
>
> Any ideas on this?

IBSS with non-fixed or dfs channel? It would bump
num_different_channels and yield no valid combinations. But why would
that work fine with, e.g. ath9k-ath9k otherwise - no idea.


Michał

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Janusz Dziedzic]

On 7 April 2015 at 07:12, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 7 April 2015 at 02:39, Ben Greear <greearb@candelatech.com> wrote:
>> Has anyone tried running ath10k to ath9k IBSS?
>>
>> I'm trying this with a somewhat hacked 4.0-rc6 kernel,
>> and latest wpa_supplicant.
>>
>> ath9k to ath9k works with and without encryption, and ath10k to ath10k works
>> (w/out encryption at least).
>>
>> But, if I try to tell ath10k to connect to ath9k, then the ath9k reports
>> interface combinations
>> issues and will not associate.  I've added some debug, and the issue is the
>> 'num==0' part here:
>>
>>
>> int cfg80211_check_combinations(struct wiphy *wiphy,
>>                                 const int num_different_channels,
>>                                 const u8 radar_detect,
>>                                 const int iftype_num[NUM_NL80211_IFTYPES])
>> {
>>         int err, num = 0;
>>
>>         err = cfg80211_iter_combinations(wiphy, num_different_channels,
>>                                          radar_detect, iftype_num,
>>                                          cfg80211_iter_sum_ifcombs, &num);
>>         if (err) {
>>                 pr_info("cfg-comb-check: failed to iterate combinations\n");
>>                 return err;
>>         }
>>         if (num == 0) {
>>                 pr_info("cfg-comb-check: iter-combinations returned
>> num==0\n");
>>                 return -EBUSY;
>>         }
>>
>>         return 0;
>> }
>> EXPORT_SYMBOL(cfg80211_check_combinations);
>>
>> There should be exactly one interface on this radio that is admin-up, and it
>> is the
>> one that I am trying to make run in adhoc mode.
>>
>> Any ideas on this?
>
> IBSS with non-fixed or dfs channel? It would bump
> num_different_channels and yield no valid combinations. But why would
> that work fine with, e.g. ath9k-ath9k otherwise - no idea.
>

Check this discussion (ibss + p2p_device - this could be one you hit).
http://www.spinics.net/lists/linux-wireless/msg134447.html

BR
Janusz

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Ben Greear]

On 04/06/2015 10:17 PM, Janusz Dziedzic wrote:
> On 7 April 2015 at 07:12, Michal Kazior <michal.kazior@tieto.com> wrote:
>> On 7 April 2015 at 02:39, Ben Greear <greearb@candelatech.com> wrote:
>>> Has anyone tried running ath10k to ath9k IBSS?
>>>
>>> I'm trying this with a somewhat hacked 4.0-rc6 kernel,
>>> and latest wpa_supplicant.
>>>
>>> ath9k to ath9k works with and without encryption, and ath10k to ath10k works
>>> (w/out encryption at least).
>>>
>>> But, if I try to tell ath10k to connect to ath9k, then the ath9k reports
>>> interface combinations
>>> issues and will not associate.  I've added some debug, and the issue is the
>>> 'num==0' part here:
>>>
>>>
>>> int cfg80211_check_combinations(struct wiphy *wiphy,
>>>                                 const int num_different_channels,
>>>                                 const u8 radar_detect,
>>>                                 const int iftype_num[NUM_NL80211_IFTYPES])
>>> {
>>>         int err, num = 0;
>>>
>>>         err = cfg80211_iter_combinations(wiphy, num_different_channels,
>>>                                          radar_detect, iftype_num,
>>>                                          cfg80211_iter_sum_ifcombs, &num);
>>>         if (err) {
>>>                 pr_info("cfg-comb-check: failed to iterate combinations\n");
>>>                 return err;
>>>         }
>>>         if (num == 0) {
>>>                 pr_info("cfg-comb-check: iter-combinations returned
>>> num==0\n");
>>>                 return -EBUSY;
>>>         }
>>>
>>>         return 0;
>>> }
>>> EXPORT_SYMBOL(cfg80211_check_combinations);
>>>
>>> There should be exactly one interface on this radio that is admin-up, and it
>>> is the
>>> one that I am trying to make run in adhoc mode.
>>>
>>> Any ideas on this?
>>
>> IBSS with non-fixed or dfs channel? It would bump
>> num_different_channels and yield no valid combinations. But why would
>> that work fine with, e.g. ath9k-ath9k otherwise - no idea.
>>
> 
> Check this discussion (ibss + p2p_device - this could be one you hit).
> http://www.spinics.net/lists/linux-wireless/msg134447.html

That patch is in my tree already, so must be something else.

Thanks,
Ben

> 
> BR
> Janusz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


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

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Ben Greear]

On 04/07/2015 09:33 AM, Ben Greear wrote:
> On 04/06/2015 10:17 PM, Janusz Dziedzic wrote:
>> On 7 April 2015 at 07:12, Michal Kazior <michal.kazior@tieto.com> wrote:
>>> On 7 April 2015 at 02:39, Ben Greear <greearb@candelatech.com> wrote:
>>>> Has anyone tried running ath10k to ath9k IBSS?
>>>>
>>>> I'm trying this with a somewhat hacked 4.0-rc6 kernel,
>>>> and latest wpa_supplicant.
>>>>
>>>> ath9k to ath9k works with and without encryption, and ath10k to ath10k works
>>>> (w/out encryption at least).
>>>>
>>>> But, if I try to tell ath10k to connect to ath9k, then the ath9k reports
>>>> interface combinations
>>>> issues and will not associate.  I've added some debug, and the issue is the
>>>> 'num==0' part here:
>>>>
>>>>
>>>> int cfg80211_check_combinations(struct wiphy *wiphy,
>>>>                                 const int num_different_channels,
>>>>                                 const u8 radar_detect,
>>>>                                 const int iftype_num[NUM_NL80211_IFTYPES])
>>>> {
>>>>         int err, num = 0;
>>>>
>>>>         err = cfg80211_iter_combinations(wiphy, num_different_channels,
>>>>                                          radar_detect, iftype_num,
>>>>                                          cfg80211_iter_sum_ifcombs, &num);
>>>>         if (err) {
>>>>                 pr_info("cfg-comb-check: failed to iterate combinations\n");
>>>>                 return err;
>>>>         }
>>>>         if (num == 0) {
>>>>                 pr_info("cfg-comb-check: iter-combinations returned
>>>> num==0\n");
>>>>                 return -EBUSY;
>>>>         }
>>>>
>>>>         return 0;
>>>> }
>>>> EXPORT_SYMBOL(cfg80211_check_combinations);
>>>>
>>>> There should be exactly one interface on this radio that is admin-up, and it
>>>> is the
>>>> one that I am trying to make run in adhoc mode.
>>>>
>>>> Any ideas on this?
>>>
>>> IBSS with non-fixed or dfs channel? It would bump
>>> num_different_channels and yield no valid combinations. But why would
>>> that work fine with, e.g. ath9k-ath9k otherwise - no idea.
>>>
>>
>> Check this discussion (ibss + p2p_device - this could be one you hit).
>> http://www.spinics.net/lists/linux-wireless/msg134447.html
> 
> That patch is in my tree already, so must be something else.

First, I was wrong...I have some bug (or maybe user-error) and
I had 2 VAP running on this radio when I did not think they were
running.

The combination check is failing because this check below is failing for the third set of combinations:

int cfg80211_iter_combinations(struct wiphy *wiphy,
			       const int num_different_channels,
			       const u8 radar_detect,
			       const int iftype_num[NUM_NL80211_IFTYPES],
			       void (*iter)(const struct ieee80211_iface_combination *c,
					    void *data),
			       void *data)
.....
		if (num_interfaces > c->max_interfaces) {
			pr_info("%i: iter-comb, num > max: %d > %d\n",
				i, num_interfaces, c->max_interfaces);
			continue;
		}

In my case, num_interfaces is 3 here when I get to i == 2.

'iw phy wiphy1 info' has this:

	valid interface combinations:
		 * #{ managed } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1,
		   total <= 2048, #channels <= 1, STA/AP BI must match
		 * #{ WDS } <= 2048,
		   total <= 2048, #channels <= 1, STA/AP BI must match
		 * #{ IBSS, AP, mesh point } <= 1,
		   total <= 1, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz }

For the third set, why limit to a single interface.  Can't we run IBSS + AP
(and plus stations, for that matter), all at the same time with ath9k?

Thanks,
Ben


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

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Sujith Manoharan]

Ben Greear wrote:
> For the third set, why limit to a single interface.  Can't we run IBSS + AP
> (and plus stations, for that matter), all at the same time with ath9k?

TSF would jump around since the HW would sync with the
received beacons and this will happen in both IBSS and station
mode. Hence the limitation, but I think OpenWrt has a one-liner
to remove this restriction...

Sujith

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Sven-Ola Tuecke]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

Am 08.04.2015 um 05:25 schrieb Sujith Manoharan:
> TSF would jump around since the HW would sync with the
> received beacons and this will happen in both IBSS and station
> mode. Hence the limitation, but I think OpenWrt has a one-liner
> to remove this restriction...
TSF in larger IBSS meshes (> 100 nodes) may be jumpy anyway, e.g. it
requires only one (misonfigured / buggy) node to introduce a TSF >
0xffffffff00000000 once. Because all IBSS nodes will take over the
largest TSF unverified from any neighbour, you end up by having TSF
bouncing around 64 bit overflow until you switch off the mesh
completely. We had this situation a couple of years here in Berlin.
Moment, let's have a look:

-> Frame 2: 104 bytes on wire (832 bits), 104 bytes captured (832 bits)
-> Radiotap Header v0, Length 18
-> IEEE 802.11 Beacon frame, Flags: ........
+> IEEE 802.11 wireless LAN management frame
   +> Fixed parameters (12 bytes)
      +> Timestamp: 0x0008004c7ddf6095

Seems the familiar 0xffffffffxxxxxxxx TSF is gone for some reason. In
practise, this does not hurt too much, you get a second downtime every
hour or so on turnaround.

// Sven-Ola



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Ben Greear]

On 04/07/2015 08:25 PM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> For the third set, why limit to a single interface.  Can't we run IBSS + AP
>> (and plus stations, for that matter), all at the same time with ath9k?
> 
> TSF would jump around since the HW would sync with the
> received beacons and this will happen in both IBSS and station
> mode. Hence the limitation, but I think OpenWrt has a one-liner
> to remove this restriction...

It seems I can only do a single VAP on ath9k as well?

Is that per design?

Thanks,
Ben


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

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Sujith Manoharan]

Ben Greear wrote:
> > TSF would jump around since the HW would sync with the
> > received beacons and this will happen in both IBSS and station
> > mode. Hence the limitation, but I think OpenWrt has a one-liner
> > to remove this restriction...
> 
> It seems I can only do a single VAP on ath9k as well?
> 
> Is that per design?

I was referring to ath9k, but it probably applies to ath10k too.
But yes, IBSS is restricted to a single interface by design.

Sujith

Re: ath10k to ath9k IBSS, ath9k has interface-combinations issue

[Ben Greear]

On 04/24/2015 07:42 AM, Sujith Manoharan wrote:
> Ben Greear wrote:
>>> TSF would jump around since the HW would sync with the
>>> received beacons and this will happen in both IBSS and station
>>> mode. Hence the limitation, but I think OpenWrt has a one-liner
>>> to remove this restriction...
>>
>> It seems I can only do a single VAP on ath9k as well?
>>
>> Is that per design?
>
> I was referring to ath9k, but it probably applies to ath10k too.
> But yes, IBSS is restricted to a single interface by design.
>
> Sujith
>

My VAP issues were due to regulatory domain issues it seems,
after fixing that I could bring up 8 VAPs on ath9k.

I also added that patch to allow IBSS + other combinations, but
I haven't actually done any real testing with that config.

Thanks,
Ben

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