Hi,
My test plateform is:
2 equipements
Both equipment used compat version 2015-07-21 from openwrt.
Both equipment used security WPA2
The equipment #1 is an AP.
The Group rekey interval is set to 3601s
The Pair rekey interval set to 50s (I reduced this value to show
the issue often)
The Master rekey interval is set to 86400 s.
The equipment #2 is a sta+wds
I used a 5GHz channel to have a free channel (without other AP)
I connected a computer on each equipment.
To reproduce the issue:
I ran iperf udp@50Mbps from computer connected to the AP to the
computer connected to the sta. After several WPA2 rekeying, iperf server
side didn't received any frame.
I investigated in the driver. All packets are dropped in sta side,
because the function ieee80211_crypto_ccmp_decrypt return
Rx_DROP_UNUSABLE. This function return this code because the test
if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0) return
true.
Have you any idea to fix this issue?
Thanks for your help.
Cedric.
> >
> > Hi,
> >
> > I'm not a WPA expert and security expert,
> >
> > Could you explain why the patch sent by Alexander Wetzel break the
> security properties of this code?
> >
> > The Alexander's patch is in attachment.
> >
> > Thanks for your help.
>
> It simply disables the replay attack detection :) You could receive the
> same (encrypted) packet twice and not throw away the second one.
> The author of the patch never said that this patch is a "fix", it is rather
> a debug step to understand what happens.
>
> PTK rekeying is a problem from the spec point of view. In Intel, we did
> inquiries and in the end we understood that what we should really do
> whenever we get to a situation where we need to rekey the PTK is to
> disconnect and reconnect. Only weird configuration allow to change the PTK
> more frequently than after X packet (don't remember what X is bu something
> like 2^32 which is big enough to hold the connection for days...).
>
> IIRC, Intel devices don't have problems in Tx while we rekey because we
> give the key material along with the packet itself, so that we can't get to
> a situation where we have old PN and new key. The Atheros devices separate
> the key material and the Tx packet (which is a perfectly valid design
> decision), but this introduce the possibility to use the old PN with a new
> key meaning that the recipient could decrypt the packet after the new key
> has been installed, but it would also update the PN to be high and discard
> all the next packets that will come with a new (low) PN.
> So essentially, this is a bug in the TX'ing side. Fixing it requires to hit
> the performance which is not something people are willing to do, when the
> bug is really in the spec.
> That's what I remember, but I may be wrong.
>
Thanks for your answer.
Do you know if we can have the same issue with ATH10K chipset?
On 12/31/2015 02:15 AM, voncken wrote:
> Thanks for your answer.
> Do you know if we can have the same issue with ATH10K chipset?
Someone else reported re-keying problems with ath10k recently, and
it appears to be a bug in in upstream firmware, probably related to
the same issue that keeps 802.11r from working in some upstream
firmware...
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN
<[email protected]> wrote:
> Hi,
>
> My test plateform is:
> 2 equipements
> Both equipment used compat version 2015-07-21 from openwrt.
> Both equipment used security WPA2
>
> The equipment #1 is an AP.
> The Group rekey interval is set to 3601s
> The Pair rekey interval set to 50s (I reduced this value to show
> the issue often)
> The Master rekey interval is set to 86400 s.
>
> The equipment #2 is a sta+wds
>
> I used a 5GHz channel to have a free channel (without other AP)
> I connected a computer on each equipment.
>
> To reproduce the issue:
> I ran iperf udp@50Mbps from computer connected to the AP to the
> computer connected to the sta. After several WPA2 rekeying, iperf server
> side didn't received any frame.
>
> I investigated in the driver. All packets are dropped in sta side,
> because the function ieee80211_crypto_ccmp_decrypt return
> Rx_DROP_UNUSABLE. This function return this code because the test
> if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0) return
> true.
>
> Have you any idea to fix this issue?
>
I don't remember exactly what we had, but you may look at
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742
On Thu, Dec 31, 2015 at 10:12 AM, voncken <[email protected]> wrote:
>
> Hi,
>
> I'm not a WPA expert and security expert,
>
> Could you explain why the patch sent by Alexander Wetzel break the security properties of this code?
>
> The Alexander's patch is in attachment.
>
> Thanks for your help.
It simply disables the replay attack detection :)
You could receive the same (encrypted) packet twice and not throw away
the second one.
The author of the patch never said that this patch is a "fix", it is
rather a debug step to understand what happens.
PTK rekeying is a problem from the spec point of view. In Intel, we
did inquiries and in the end we understood that what we should really
do whenever we get to a situation where we need to rekey the PTK is to
disconnect and reconnect. Only weird configuration allow to change the
PTK more frequently than after X packet (don't remember what X is bu
something like 2^32 which is big enough to hold the connection for
days...).
IIRC, Intel devices don't have problems in Tx while we rekey because
we give the key material along with the packet itself, so that we
can't get to a situation where we have old PN and new key. The Atheros
devices separate the key material and the Tx packet (which is a
perfectly valid design decision), but this introduce the possibility
to use the old PN with a new key meaning that the recipient could
decrypt the packet after the new key has been installed, but it would
also update the PN to be high and discard all the next packets that
will come with a new (low) PN.
So essentially, this is a bug in the TX'ing side. Fixing it requires
to hit the performance which is not something people are willing to
do, when the bug is really in the spec.
That's what I remember, but I may be wrong.
>
> > -----Message d'origine-----
> > De : [email protected] [mailto:linux-wireless-
> > [email protected]] De la part de voncken
> > Envoyé : mardi 29 décembre 2015 16:24
> > À : 'Emmanuel Grumbach'
> > Cc : 'linux-wireless'; 'Johannes Berg'
> > Objet : RE: Mac80211 : Wpa rekeying issue
> >
> > > -----Message d'origine-----
> > > De : Emmanuel Grumbach [mailto:[email protected]] Envoyé : mardi 29
> > > décembre 2015 15:20 À : Cedric VONCKEN Cc : linux-wireless Objet : Re:
> > > Mac80211 : Wpa rekeying issue
> > >
> > > On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN
> > > <[email protected]>
> > > wrote:
> > > > Hi,
> > > >
> > > > My test plateform is:
> > > > 2 equipements
> > > > Both equipment used compat version 2015-07-21 from openwrt.
> > > > Both equipment used security WPA2
> > > >
> > > > The equipment #1 is an AP.
> > > > The Group rekey interval is set to 3601s
> > > > The Pair rekey interval set to 50s (I reduced this value to
> > > > show the issue often)
> > > > The Master rekey interval is set to 86400 s.
> > > >
> > > > The equipment #2 is a sta+wds
> > > >
> > > > I used a 5GHz channel to have a free channel (without other AP) I
> > > > connected a computer on each equipment.
> > > >
> > > > To reproduce the issue:
> > > > I ran iperf udp@50Mbps from computer connected to the AP to
> > > > the computer connected to the sta. After several WPA2 rekeying,
> > > > iperf server side didn't received any frame.
> > > >
> > > > I investigated in the driver. All packets are dropped in sta side,
> > > > because the function ieee80211_crypto_ccmp_decrypt return
> > > > Rx_DROP_UNUSABLE. This function return this code because the test
> > > > if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0)
> > > > return true.
> > > >
> > > > Have you any idea to fix this issue?
> > > >
> > >
> > > I don't remember exactly what we had, but you may look at
> > > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742
> >
> > Thanks for the link, I think I'm in the same situation.
> >
> > How can I fix this issue?
> >
> > Because the patch sent by Alexander Wetzel was rejected by Johannes (for
> > security reason), and if I disable the hw crypto I will have performance
> > issue.
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> > in the body of a message to [email protected] More majordomo info
> > at http://vger.kernel.org/majordomo-info.html
> -----Message d'origine-----
> De : Emmanuel Grumbach [mailto:[email protected]]
> Envoyé : mardi 29 décembre 2015 15:20
> À : Cedric VONCKEN
> Cc : linux-wireless
> Objet : Re: Mac80211 : Wpa rekeying issue
>
> On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN <[email protected]>
> wrote:
> > Hi,
> >
> > My test plateform is:
> > 2 equipements
> > Both equipment used compat version 2015-07-21 from openwrt.
> > Both equipment used security WPA2
> >
> > The equipment #1 is an AP.
> > The Group rekey interval is set to 3601s
> > The Pair rekey interval set to 50s (I reduced this value to
> > show the issue often)
> > The Master rekey interval is set to 86400 s.
> >
> > The equipment #2 is a sta+wds
> >
> > I used a 5GHz channel to have a free channel (without other AP) I
> > connected a computer on each equipment.
> >
> > To reproduce the issue:
> > I ran iperf udp@50Mbps from computer connected to the AP to
> > the computer connected to the sta. After several WPA2 rekeying, iperf
> > server side didn't received any frame.
> >
> > I investigated in the driver. All packets are dropped in sta side,
> > because the function ieee80211_crypto_ccmp_decrypt return
> > Rx_DROP_UNUSABLE. This function return this code because the test
> > if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0)
> > return true.
> >
> > Have you any idea to fix this issue?
> >
>
> I don't remember exactly what we had, but you may look at
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742
Thanks for the link, I think I'm in the same situation.
How can I fix this issue?
Because the patch sent by Alexander Wetzel was rejected by Johannes (for security reason), and if I disable the hw crypto I will have performance issue.
Hi,
I'm not a WPA expert and security expert,
Could you explain why the patch sent by Alexander Wetzel break the security properties of this code?
The Alexander's patch is in attachment.
Thanks for your help.
> -----Message d'origine-----
> De : [email protected] [mailto:linux-wireless-
> [email protected]] De la part de voncken
> Envoyé : mardi 29 décembre 2015 16:24
> À : 'Emmanuel Grumbach'
> Cc : 'linux-wireless'; 'Johannes Berg'
> Objet : RE: Mac80211 : Wpa rekeying issue
>
> > -----Message d'origine-----
> > De : Emmanuel Grumbach [mailto:[email protected]] Envoyé : mardi 29
> > décembre 2015 15:20 À : Cedric VONCKEN Cc : linux-wireless Objet : Re:
> > Mac80211 : Wpa rekeying issue
> >
> > On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN
> > <[email protected]>
> > wrote:
> > > Hi,
> > >
> > > My test plateform is:
> > > 2 equipements
> > > Both equipment used compat version 2015-07-21 from openwrt.
> > > Both equipment used security WPA2
> > >
> > > The equipment #1 is an AP.
> > > The Group rekey interval is set to 3601s
> > > The Pair rekey interval set to 50s (I reduced this value to
> > > show the issue often)
> > > The Master rekey interval is set to 86400 s.
> > >
> > > The equipment #2 is a sta+wds
> > >
> > > I used a 5GHz channel to have a free channel (without other AP) I
> > > connected a computer on each equipment.
> > >
> > > To reproduce the issue:
> > > I ran iperf udp@50Mbps from computer connected to the AP to
> > > the computer connected to the sta. After several WPA2 rekeying,
> > > iperf server side didn't received any frame.
> > >
> > > I investigated in the driver. All packets are dropped in sta side,
> > > because the function ieee80211_crypto_ccmp_decrypt return
> > > Rx_DROP_UNUSABLE. This function return this code because the test
> > > if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0)
> > > return true.
> > >
> > > Have you any idea to fix this issue?
> > >
> >
> > I don't remember exactly what we had, but you may look at
> > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742
>
> Thanks for the link, I think I'm in the same situation.
>
> How can I fix this issue?
>
> Because the patch sent by Alexander Wetzel was rejected by Johannes (for
> security reason), and if I disable the hw crypto I will have performance
> issue.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to [email protected] More majordomo info
> at http://vger.kernel.org/majordomo-info.html
On Thu, 2015-12-31 at 10:41 +0200, Emmanuel Grumbach wrote:
> It simply disables the replay attack detection :)
> You could receive the same (encrypted) packet twice and not throw
> away the second one.
Correct.
> PTK rekeying is a problem from the spec point of view.
Which was/is being addressed too, with different key index being
allowed now. We just haven't implemented it yet, and in the case at
hand the AP also won't be requesting it and the enhancement wouldn't be
used anyway.
> In Intel, we
> did inquiries and in the end we understood that what we should really
> do whenever we get to a situation where we need to rekey the PTK is
> to disconnect and reconnect. Only weird configuration allow to change
> the PTK more frequently than after X packet (don't remember what X is
> but something like 2^32 which is big enough to hold the connection
> for days...).
wpa_supplicant could easily disconnect.
> IIRC, Intel devices don't have problems in Tx while we rekey because
> we give the key material along with the packet itself, so that we
> can't get to a situation where we have old PN and new key.
Yeah, that's my recollection as well. Emmanuel, remember though we're
going to change this, which could become problematic. We might want to
implement the disconnection once we change it, and also implement the
new spec way of PTK rekeying (with key index).
> The Atheros
> devices separate the key material and the Tx packet (which is a
> perfectly valid design decision), but this introduce the possibility
> to use the old PN with a new key meaning that the recipient could
> decrypt the packet after the new key has been installed, but it would
> also update the PN to be high and discard all the next packets that
> will come with a new (low) PN.
> So essentially, this is a bug in the TX'ing side. Fixing it requires
> to hit the performance which is not something people are willing to
> do, when the bug is really in the spec.
> That's what I remember, but I may be wrong.
It matches what I remember too :)
johannes
On Tue, 2016-01-05 at 11:54 +0100, Matthias May wrote:
>
> Not safe as in "access to stuff which has to be locked", or not safe
> as
> in "a CCMP replay attack is possible"?
> When changing this we argumented that since we are not really
> connected
> yet, a CCMP replay attack doesn't really make sense.
>
It's a bit more complicated than my first look suggested, it seems.
However, I'm not sure what effect your patch is supposed to have.
You're skipping CCMP replay checking and update when not authorized
yet, at which point the station isn't receiving frames anyway (though
they'd be checked for all this, they'd later be discarded).
Once it becomes authorized, you do the checks. However, it never
becomes unauthorized again, even for rekeying, so for the PTK rekeying
issue at hand it's pretty much a no-op?
johannes
PS: the comment in your patch is also wrong:
> + /* If we are a station update the ccmp counter only when we are
> + * authorised. For all other modes always update. */
> + if (!rx->sta ||
> + (rx->sta && test_sta_flag(rx->sta, WLAN_STA_AUTHORIZED)) ) {
There's no check for "if we are a station" here.
On Wed, 2016-01-06 at 10:09 +0100, Matthias May wrote:
>
> afaik it solves the issue that when a STA roames from AP1 to AP2, and
> key material is installed at different times.
> We observed encrypted frames which had a wrong CCMP counter. If the
> STA
> updates it's counter with these frames then depending on the wrong
> CCMP
> value received, up to a few hundred frames were dropped.
I don't really see how it has any effect there either, since in that
case the old key material should be deleted long before the new one is
installed, so the cross-over that causes the PN update problem with
rekeying can't happen?
> Not exactly the same as rekeying but the effect are pretty similar.
Ignoring the discussion about the effect of the patch in roaming, the
patch really can't do anything for rekeying since the station never
goes back to !authorized in that case, so it can't really be relevant
for this thread.
johannes
On 31/12/15 09:41, Emmanuel Grumbach wrote:
> On Thu, Dec 31, 2015 at 10:12 AM, voncken <[email protected]> wrote:
>>
>> Hi,
>>
>> I'm not a WPA expert and security expert,
>>
>> Could you explain why the patch sent by Alexander Wetzel break the security properties of this code?
>>
>> The Alexander's patch is in attachment.
>>
>> Thanks for your help.
>
> It simply disables the replay attack detection :)
> You could receive the same (encrypted) packet twice and not throw away
> the second one.
> The author of the patch never said that this patch is a "fix", it is
> rather a debug step to understand what happens.
>
> PTK rekeying is a problem from the spec point of view. In Intel, we
> did inquiries and in the end we understood that what we should really
> do whenever we get to a situation where we need to rekey the PTK is to
> disconnect and reconnect. Only weird configuration allow to change the
> PTK more frequently than after X packet (don't remember what X is bu
> something like 2^32 which is big enough to hold the connection for
> days...).
>
> IIRC, Intel devices don't have problems in Tx while we rekey because
> we give the key material along with the packet itself, so that we
> can't get to a situation where we have old PN and new key. The Atheros
> devices separate the key material and the Tx packet (which is a
> perfectly valid design decision), but this introduce the possibility
> to use the old PN with a new key meaning that the recipient could
> decrypt the packet after the new key has been installed, but it would
> also update the PN to be high and discard all the next packets that
> will come with a new (low) PN.
> So essentially, this is a bug in the TX'ing side. Fixing it requires
> to hit the performance which is not something people are willing to
> do, when the bug is really in the spec.
> That's what I remember, but I may be wrong.
We've encountered exactly this problem in a mix of devices where one
applies key material faster than the other. (ath9k and aquilla)
As a workaround we check on the STA if we are authorized when
updating/checking CCMP. (see attached patches)
Not sure what the performance impact of that is.
Is this something which might be interesting to upstream?
>
>>
>>> -----Message d'origine-----
>>> De : [email protected] [mailto:linux-wireless-
>>> [email protected]] De la part de voncken
>>> Envoyé : mardi 29 décembre 2015 16:24
>>> À : 'Emmanuel Grumbach'
>>> Cc : 'linux-wireless'; 'Johannes Berg'
>>> Objet : RE: Mac80211 : Wpa rekeying issue
>>>
>>> > -----Message d'origine-----
>>>> De : Emmanuel Grumbach [mailto:[email protected]] Envoyé : mardi 29
>>>> décembre 2015 15:20 À : Cedric VONCKEN Cc : linux-wireless Objet : Re:
>>>> Mac80211 : Wpa rekeying issue
>>>>
>>>> On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN
>>>> <[email protected]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> My test plateform is:
>>>>> 2 equipements
>>>>> Both equipment used compat version 2015-07-21 from openwrt.
>>>>> Both equipment used security WPA2
>>>>>
>>>>> The equipment #1 is an AP.
>>>>> The Group rekey interval is set to 3601s
>>>>> The Pair rekey interval set to 50s (I reduced this value to
>>>>> show the issue often)
>>>>> The Master rekey interval is set to 86400 s.
>>>>>
>>>>> The equipment #2 is a sta+wds
>>>>>
>>>>> I used a 5GHz channel to have a free channel (without other AP) I
>>>>> connected a computer on each equipment.
>>>>>
>>>>> To reproduce the issue:
>>>>> I ran iperf udp@50Mbps from computer connected to the AP to
>>>>> the computer connected to the sta. After several WPA2 rekeying,
>>>>> iperf server side didn't received any frame.
>>>>>
>>>>> I investigated in the driver. All packets are dropped in sta side,
>>>>> because the function ieee80211_crypto_ccmp_decrypt return
>>>>> Rx_DROP_UNUSABLE. This function return this code because the test
>>>>> if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0)
>>>>> return true.
>>>>>
>>>>> Have you any idea to fix this issue?
>>>>>
>>>>
>>>> I don't remember exactly what we had, but you may look at
>>>> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742
>>>
>>> Thanks for the link, I think I'm in the same situation.
>>>
>>> How can I fix this issue?
>>>
>>> Because the patch sent by Alexander Wetzel was rejected by Johannes (for
>>> security reason), and if I disable the hw crypto I will have performance
>>> issue.
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>>> in the body of a message to [email protected] More majordomo info
>>> at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Matthias May
Software Engineer
Neratec Solutions AG
Postfach 83, CH-8608 Bubikon, Switzerland
Direct: +41 55 253 2074
Office: +41 55 253 2000
Fax: +41 55 253 2070
email: [email protected]
Web: http://www.neratec.com
On 05/01/16 16:50, Johannes Berg wrote:
> On Tue, 2016-01-05 at 11:54 +0100, Matthias May wrote:
>>
>> Not safe as in "access to stuff which has to be locked", or not safe
>> as
>> in "a CCMP replay attack is possible"?
>> When changing this we argumented that since we are not really
>> connected
>> yet, a CCMP replay attack doesn't really make sense.
>>
>
> It's a bit more complicated than my first look suggested, it seems.
>
> However, I'm not sure what effect your patch is supposed to have.
> You're skipping CCMP replay checking and update when not authorized
> yet, at which point the station isn't receiving frames anyway (though
> they'd be checked for all this, they'd later be discarded).
>
> Once it becomes authorized, you do the checks. However, it never
> becomes unauthorized again, even for rekeying, so for the PTK rekeying
> issue at hand it's pretty much a no-op?
>
afaik it solves the issue that when a STA roames from AP1 to AP2, and
key material is installed at different times.
We observed encrypted frames which had a wrong CCMP counter. If the STA
updates it's counter with these frames then depending on the wrong CCMP
value received, up to a few hundred frames were dropped.
Not exactly the same as rekeying but the effect are pretty similar.
> johannes
>
> PS: the comment in your patch is also wrong:
>
>> + /* If we are a station update the ccmp counter only when we are
>> + * authorised. For all other modes always update. */
>> + if (!rx->sta ||
>> + (rx->sta && test_sta_flag(rx->sta, WLAN_STA_AUTHORIZED)) ) {
>
> There's no check for "if we are a station" here.
>
Yeah this doesn't make sense.
Also the check on !rx-sta seems superfluous since it's already checked a
few lines above.
Regards
Matthias
On Tue, 2016-01-05 at 10:47 +0100, Matthias May wrote:
>
> We've encountered exactly this problem in a mix of devices where one
> applies key material faster than the other. (ath9k and aquilla)
> As a workaround we check on the STA if we are authorized when
> updating/checking CCMP. (see attached patches)
>
Those don't really seem safe to use either.
johannes
On 05/01/16 10:58, Johannes Berg wrote:
> On Tue, 2016-01-05 at 10:47 +0100, Matthias May wrote:
>
>>
>> We've encountered exactly this problem in a mix of devices where one
>> applies key material faster than the other. (ath9k and aquilla)
>> As a workaround we check on the STA if we are authorized when
>> updating/checking CCMP. (see attached patches)
>>
>
> Those don't really seem safe to use either.
>
> johannes
>
Not safe as in "access to stuff which has to be locked", or not safe as
in "a CCMP replay attack is possible"?
When changing this we argumented that since we are not really connected
yet, a CCMP replay attack doesn't really make sense.
Matthias
On Thu, Jan 7, 2016 at 11:15 PM, Johannes Berg
<[email protected]> wrote:
>
> On Thu, 2015-12-31 at 10:41 +0200, Emmanuel Grumbach wrote:
> >
> > So essentially, this is a bug in the TX'ing side. Fixing it requires
> > to hit the performance which is not something people are willing to
> > do, when the bug is really in the spec.
> >
>
> I wonder if, for most devices, this is really true?
>
> We could, after all, remove the key from hardware acceleration before
> we replace it logically in software, avoiding the problem [1], like
> this:
>
> https://p.sipsolutions.net/a71aa559c27998c7.txt
> (completely untested!)
>
> This would slightly increase the window of time in which devices like
> ath10k that require hardware crypto drop the frame entirely, but that
> seems quite reasonable?
Yes - it looks reasonable. At least, worth being tested :)
>
>
> [1] assuming the driver doesn't return from the set_key() method while
> it still has frames that might have been decrypted with that key; which
> again is clearly true for iwlwifi due to the combined data/firmware
> command design, but maybe not fully guaranteed for ath9k
On Thu, 2015-12-31 at 10:41 +0200, Emmanuel Grumbach wrote:
>
> So essentially, this is a bug in the TX'ing side. Fixing it requires
> to hit the performance which is not something people are willing to
> do, when the bug is really in the spec.
>
I wonder if, for most devices, this is really true?
We could, after all, remove the key from hardware acceleration before
we replace it logically in software, avoiding the problem [1], like
this:
https://p.sipsolutions.net/a71aa559c27998c7.txt
(completely untested!)
This would slightly increase the window of time in which devices like
ath10k that require hardware crypto drop the frame entirely, but that
seems quite reasonable?
[1] assuming the driver doesn't return from the set_key() method while
it still has frames that might have been decrypted with that key; which
again is clearly true for iwlwifi due to the combined data/firmware
command design, but maybe not fully guaranteed for ath9k