CT ath10k firmware now supports IBSS + RSN

CT ath10k firmware now supports IBSS + RSN

[Ben Greear]

First, thanks to everyone that helped me with questions,
QCA/Tieto's upstream patches, etc.

This needs more testing, but it appears to at least mostly work.

I am using this 4.0 related kernel.  I think only the last 3 patches
are IBSS specific, but possibly there are others that matter as well.

http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary

Firmware binaries and release notes are here:
http://www.candelatech.com/downloads/ath10k-fw-beta/

I'm using a very recent wpa_supplicant..upstream should work I think,
but I am using this one:

https://github.com/greearb/hostap-ct/tree/master/hostapd

supplicant needs to have this enabled, among other things:

CONFIG_IBSS_RSN=y


I suspect there are lingering bugs, perhaps in supplicant, as it seems to take
a few tries for the 4-way to happen properly, and I have to re-start hostapd
on each side each time I associate.

My supplicant config files look like this (you can comment out any options
your supplicant doesn't know about...I have a few extra features not specifically
related to IBSS in my hostapd tree)

ctrl_interface=/var/run/wpa_supplicant
fast_reauth=1
concurrent_assoc_ok=1
scan_cur_freq=1
min_scan_gap=5
freq_list=5180

bss_max_count=2000
network={
    ssid="ota-ibss-ssid"
    disable_ht=0
    disable_vht=0
    ieee80211w=0
    disable_ht40=1
    disable_sgi=0
    ht_mcs=""
    disable_max_amsdu=-1
    ampdu_factor=-1
    ampdu_density=-1
    freq_list=5180
    fixed_freq=1

    mode=1
    frequency=5180
    proto=RSN
    key_mgmt=WPA-PSK
    #psk="ben-ota-passwd"
    psk=fc29b6edf32abd7a9818af3c94b2aa5364c785eee33ed3df11605a3db8f905bc
    pairwise=CCMP
    group=CCMP
    proactive_key_caching=0

}


I'm curious to know if anyone tries it out.

Thanks,
Ben

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

Re: CT ath10k firmware now supports IBSS + RSN

[Ben Greear]

Looks like I have some more work to do.  For any moderately large frames,
I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
was working around a more serious issue...

Thanks,
Ben

On 04/10/2015 04:32 PM, Ben Greear wrote:
> First, thanks to everyone that helped me with questions,
> QCA/Tieto's upstream patches, etc.
> 
> This needs more testing, but it appears to at least mostly work.
> 
> I am using this 4.0 related kernel.  I think only the last 3 patches
> are IBSS specific, but possibly there are others that matter as well.
> 
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary
> 
> Firmware binaries and release notes are here:
> http://www.candelatech.com/downloads/ath10k-fw-beta/
> 
> I'm using a very recent wpa_supplicant..upstream should work I think,
> but I am using this one:
> 
> https://github.com/greearb/hostap-ct/tree/master/hostapd
> 
> supplicant needs to have this enabled, among other things:
> 
> CONFIG_IBSS_RSN=y
> 
> 
> I suspect there are lingering bugs, perhaps in supplicant, as it seems to take
> a few tries for the 4-way to happen properly, and I have to re-start hostapd
> on each side each time I associate.
> 
> My supplicant config files look like this (you can comment out any options
> your supplicant doesn't know about...I have a few extra features not specifically
> related to IBSS in my hostapd tree)
> 
> ctrl_interface=/var/run/wpa_supplicant
> fast_reauth=1
> concurrent_assoc_ok=1
> scan_cur_freq=1
> min_scan_gap=5
> freq_list=5180
> 
> bss_max_count=2000
> network={
>     ssid="ota-ibss-ssid"
>     disable_ht=0
>     disable_vht=0
>     ieee80211w=0
>     disable_ht40=1
>     disable_sgi=0
>     ht_mcs=""
>     disable_max_amsdu=-1
>     ampdu_factor=-1
>     ampdu_density=-1
>     freq_list=5180
>     fixed_freq=1
> 
>     mode=1
>     frequency=5180
>     proto=RSN
>     key_mgmt=WPA-PSK
>     #psk="ben-ota-passwd"
>     psk=fc29b6edf32abd7a9818af3c94b2aa5364c785eee33ed3df11605a3db8f905bc
>     pairwise=CCMP
>     group=CCMP
>     proactive_key_caching=0
> 
> }
> 
> 
> I'm curious to know if anyone tries it out.
> 
> Thanks,
> Ben
> 


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

