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 th
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 dec
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
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
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 hardwar
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 t
> 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
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 i
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 pa
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
> encryp
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 init
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 sequ
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
ath5
13 matches
Mail list logo
