Skip to contentSkip to conversation

ath10k to ath9k IBSS, ath9k has interface-combinations issue

DISCUSSION Ben Greear 5 participants 10 messages Apr 7, 2015 – Apr 24, 2015

lore
Share & tools
lore

Ben Greear

author
#0 lore raw

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

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#1 lore raw
Quoted 36 lines · 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;
}
Quoted 7 lines

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ł

#2 lore raw
Quoted 43 lines · Michal Kazior
Quoted 42 lines · 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.

Quoted 6 lines
Quoted 1 line

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

author
#3 lore raw
Quoted 46 lines · Janusz Dziedzic
Quoted 45 lines · Michal Kazior
Quoted 43 lines · 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?

Quoted 7 lines
Quoted 4 lines

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

Quoted 8 lines

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

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
author
#4 lore raw
Quoted 52 lines · Ben Greear
Quoted 51 lines · Janusz Dziedzic
Quoted 49 lines · Michal Kazior
Quoted 36 lines · 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;
}
Quoted 7 lines

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.

Quoted 4 lines
Quoted 2 lines

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

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#5 lore raw
Quoted 2 lines · Ben Greear

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

#6 lore raw

Am 08.04.2015 um 05:25 schrieb Sujith Manoharan:

Quoted 4 lines

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

author
#7 lore raw
In reply to Sujith Manoharan
Quoted 8 lines · Sujith Manoharan
Quoted 2 lines · Ben Greear

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

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#8 lore raw
Quoted 8 lines · Ben Greear
Quoted 4 lines

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

author
#9 lore raw
Quoted 6 lines · Sujith Manoharan
Quoted 5 lines · Ben Greear
Quoted 4 lines

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...

Quoted 9 lines
Quoted 3 lines

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

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com