Re: CT ath10k firmware now supports IBSS + RSN

[Ben Greear]

On 04/13/2015 10:41 AM, Ben Greear wrote:
> Looks like I have some more work to do.  For any moderately large frames,
> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
> was working around a more serious issue...

A better-tested version of kernel and firmware is uploaded now.

Looks like I needed to add a hack to firmware to bump pkt-size by
16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
to work in light testing.

I removed the skb-padto hack from the kernel, and kernel is rebased on
top of official 4.0 now.

Thanks,
Ben

> On 04/10/2015 04:32 PM, Ben Greear wrote:
>> First, thanks to everyone that helped me with questions,
>> QCA/Tieto's upstream patches, etc.
>>
>> This needs more testing, but it appears to at least mostly work.
>>
>> I am using this 4.0 related kernel.  I think only the last 3 patches
>> are IBSS specific, but possibly there are others that matter as well.
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary
>>
>> Firmware binaries and release notes are here:
>> http://www.candelatech.com/downloads/ath10k-fw-beta/
>>
>> I'm using a very recent wpa_supplicant..upstream should work I think,
>> but I am using this one:
>>
>> https://github.com/greearb/hostap-ct/tree/master/hostapd
>>
>> supplicant needs to have this enabled, among other things:
>>
>> CONFIG_IBSS_RSN=y
>>
>>
>> I suspect there are lingering bugs, perhaps in supplicant, as it seems to take
>> a few tries for the 4-way to happen properly, and I have to re-start hostapd
>> on each side each time I associate.
>>
>> My supplicant config files look like this (you can comment out any options
>> your supplicant doesn't know about...I have a few extra features not specifically
>> related to IBSS in my hostapd tree)
>>
>> ctrl_interface=/var/run/wpa_supplicant
>> fast_reauth=1
>> concurrent_assoc_ok=1
>> scan_cur_freq=1
>> min_scan_gap=5
>> freq_list=5180
>>
>> bss_max_count=2000
>> network={
>>     ssid="ota-ibss-ssid"
>>     disable_ht=0
>>     disable_vht=0
>>     ieee80211w=0
>>     disable_ht40=1
>>     disable_sgi=0
>>     ht_mcs=""
>>     disable_max_amsdu=-1
>>     ampdu_factor=-1
>>     ampdu_density=-1
>>     freq_list=5180
>>     fixed_freq=1
>>
>>     mode=1
>>     frequency=5180
>>     proto=RSN
>>     key_mgmt=WPA-PSK
>>     #psk="ben-ota-passwd"
>>     psk=fc29b6edf32abd7a9818af3c94b2aa5364c785eee33ed3df11605a3db8f905bc
>>     pairwise=CCMP
>>     group=CCMP
>>     proactive_key_caching=0
>>
>> }
>>
>>
>> I'm curious to know if anyone tries it out.
>>
>> Thanks,
>> Ben
>>
> 
> 


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

Re: CT ath10k firmware now supports IBSS + RSN

[Michal Kazior]

On 14 April 2015 at 02:10, Ben Greear <greearb@candelatech.com> wrote:
> On 04/13/2015 10:41 AM, Ben Greear wrote:
>> Looks like I have some more work to do.  For any moderately large frames,
>> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
>> was working around a more serious issue...
>
> A better-tested version of kernel and firmware is uploaded now.
>
> Looks like I needed to add a hack to firmware to bump pkt-size by
> 16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
> to work in light testing.
>
> I removed the skb-padto hack from the kernel, and kernel is rebased on
> top of official 4.0 now.

Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
be different from frame length (ath10k_htt_tx(),
htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1]
needs to be applied..?


[1]: https://www.mail-archive.com/ath10k@lists.infradead.org/msg00241.html


Michał

Re: CT ath10k firmware now supports IBSS + RSN

[Ben Greear]

