Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
On Tuesday 11 September 2012 18:36:27 Nick Kossifidis wrote: > 2012/9/11 Yeoh Chun-Yeow : > >> 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. > > > > How about disabling acks on hw completely and handle them on sw ? > This might keep the engine running ok for unicast frames. > > #define AR5K_DIAG_SW_DIS_ACK 0x0002 /* Disable ACKs */ > #define AR5K_DIAG_SW_DIS_CTS 0x0004 /* Disable CTSs */ No, CTS and ACKs are control frames and not management frames. ___ 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
2012/9/11 Christian Lamparter : > On Tuesday 11 September 2012 18:36:27 Nick Kossifidis wrote: >> 2012/9/11 Yeoh Chun-Yeow : >> >> 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. >> > >> >> How about disabling acks on hw completely and handle them on sw ? >> This might keep the engine running ok for unicast frames. >> >> #define AR5K_DIAG_SW_DIS_ACK 0x0002 /* Disable ACKs */ >> #define AR5K_DIAG_SW_DIS_CTS 0x0004 /* Disable CTSs */ > > No, CTS and ACKs are control frames and not management frames. ACK :-) -- 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] Multi-channel support in AR2313
Hi, I can't point you to any working implementations, sorry. I know that channel change on the older platforms takes time; even "fast channel change" wasn't terribly fast and came with a _lot_ of restrictions. There was some attempt at a virtualised phy with mac80211 and ath9k in the past. It may be worth looking into what was done there. Adrian ___ 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
This is why I asked for a bit of a summary. What specific behaviour are you chasing from the keycache, source/destination MAC address matching and encryption engine? There've apparently been some keycache matching bugs in the past .. Adrian ___ 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
On Tue, 2012-09-11 at 19:36 +0300, Nick Kossifidis wrote: > > 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. > > > > How about disabling acks on hw completely and handle them on sw ? This > might keep the engine running ok for unicast frames. That would achieve what? Even if you could do something with that ... the cure would be worse than the disease for sure! (I'd also appreciate if you guys could drop me from this thread, I have little interest in ath5k I'm just the person pointing out that it isn't as easy to enable MFP as it seems) johannes ___ 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
2012/9/11 Yeoh Chun-Yeow : >> 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. > How about disabling acks on hw completely and handle them on sw ? This might keep the engine running ok for unicast frames. #define AR5K_DIAG_SW_DIS_ACK0x0002 /* Disable ACKs */ #define AR5K_DIAG_SW_DIS_CTS0x0004 /* Disable CTSs */ -- 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
> 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
2012/9/11 Nick Kossifidis : > 2012/9/11 Yeoh Chun-Yeow : >> 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? >> > > Its possible to tell hw to disable decryption so that you can handle > that only on sw, I haven't tested it but that's what docs say. > To be more clear: you can tell the hw to *only* disable decryption and keep doing encryption. -- 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
2012/9/11 Yeoh Chun-Yeow : > 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? > Its possible to tell hw to disable decryption so that you can handle that only on sw, I haven't tested it but that's what docs say. -- 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 > 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
2012/9/11 Yeoh Chun-Yeow : > 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 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. -- 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] Multi-channel support in AR2313
Hi Adrian, Thank you very much for replying. My motivation behind this idea is that, if the network is really dense and the nodes are each equipped with only single radio, then the nodes coordinate with each other and switch their channel to another channel periodically. And this happens in a sequence so that, no node lies hidden all the time with respect to the nodes on different channel. Can you also please suggest me if it's practical and worth implementing the feature on ath5k/openWRT/AR2313 platform? I've configured openWRT to include open802.11s/mac80211 mesh networking and my nodes in the test-bed are all mesh points. I am not completely aware about the implementation details. So, can you please point me to the software that I'll have to modify to implement this feature? Best Regards, Siva. On Sat, Sep 8, 2012 at 9:51 PM, Adrian Chadd wrote: > Hi, > > The problem with doing multi-channel single radio work is that channel > change will take quite a bit of time; so you will have to take that > into account when implementing this. > > Then you have to ensure all the whacky power save stuff works > absolutely correctly.. :-) > > > Adrian > > On 4 September 2012 18:16, Sivateja Patibandla wrote: >> Hi guys, >> >> I'm new to the ath5k driver development. I wanted to implement a >> "multi-channel single radio" based MAC on AR2313 hardware. I'm using >> openWRT distribution. >> Is multi-channel support dependent more on hardware? If so, does >> AR2313 support multi-channel? If not, is it possible to add this >> capability in the ath5k driver? >> Any suggestions and commented will be appreciated. >> >> Thanks & Regards, >> Siva. >> ___ >> 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
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
