* [ath9k-devel] Any idea if multi-vif can work with hw-encryption?
@ 2013-04-03 17:55 Ben Greear
2013-04-03 19:39 ` Adrian Chadd
0 siblings, 1 reply; 6+ messages in thread
From: Ben Greear @ 2013-04-03 17:55 UTC (permalink / raw)
To: ath9k-devel
In the old days, I heard that multiple station VIFs could not work with
hardware encryption. Does anyone know if this is still true?
And if so, is this a hardware/firmware issue, or is it some limitation
that can be fixed in the driver?
I'd like to try offloading at least some of the encryption while
still running multiple station VIFs if possible....
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Any idea if multi-vif can work with hw-encryption?
2013-04-03 17:55 [ath9k-devel] Any idea if multi-vif can work with hw-encryption? Ben Greear
@ 2013-04-03 19:39 ` Adrian Chadd
2013-04-03 21:16 ` Ben Greear
0 siblings, 1 reply; 6+ messages in thread
From: Adrian Chadd @ 2013-04-03 19:39 UTC (permalink / raw)
To: ath9k-devel
.. maybe for later chips and proxysta support?
The problem is making sure that you can do both transmit and receive
MAC addresses when doing encryption and decryption.
Encryption is easier - we get to set which key explicitly. but on
reception it needs to look at both..
Adrian
On 3 April 2013 10:55, Ben Greear <greearb@candelatech.com> wrote:
> In the old days, I heard that multiple station VIFs could not work with
> hardware encryption. Does anyone know if this is still true?
> And if so, is this a hardware/firmware issue, or is it some limitation
> that can be fixed in the driver?
>
> I'd like to try offloading at least some of the encryption while
> still running multiple station VIFs if possible....
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Any idea if multi-vif can work with hw-encryption?
2013-04-03 19:39 ` Adrian Chadd
@ 2013-04-03 21:16 ` Ben Greear
2013-04-03 21:36 ` Adrian Chadd
0 siblings, 1 reply; 6+ messages in thread
From: Ben Greear @ 2013-04-03 21:16 UTC (permalink / raw)
To: ath9k-devel
On 04/03/2013 12:39 PM, Adrian Chadd wrote:
> .. maybe for later chips and proxysta support?
>
> The problem is making sure that you can do both transmit and receive
> MAC addresses when doing encryption and decryption.
>
> Encryption is easier - we get to set which key explicitly. but on
> reception it needs to look at both..
Well, I can verify that it doesn't work in 3.9-rc5+ with AR9380
hardware....
I think I'll focus elsewhere for a while..but if someone wants to make
this work somehow I'll send them some shiny present :)
Even something asymmetric where it encoded in hardware on transmit
and software on rx might be useful...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Any idea if multi-vif can work with hw-encryption?
2013-04-03 21:16 ` Ben Greear
@ 2013-04-03 21:36 ` Adrian Chadd
2013-04-03 21:52 ` Ben Greear
0 siblings, 1 reply; 6+ messages in thread
From: Adrian Chadd @ 2013-04-03 21:36 UTC (permalink / raw)
To: ath9k-devel
On 3 April 2013 14:16, Ben Greear <greearb@candelatech.com> wrote:
> Well, I can verify that it doesn't work in 3.9-rc5+ with AR9380
> hardware....
>
> I think I'll focus elsewhere for a while..but if someone wants to make
> this work somehow I'll send them some shiny present :)
> Even something asymmetric where it encoded in hardware on transmit
> and software on rx might be useful...
Well, you should be able to do asymmetric encryption right now. You
just need to populate the keycache with an invalid source address? Say
all-ones or something?
Adrian
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Any idea if multi-vif can work with hw-encryption?
2013-04-03 21:36 ` Adrian Chadd
@ 2013-04-03 21:52 ` Ben Greear
2013-04-03 23:26 ` Adrian Chadd
0 siblings, 1 reply; 6+ messages in thread
From: Ben Greear @ 2013-04-03 21:52 UTC (permalink / raw)
To: ath9k-devel
On 04/03/2013 02:36 PM, Adrian Chadd wrote:
> On 3 April 2013 14:16, Ben Greear <greearb@candelatech.com> wrote:
>
>> Well, I can verify that it doesn't work in 3.9-rc5+ with AR9380
>> hardware....
>>
>> I think I'll focus elsewhere for a while..but if someone wants to make
>> this work somehow I'll send them some shiny present :)
>
>> Even something asymmetric where it encoded in hardware on transmit
>> and software on rx might be useful...
>
> Well, you should be able to do asymmetric encryption right now. You
> just need to populate the keycache with an invalid source address? Say
> all-ones or something?
It sounds so easy when you say that :)
I have a fairly dim understanding of how all the encryption
works..so probably more than I'm up for at this time.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ath9k-devel] Any idea if multi-vif can work with hw-encryption?
2013-04-03 21:52 ` Ben Greear
@ 2013-04-03 23:26 ` Adrian Chadd
0 siblings, 0 replies; 6+ messages in thread
From: Adrian Chadd @ 2013-04-03 23:26 UTC (permalink / raw)
To: ath9k-devel
On 3 April 2013 14:52, Ben Greear <greearb@candelatech.com> wrote:
>> Well, you should be able to do asymmetric encryption right now. You
>> just need to populate the keycache with an invalid source address? Say
>> all-ones or something?
>
>
> It sounds so easy when you say that :)
>
> I have a fairly dim understanding of how all the encryption
> works..so probably more than I'm up for at this time.
*laugh*
So do I. :-)
for RX, the hardware has to match the source key in the keycache
somehow, and use that key for decryption.
For TX, the hardware is _told_ which key to use when you queue a TX
descriptor - there's a keyIndex parameter saying which keycache slot
to use.
I don't _think_ that for TX it needs to care about the MAC in the keycache slot.
For RX however, it needs to match. The question is what it's matching
on. if it just matches on the SA, then you will hit the issue where
you have multiple frames with SA == AP, but DA == (lots of different
VIF mac addresses.) So the keycache won't work with RX there out of
the box. I need to go digging through how the keycache is implemented
in various chips to see what other fun matching types there are. I
think there's a way to match both SA _AND_ DA, but I've never gone
looking.
So what you could do is setup a software RX keycache entry for a given
peer, but the TX keycache slot is a hardware slot. And just populate
that keycache slot. It shouldn't use it for RX as the TX keycache
entries have all 0xff's in the MAC, or something like that.
Adrian
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-04-03 23:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-03 17:55 [ath9k-devel] Any idea if multi-vif can work with hw-encryption? Ben Greear
2013-04-03 19:39 ` Adrian Chadd
2013-04-03 21:16 ` Ben Greear
2013-04-03 21:36 ` Adrian Chadd
2013-04-03 21:52 ` Ben Greear
2013-04-03 23:26 ` Adrian Chadd
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.