On 04/13/2015 10:34 PM, Michal Kazior wrote:
> On 14 April 2015 at 02:10, Ben Greear <greearb@candelatech.com> wrote:
>> On 04/13/2015 10:41 AM, Ben Greear wrote:
>>> Looks like I have some more work to do.  For any moderately large frames,
>>> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
>>> was working around a more serious issue...
>>
>> A better-tested version of kernel and firmware is uploaded now.
>>
>> Looks like I needed to add a hack to firmware to bump pkt-size by
>> 16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
>> to work in light testing.
>>
>> I removed the skb-padto hack from the kernel, and kernel is rebased on
>> top of official 4.0 now.
>
> Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
> be different from frame length (ath10k_htt_tx(),
> htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1]
> needs to be applied..?
>
>
> [1]: https://www.mail-archive.com/ath10k@lists.infradead.org/msg00241.html

This IBSS+RSN hack could be done in the kernel, but if my firmware is the only thing that
needs it, then it is more convenient for me to hack firmware than have it
incompatible with upstream drivers.

If you do find similar problems with other firmware, then certainly a driver
patch is welcome, and I will back out my firmware hack accordingly.

And, it would be nice if someone put some version if your raw-tx patch upstream.
I can also adjust length for raw pkts in firmware too, but again, in many cases
it is better to be similarly broken to existing firmware than to be technically
correct but break compatibility with the driver.  If I ever get a 'ct-firmware'
feature flag upstream, then we could of course do the changes to take advantage
of my firmwares differences as needed.

Thanks,
Ben

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

Re: CT ath10k firmware now supports IBSS + RSN

[Ben Greear]

I have uploaded a new firmware.

http://www.candelatech.com/downloads/ath10k-fw-beta/

It fixes IBSS blockack (firmware was mis-configuring the BSSID, so
blockacks were sent to wrong BSS address and were not processed when
received).

I also disabled AMSDU for IBSS stations, which significantly improves
performance in my ath10k <-> ath10k IBSS test.  I do not know why this
is needed.

There is still a bug:  I cannot get ath10k <-> ath10k to do IBSS + RSN.

I can get ath9k <-> ath10k IBSS + RSN to work,
and open IBSS ath10k <-> ath10k works.

I am taking a break on IBSS + RSN for a while.

Thanks,
Ben




On 04/14/2015 08:01 AM, Ben Greear wrote:
> 
> 
> On 04/13/2015 10:34 PM, Michal Kazior wrote:
>> On 14 April 2015 at 02:10, Ben Greear <greearb@candelatech.com> wrote:
>>> On 04/13/2015 10:41 AM, Ben Greear wrote:
>>>> Looks like I have some more work to do.  For any moderately large frames,
>>>> I am now dropping the last 16 bytes.  Looks like the skb_put_padto logic
>>>> was working around a more serious issue...
>>>
>>> A better-tested version of kernel and firmware is uploaded now.
>>>
>>> Looks like I needed to add a hack to firmware to bump pkt-size by
>>> 16 for IBSS + RSN encrypted frames.  Not sure exactly why, but seems
>>> to work in light testing.
>>>
>>> I removed the skb-padto hack from the kernel, and kernel is rebased on
>>> top of official 4.0 now.
>>
>> Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
>> be different from frame length (ath10k_htt_tx(),
>> htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1]
>> needs to be applied..?
>>
>>
>> [1]: https://www.mail-archive.com/ath10k@lists.infradead.org/msg00241.html
> 
> This IBSS+RSN hack could be done in the kernel, but if my firmware is the only thing that
> needs it, then it is more convenient for me to hack firmware than have it
> incompatible with upstream drivers.
> 
> If you do find similar problems with other firmware, then certainly a driver
> patch is welcome, and I will back out my firmware hack accordingly.
> 
> And, it would be nice if someone put some version if your raw-tx patch upstream.
> I can also adjust length for raw pkts in firmware too, but again, in many cases
> it is better to be similarly broken to existing firmware than to be technically
> correct but break compatibility with the driver.  If I ever get a 'ct-firmware'
> feature flag upstream, then we could of course do the changes to take advantage
> of my firmwares differences as needed.
> 
> Thanks,
> Ben
> 


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

Re: CT ath10k firmware now supports IBSS + RSN

[Sven Eckelmann]

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

Hi,

