Le Fri, 15 May 2020 11:02:46 +0200,
Stefan Sperling a écrit :
> On Fri, May 08, 2020 at 10:53:30AM +0200, Stefan Sperling wrote:
> > So the diff below contains just the reordering fix for drivers using
> > hardware acceleration for WPA.
>
> Is there anybody who wants to OK this?
>
> To recap:
On Fri, May 08, 2020 at 10:53:30AM +0200, Stefan Sperling wrote:
> So the diff below contains just the reordering fix for drivers using
> hardware acceleration for WPA.
Is there anybody who wants to OK this?
To recap:
Currently, CCMP replay checking is skipped for aggregated 11n frames on
driver
On Fri, May 01, 2020 at 06:05:47PM +0200, Stefan Sperling wrote:
> The following diff moves the Packet Number check out of affected drivers
> into ieee80211_inputm() so the check can be performed after frames have
> been re-ordered.
Here is a new version of this diff.
I realized I made a mistake
On Fri, May 01, 2020 at 08:06:05PM +, Kevin Chadwick wrote:
> On 2020-05-01 16:05, Stefan Sperling wrote:
> > The CCMP header contains a nonce,
> > which is incremented by the transmitter whenever it encrypts a new frame.
>
> I assume there isn't opportunity to set the nonce to a 128 bit rand
On 2020-05-01 16:05, Stefan Sperling wrote:
> The CCMP header contains a nonce,
> which is incremented by the transmitter whenever it encrypts a new frame.
I assume there isn't opportunity to set the nonce to a 128 bit random one. It
would avoid a lot of risk with the likelihood of collisions bei
This diff needs testing in particular on: athn(4), iwn(4), wpi(4)
I have tested on iwn(4) and athn(4) so far.
Testing with other drivers would be good, too, to ensure that no
regressions are introduced for the software crypto case.
Drivers which offload CCMP decryption to hardware contain a check
