Re: CT ath10k firmware now supports IBSS + RSN
-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 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- -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CT ath10k firmware now supports IBSS + RSN
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 signature.asc Description: This is a digitally signed message part.
Re: CT ath10k firmware now supports IBSS + RSN
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 roamingI 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 Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CT ath10k firmware now supports IBSS + RSN
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 failed_encryption_ath9k-37_ath10k-67.pcapng.gz Description: application/pcapng failed_encryption_ath10k-c7_ath10k-67.pcapng.gz Description: application/pcapng working_encryption_ath9k-0f.37_ath9k-9e.37.pcapng.gz Description: application/pcapng 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
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 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 Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CT ath10k firmware now supports IBSS + RSN
On 04/13/2015 10:34 PM, Michal Kazior wrote: On 14 April 2015 at 02:10, Ben Greear 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 Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CT ath10k firmware now supports IBSS + RSN
On 14 April 2015 at 02:10, Ben Greear 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Ć -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CT ath10k firmware now supports IBSS + RSN
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 Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CT ath10k firmware now supports IBSS + RSN
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 Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html