On Friday 10 April 2015 16:32:29 Ben Greear wrote:
> First, thanks to everyone that helped me with questions,
> QCA/Tieto's upstream patches, etc.
> 
> This needs more testing, but it appears to at least mostly work.
> 
> I am using this 4.0 related kernel.  I think only the last 3 patches
> are IBSS specific, but possibly there are others that matter as well.
> 
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary
> 
> Firmware binaries and release notes are here:
> http://www.candelatech.com/downloads/ath10k-fw-beta/
> 
> I'm using a very recent wpa_supplicant..upstream should work I think,
> but I am using this one:
> 
> https://github.com/greearb/hostap-ct/tree/master/hostapd
> 
> supplicant needs to have this enabled, among other things:
> 
> CONFIG_IBSS_RSN=y

thanks for your work on the QCA firmware fork. I have testing your
firmware v14 (firmware-2-ct-full-community.bin;
md5sum 800799459c20c1683138c74b3ba58f25) a little bit on OpenWrt r46413
(+ your patches [1]) with a QCA9880 device and focus on IBSS.

The performance over IBSS looks a lot better than before. So your
aggregation/BlockAck fix seems to work quite well.

But there are also some problems which I've noticed.

 * setting the mcast rate during `iw dev "$ifname" ibss join`
   doesn't seem to work for IBSS mode. The bcast frames are still
   transmitted with 6Mbit/s
   - I've also tried to use the hack
     + echo mcast > /sys/kernel/debug/ieee80211/phy0/ath10k/set_rates
     + iw dev adhoc0 set bitrates legacy-5 18
 * IBSS/RSN isn't working between ath10k<->ath10k, ath9k<->ath10k
   (works well between ath9k<->ath9k)
   - the ath10k device doesn't seem to send its broadcast frames
     after the handshake finished (ath9k already tries to transmit
     bcast frames)
   - also doesn't work with firmware-2-ct-non-commercial-full-14.bin
     and nohwcrypt=1
 * IBSS stops working everytime an AP interface is added to the same
   PHY (it isn't importing whether it is using WPA/WPA2 or configured
   as open AP)
   - tested again with ath9k on the same OpenWrt version and it
     working quite well with 1x IBSS + 2x AP

Were you able to get anything from the above setups working for you?
Maybe there are some workarounds I've missed and that you've
mentioned in other mails. It would be really nice if you could
mention those again :)

Especially interesting would be to know if some of the problems are
already known and just not implemented. Are the not implemented
features planned or currently not the development goal for this
firmware?

Kind regards,
	Sven

[1] https://dev.cloudtrax.com/git/ath10k-ibss-test.git/shortlog/refs/heads/master-20150824

