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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 7 April 2015 at 07:12, Michal Kazior <[email protected]> wrote:
> On 7 April 2015 at 02:39, Ben Greear <[email protected]> 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
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
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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 04/06/2015 10:17 PM, Janusz Dziedzic wrote:
> On 7 April 2015 at 07:12, Michal Kazior <[email protected]> wrote:
>> On 7 April 2015 at 02:39, Ben Greear <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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
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 <[email protected]> wrote:
>>> On 7 April 2015 at 02:39, Ben Greear <[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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
On 7 April 2015 at 02:39, Ben Greear <[email protected]> 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ł