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
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, 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
2012/9/10 Yeoh Chun-Yeow :
> 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(nl
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_KEYTY
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.
Hiya,
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?
I can do some digging into what changed with the encryption stuff and
see if I can figure it out in my (limited) spare time. I can try to do
it sometime ne
> 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.,
>
On Wed, Sep 05, 2012 at 03:31:08PM +0800, Yeoh Chun-Yeow wrote:
> 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
It looks like this particular implementation is hardcoded to use MFP..
> >
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/
On Wed, Sep 05, 2012 at 12:41:16AM +0800, Yeoh Chun-Yeow wrote:
> 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
On Tue, Sep 04, 2012 at 01:35:21PM +0200, Johannes Berg wrote:
> 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, I was assuming that receiving robust unicast management frames
would fa
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
On Tuesday 04 September 2012 18:41:16 Yeoh Chun-Yeow wrote:
> 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 accidenta
On Tue, 2012-09-04 at 18:55 +0200, Christian Lamparter wrote:
> > 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
Hi,
> > 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,
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, w
On Tue, 2012-09-04 at 19:25 +0800, Yeoh Chun-Yeow wrote:
> 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 f
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
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.
Not
On Tue, Sep 04, 2012 at 05:28:40PM +0800, Yeoh Chun-Yeow wrote:
> 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
> followi
On Tue, 2012-09-04 at 17:28 +0800, Yeoh Chun-Yeow wrote:
> 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
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
On Tue, 2012-08-28 at 17:34 +0800, Chun-Yeow Yeoh wrote:
> This patch provides the support of hardware encyrption for
> management frame, including the support of AES CMAC. This
> patch is tested with the following chipsets:
> - AR5213A
> - AR5413
> - AR2413/AR2414
_How_ did you test this? Did you
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 wou
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-
34 matches
Mail list logo