[-- Attachment #2: failed_encryption_ath9k-37_ath10k-67.pcapng.gz --]
[-- Type: application/x-pcapng, Size: 7556 bytes --]

[-- Attachment #3: failed_encryption_ath10k-c7_ath10k-67.pcapng.gz --]
[-- Type: application/x-pcapng, Size: 2748 bytes --]

[-- Attachment #4: working_encryption_ath9k-0f.37_ath9k-9e.37.pcapng.gz --]
[-- Type: application/x-pcapng, Size: 31125 bytes --]

[-- Attachment #5: wpa_supplicant-adhoc0.conf --]
[-- Type: text/plain, Size: 301 bytes --]

ap_scan=2
network={
        scan_ssid=0
        ssid="mesh"
        key_mgmt=WPA-PSK
        mode=1
        fixed_freq=1
        frequency=5180
        mode=1
        psk="9f0a965af38f2d0a13b66d8b46ab962c"
        proto=RSN
        bssid=02:CA:FE:CA:CA:40
        mcast_rate=18
        htmode=HT40+
}

Re: CT ath10k firmware now supports IBSS + RSN

[Ben Greear]

On 08/17/2015 06:11 AM, Sven Eckelmann wrote:
> Hi,
> 
> On Friday 10 April 2015 16:32:29 Ben Greear wrote:
>> First, thanks to everyone that helped me with questions,
>> QCA/Tieto's upstream patches, etc.
>>
>> This needs more testing, but it appears to at least mostly work.
>>
>> I am using this 4.0 related kernel.  I think only the last 3 patches
>> are IBSS specific, but possibly there are others that matter as well.
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary
>>
>> Firmware binaries and release notes are here:
>> http://www.candelatech.com/downloads/ath10k-fw-beta/
>>
>> I'm using a very recent wpa_supplicant..upstream should work I think,
>> but I am using this one:
>>
>> https://github.com/greearb/hostap-ct/tree/master/hostapd
>>
>> supplicant needs to have this enabled, among other things:
>>
>> CONFIG_IBSS_RSN=y
> 
> thanks for your work on the QCA firmware fork. I have testing your
> firmware v14 (firmware-2-ct-full-community.bin;
> md5sum 800799459c20c1683138c74b3ba58f25) a little bit on OpenWrt r46413
> (+ your patches [1]) with a QCA9880 device and focus on IBSS.
> 
> The performance over IBSS looks a lot better than before. So your
> aggregation/BlockAck fix seems to work quite well.

Thanks for giving it a try!

> 
> But there are also some problems which I've noticed.
> 
>  * setting the mcast rate during `iw dev "$ifname" ibss join`
>    doesn't seem to work for IBSS mode. The bcast frames are still
>    transmitted with 6Mbit/s
>    - I've also tried to use the hack
>      + echo mcast > /sys/kernel/debug/ieee80211/phy0/ath10k/set_rates
>      + iw dev adhoc0 set bitrates legacy-5 18

This is likely fixable, but I have higher priority things to work on
first.  It seems one could spend a good deal of effort in the
rate-ctrl logic.

I am also interested in pursuing host-based rate-ctrl, but I would need
the help of some driver writers as I don't have time to do it all myself.

>  * IBSS/RSN isn't working between ath10k<->ath10k, ath9k<->ath10k
>    (works well between ath9k<->ath9k)
>    - the ath10k device doesn't seem to send its broadcast frames
>      after the handshake finished (ath9k already tries to transmit
>      bcast frames)
>    - also doesn't work with firmware-2-ct-non-commercial-full-14.bin
>      and nohwcrypt=1

I believe I had ath10k to ath9k + RSN work, but I did see problems with ath10k-ath10k + RSN.

I think sometimes it worked a bit, and then stopped.  Truth is, my customers
interested in IBSS are not doing encryption on the IBSS interface, so I have no plans to work on this
soon.  And, even if offered the opportunity, I'm not sure what I could do to
improve the problem.  Possibly someone at QCA would have ideas and might share
them with me...


>  * IBSS stops working everytime an AP interface is added to the same
>    PHY (it isn't importing whether it is using WPA/WPA2 or configured
>    as open AP)
>    - tested again with ath9k on the same OpenWrt version and it
>      working quite well with 1x IBSS + 2x AP

One of my customers is using AP + IBSS interface with no obvious problems
related to concurrency.  But, maybe they are doing things in a different
order.  Does it work for you if you bring up AP first and then add IBSS?

This is likely fixable.

> Were you able to get anything from the above setups working for you?
> Maybe there are some workarounds I've missed and that you've
> mentioned in other mails. It would be really nice if you could
> mention those again :)
> 
> Especially interesting would be to know if some of the problems are
> already known and just not implemented. Are the not implemented
> features planned or currently not the development goal for this
> firmware?

In general, I have about as much work as I can handle.  General development
goals are rate-ctrl improvements, more stability improvements, maybe IBSS + AMSDU
support (that is what I disabled to make it run at least moderately fast).

Part of my rate-ctrl effort is allowing radio-tap transmit to work, and especially
to allow some per-pkt settings w/regard to rate-ctrl.  I am not sure how possible
this will be, but so far, it seems like something I have a chance at making work.

We also see bugs with ANQP and 802.11r roaming....I am thinking this may be
at least partially a driver bug...might have to add a peer for whoever we
are doing ANQP with, for instance.  I'm not sure how multiple peers on a station
vdev will work or not.

Thanks,
Ben

> 
> Kind regards,
> 	Sven
> 
> [1] https://dev.cloudtrax.com/git/ath10k-ibss-test.git/shortlog/refs/heads/master-20150824
> 


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

Re: CT ath10k firmware now supports IBSS + RSN

[Sven Eckelmann]

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

On Monday 17 August 2015 08:33:06 Ben Greear wrote:
[...]
> >  * IBSS/RSN isn't working between ath10k<->ath10k, ath9k<->ath10k
> >    (works well between ath9k<->ath9k)
> >    - the ath10k device doesn't seem to send its broadcast frames
> >      after the handshake finished (ath9k already tries to transmit
> >      bcast frames)
> >    - also doesn't work with firmware-2-ct-non-commercial-full-14.bin
> >      and nohwcrypt=1
> 
> I believe I had ath10k to ath9k + RSN work, but I did see problems with ath10k-ath10k + RSN.

Yes, this was what I was reading in a different mail and also the reason
why I've tried to get it working for ath9k<->ath10k. But unfortunately,
I had no success.

I have also tried to use your config without the overrides and with
overrides without any success.

> I think sometimes it worked a bit, and then stopped.  Truth is, my customers
> interested in IBSS are not doing encryption on the IBSS interface, so I have no plans to work on this
> soon.  And, even if offered the opportunity, I'm not sure what I could do to
> improve the problem.  Possibly someone at QCA would have ideas and might share
> them with me...
> 
> 
> >  * IBSS stops working everytime an AP interface is added to the same
> >    PHY (it isn't importing whether it is using WPA/WPA2 or configured
> >    as open AP)
> >    - tested again with ath9k on the same OpenWrt version and it
> >      working quite well with 1x IBSS + 2x AP
> 
> One of my customers is using AP + IBSS interface with no obvious problems
> related to concurrency.  But, maybe they are doing things in a different
> order.  Does it work for you if you bring up AP first and then add IBSS?
> 
> This is likely fixable.

I had to hack a little bit of OpenWrt away but it seems that it works for
a simple setup to first create the adhoc interface and then sometimes later
add the AP interface.

[...]

Thanks for your feedback.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: CT ath10k firmware now supports IBSS + RSN

[Ben Greear]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/18/2015 02:38 AM, Sven Eckelmann wrote:
> On Monday 17 August 2015 08:33:06 Ben Greear wrote: [...]
>>> * IBSS/RSN isn't working between ath10k<->ath10k, ath9k<->ath10k (works well between ath9k<->ath9k) - the ath10k device doesn't seem to send its
>>> broadcast frames after the handshake finished (ath9k already tries to transmit bcast frames) - also doesn't work with
>>> firmware-2-ct-non-commercial-full-14.bin and nohwcrypt=1
>> 
>> I believe I had ath10k to ath9k + RSN work, but I did see problems with ath10k-ath10k + RSN.
> 
> Yes, this was what I was reading in a different mail and also the reason why I've tried to get it working for ath9k<->ath10k. But unfortunately, I had no
> success.
> 
> I have also tried to use your config without the overrides and with overrides without any success.

I'm not sure if it matters, but I was using sw-crypt for both ath9k and ath10k
(and my patched kernel).

>> I think sometimes it worked a bit, and then stopped.  Truth is, my customers interested in IBSS are not doing encryption on the IBSS interface, so I have
>> no plans to work on this soon.  And, even if offered the opportunity, I'm not sure what I could do to improve the problem.  Possibly someone at QCA would
>> have ideas and might share them with me...
>> 
>> 
>>> * IBSS stops working everytime an AP interface is added to the same PHY (it isn't importing whether it is using WPA/WPA2 or configured as open AP) -
>>> tested again with ath9k on the same OpenWrt version and it working quite well with 1x IBSS + 2x AP
>> 
>> One of my customers is using AP + IBSS interface with no obvious problems related to concurrency.  But, maybe they are doing things in a different order.
>> Does it work for you if you bring up AP first and then add IBSS?
>> 
>> This is likely fixable.
> 
> I had to hack a little bit of OpenWrt away but it seems that it works for a simple setup to first create the adhoc interface and then sometimes later add
> the AP interface.

Ok, I'll make a note to test adding IBSS after AP.

Thanks,
Ben


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJV01k7AAoJELbHqkYeJT4Ol4kH/A1Vx0S76imRAVwVx9tXMmT5
zwAEa8vh9v5yF/URxaOiOhKgM0B4YB7Lt0hYgwp5zI9b+JEDpdA1Rj1EiaIAMnmb
Oj7r2f/LAKF1QHD3tZuPNa4v/L1+DwZ3K+zJ462pY6Yw9nOMvyiCRu/cONFJAY2U
dRyw+7tiHJfc11MfxXGNmUR60VyleNqGufZod+Ukh6QnJZHJUw9+xuYMDuugha48
oQ8WrbZIo4nHsg760zfwS6O5QMk3RxDztJnKjpt66uMNPP96zUz2PD38JmBF/H50
re3OHXaW1yGmblYA4AbPtrSyiS5+kaWnI6w6mSHMbhV/e13uL5MZ37Nhzxy81ao=
=XKv/
-----END PGP SIGNATURE-----