Re: [ath5k-devel] Power Saving Mode in ath5k
Unfortunately, ath5k has no power save support. The IEEE80211_HW_SUPPORTS_PS flag is not there. Chun-Yeow On Fri, Nov 1, 2013 at 5:03 AM, Stratos Keranidis wrote: > Hello, > > I am trying to enable the Power Saving Mode (PSM) in ath5k. > in the AR5424 chipset, by using the command: > iw wlan0 power on > > However, I get the message that the operation is not suppoted: > > Error for wireless request "Set Power Management" (8B2C) : > SET failed on device wlan0 ; Operation not supported. > > > I followed the same approach for the AR9380 chipset using ath9k and it worked, > as I observed that the ping command results in increased values when the card > is > in PSM mode (>100ms) and not when the card is in PSM-disabled mode (~1ms). > > Can you inform me on the status of PSM implementation in ath5k and chipsets > that potentially support it? > > In the case that it is supported, can you also advise on how to enable it? > > Thank you in advance, > Stratos. > > > > ___ > ath5k-devel mailing list > ath5k-devel@lists.ath5k.org > https://lists.ath5k.org/mailman/listinfo/ath5k-devel > > ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] mac80211 and kernel 3.8.13 1/2 speed as with madwifi and kernel 2.6.23 and bad respons time
What is the rate control algorithm used by your mac80211? Try use minstrel perhaps. On Sep 17, 2013 7:52 AM, "Bob Copeland" wrote: > On Tue, Sep 17, 2013 at 11:27:13AM -0300, Beat Meier wrote: > > Anyone having same issue? I realy have to switch to this driver because > > madwifi not anymore supported and I have serveral bad issues but with > > this throughput impossible to use for me > > How can I help to debug the problem? > > I don't see anything like this, but I can't recall the last time > I had madwifi working either. A capture of both scenarios would > help. > > -- > Bob Copeland %% www.bobcopeland.com > ___ > ath5k-devel mailing list > ath5k-devel@lists.ath5k.org > https://lists.ath5k.org/mailman/listinfo/ath5k-devel > ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
> To be more clear: you can tell the hw to *only* disable decryption and > keep doing encryption. But the question here is that during Rx, need to do SW decryption for management frame and then HW decryption for unicast data frame for all the frame coming from the same STA. I still not so sure how to do that. Jouni said that the workaround is to re-encrypt(incorrectly) received robust unicast management frames if hwaccel for CCMP was configured for the transmitting STA (this is to undo the incorrect decryption done by the hardware) and then pass the encrypted frame to mac80211 for software decryption. Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Nick > Nope, with nohwcrypt we don't initialize the hw engine at all, we just > tell hw that data is not encrypted and that nothing should be done > about it. With these hw options from what I understand from docs we > can initialize the engine but use only part of it, eg. use only hw > encryption or only hw decryption. It might be useful in your case. The problem of ath5k right seems to be that: ' If CCMP HW encryption is enabled, HW encryption for unicast data frame and SW encryption for unicast management frame are possible for TX. But for RX, both the unicast data frame and unicast management frame are decrypted by the HW instead of doing only SW decryption for unicast management frame. With the help of PCU DIAG register, possible to separate this? - Chun-Yeow > -- > GPG ID: 0xEE878588 > As you read this post global entropy rises. Have Fun ;-) > Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Nick > Have you tried disabing RX or TX only encryption/decryption on hw > trough PCU DIAG register ? Nope. Is that same with loading the ath5k with nohwcrypt=1 to do purely SW encryption/decryption? Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, all For your information, my submitted patch has allowed me to do the following and mainly to setup the secured mesh 802.11s using authsae: 1. Key installations for the following: /* key to protect integrity of multicast mgmt frames tx*/ install_key(nlcfg, NULL, CIPHER_AES_CMAC, NL80211_KEYTYPE_GROUP, 4, mgtk_tx); /* key to encrypt multicast data traffic */ install_key(nlcfg, NULL, CIPHER_CCMP, NL80211_KEYTYPE_GROUP, 0, mgtk_tx); /* key to encrypt/decrypt unicast data AND mgmt traffic to/from this peer */ install_key(&nlcfg, peer, CIPHER_CCMP, NL80211_KEYTYPE_PAIRWISE, 0, mtk); /* key to decrypt multicast data traffic from this peer */ install_key(&nlcfg, peer, CIPHER_CCMP, NL80211_KEYTYPE_GROUP, 0, peer_mgtk); /* to check integrity of multicast mgmt frames from this peer */ install_key(&nlcfg, peer, CIPHER_AES_CMAC, NL80211_KEYTYPE_GROUP, 4, peer_mgtk); 2. By using the submitted patch, how ever as Jouni has pointed out that testing with ath5k implementation alone may not be correct, due to the following statement: If the CCMP processing is done incorrectly, they could both mangle the results in the same way to hide the issue. thus I revert back by not disabling the IEEE80211_KEY_FLAG_SW_MGMT. However, with this, it has showed that robust unicast management frame is encrypted in SW but is decrypted wrongly in SW (perhaps HW decrypt it due to the HW accl enabling for unicast data frame). Hope this help. Thanks. Regards, Chun-Yeow On Mon, Sep 10, 2012 at 9:13 PM, Kalle Valo wrote: > Adrian Chadd writes: > >> Yeoh - can you please email me privately with a summary of what you >> implemented, what you've tested and what worked / what didn't work? > > Why privately? Better to have all the information public, you never know > if someone finds the info from the web and picks up the work. > > -- > Kalle Valo ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
> So yes, if you want to enable support for MFP, you cannot do it unless > the driver is able to handle both CCMP and BIP protection for robust > management frames. In case of ath5k, I would assume there are two > options: > - only enable MFP if software encryption is used for all frames (i.e., > no hwaccel even for data frames) > - implement workaround to re-encrypt(incorrectly) received robust > unicast management frames if hwaccel for CCMP was configured for the > transmitting STA (this is to undo the incorrect decryption done by the > hardware) and then pass the encrypted frame to mac80211 for software > decryption; with this option, you could advertise MFP support even > with CCMP hwaccel enabled No luck and still cannot work out how to re-encrypt the received robust unicast management frames if hwaccel for CCMP was configured. Need to stick with first option then. --- Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Jouni > Could you please describe what exactly you mean with "current secured > mesh requires the AES CMAC to be enabled" and what is that claim based > on? I am based on the authsae source code for secured mesh setup which can be found at: https://github.com/cozybit/authsae/blob/master/linux/meshd-nl80211.c There are total 5 keys for secured mesh: /* key to protect integrity of multicast mgmt frames tx*/ install_key(nlcfg, NULL, CIPHER_AES_CMAC, NL80211_KEYTYPE_GROUP, 4, mgtk_tx); /* key to encrypt multicast data traffic */ install_key(nlcfg, NULL, CIPHER_CCMP, NL80211_KEYTYPE_GROUP, 0, mgtk_tx); /* key to encrypt/decrypt unicast data AND mgmt traffic to/from this peer */ install_key(&nlcfg, peer, CIPHER_CCMP, NL80211_KEYTYPE_PAIRWISE, 0, mtk); /* key to decrypt multicast data traffic from this peer */ install_key(&nlcfg, peer, CIPHER_CCMP, NL80211_KEYTYPE_GROUP, 0, peer_mgtk); /* to check integrity of multicast mgmt frames from this peer */ install_key(&nlcfg, peer, CIPHER_AES_CMAC, NL80211_KEYTYPE_GROUP, 4, peer_mgtk); > Any pointers to the specific standard clause(s) that say that? I have not gone through the standard on this. - Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Johannes > Well, that's a separate question. Of course we could enable it, but what > would the point be? You don't have CCM for management frames right now, > so CMAC is pretty useless? And if you had CCM for management frames, say > with the things discussed in the p54 thread, then you could just enable > both, right? We will load the ath5k with nohwcrypt=, so no hardware encryption at all. But to proceed with key installation using AES CMAC to be processed in software, we need somethings related to: http://www.spinics.net/lists/linux-wireless/msg96187.html Otherwise, we may need to bypass the cfg80211_supported_cipher_suite checking: http://www.spinics.net/lists/linux-wireless/msg95951.html Is this relevant? --- Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Johannes > I would guess that hardware *decryption* is faulty, maybe only one > action frame needs to be correct and so if one of them is nohwcrypt=1 it > still works? Yes, you are correct. Case 3 is working only accidentally not always if the mesh node loaded with nohwcrypt=1 is reboot. So, with following case is also not working. mesh1: ath5k loaded without nohwcrypt=1 (with IEEE80211_KEY_FLAG_SW_MGMT enabled) mesh2: ath5k loaded without nohwcrypt=1 (with IEEE80211_KEY_FLAG_SW_MGMT enabled) Can we conclude that unicast data frames get processed in hardware and robust unicast management frames get processed in software for CCMP are not working. By the way, current secured mesh requires the AES CMAC to be enabled. But without enabling IEEE80211_HW_MFP_CAPABLE, the key cannot be added since this cipher suite is considered not supported. But actually AES CMAC can be done in software. Any work around on this? --- Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Jouni I have retested with the following: case 1 with submitted patch: mesh1: ath5k nohwcrypt=1 mesh2: ath5k (no IEEE80211_KEY_FLAG_SW_MGMT) Result: Both of them are not able to ping each other. Also, the PREP action frame is not able to decrypted by another node. case 2 with submitted patch: mesh1: ath5k nohwcrypt=1 mesh2: ath5k nohwcrypt=1 Result: They are able to ping each other. case 3 with submitted patch but enable IEEE80211_KEY_FLAG_SW_MGMT: mesh1: ath5k nohwcrypt=1 mesh2: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) Result: They are able to ping each other case 4 with submitted patch but enable IEEE80211_KEY_FLAG_SW_MGMT: mesh1: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) mesh2: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) Result: Both of them are not able to ping each other. Also, the PREP action frame is not able to decrypted by another node. So can we conclude that hardware encryption is not working for both robust unicast management frame and also unicast data frame? I am confuse why on case 4, it is not working? Please advice. Thanks Chun-Yeow On Tue, Sep 4, 2012 at 7:21 PM, Yeoh Chun-Yeow wrote: > Hi, Jouni > >> Depends on what those nodes were.. If they were both using the same >> ath5k implementation, then no, that would not be enough. > Both of nodes are using ath5k. > >> so working with AR2414 or even AR5213 does not necessarily mean that this >> would work >> with AR5210, AR5211, or AR5212. > Noted. > >> I would also verify that unicast data frames get processed in hardware and >> robust >> management frames in software. > I have retested with the following: > > mesh1: ath5k nohwcrypt=1 > mesh2: ath5k (no IEEE80211_KEY_FLAG_SW_MGMT) > Result: Both of them are not able to ping each other. Also, the PREP > action frame is not able to decrypted by another node. > > mesh1: ath5k nohwcrypt=1 > mesh2: ath5k nohwcrypt=1 > Result: They are able to ping each other. > > mesh1: ath5k nohwcrypt=1 > mesh2: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) > Result: They are able to ping each other > > mesh1: > mesh2I also try to enable back the IEEE80211_KEY_FLAG_SW_MGMT flags. > Also it does not work. So can we conclude that hardware encryption is > not working for both robust unicast management frame and also unicast > data frame? > > Please advice. Thanks > > > Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Jouni > Depends on what those nodes were.. If they were both using the same > ath5k implementation, then no, that would not be enough. Both of nodes are using ath5k. > so working with AR2414 or even AR5213 does not necessarily mean that this > would work > with AR5210, AR5211, or AR5212. Noted. > I would also verify that unicast data frames get processed in hardware and > robust > management frames in software. I have retested with the following: mesh1: ath5k nohwcrypt=1 mesh2: ath5k (no IEEE80211_KEY_FLAG_SW_MGMT) Result: Both of them are not able to ping each other. Also, the PREP action frame is not able to decrypted by another node. mesh1: ath5k nohwcrypt=1 mesh2: ath5k nohwcrypt=1 Result: They are able to ping each other. mesh1: ath5k nohwcrypt=1 mesh2: ath5k (with IEEE80211_KEY_FLAG_SW_MGMT) Result: They are able to ping each other mesh1: mesh2I also try to enable back the IEEE80211_KEY_FLAG_SW_MGMT flags. Also it does not work. So can we conclude that hardware encryption is not working for both robust unicast management frame and also unicast data frame? Please advice. Thanks Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Johannes > _How_ did you test this? Did you test that management frames are > properly encrypted using AES CCM, and not mangled when decrypted? I have setup the two mesh nodes using the secured mesh with the following key installation: /* key to encrypt/decrypt unicast data AND mgmt traffic to/from this peer */ install_key(&nlcfg, peer, CIPHER_CCMP, NL80211_KEYTYPE_PAIRWISE, 0, mtk); I confirm that the hardware key for CCMP is set and IEEE80211_KEY_FLAG_SW_MGMT is not enabled in mac80211-ops.c. Both nodes are able to ping each others. Is this enough? Please advice. Thanks --- Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hi, Adrian I have tested with secured mesh on AR5213A, AR5413 and AR2413/AR2414. It seems work for me. > I suggest that you at least wrap this in a run-time configuration item > that defaults to off or something. Yes, I do agree on this. But if more peoples are able to test it and confirm, it would be better. Thanks Regards, Chun-Yeow On Tue, Sep 4, 2012 at 3:24 AM, Adrian Chadd wrote: > On 31 August 2012 08:24, Yeoh Chun-Yeow wrote: >> Hi, Adrian >> >> Appreciate your testing on this. >> > > Hi, > > I don't have time to test ath5k stuff. I'm just an Atheros employee > who hacks on FreeBSD in his spare time. I'm lurking to provide > feedback. :-) > > I suggest that you at least wrap this in a run-time configuration item > that defaults to off or something. i'd be really worried about this > stuff having subtle bugs that aren't well documented; it may work for > you but it may induce weird behaviour in other setups. > > > > Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Problems when using hostapd on meshnode
Hi, Kai Do you mind to share your "ifconfig" output? Are both ap0 and mesh0 using the same MAC addresses? Regards, Chun-Yeow ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
