All of lore.kernel.org
 help / color / mirror / Atom feed
From: gregor kowski <gregor.kowski@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mac80211 : fix a race with update_tkip_key
Date: Mon, 8 Jun 2009 19:51:32 +0200	[thread overview]
Message-ID: <83a869cd0906081051h2e82bba2q731be9f84bc1846a@mail.gmail.com> (raw)
In-Reply-To: <1244442549.11006.2.camel@johannes.local>

On Mon, Jun 8, 2009 at 8:29 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Sun, 2009-06-07 at 21:49 +0000, gregor kowski wrote:
>> The mac80211 tkip code won't call update_tkip_key, if some rx packets
>> get received without KEY_FLAG_UPLOADED_TO_HARDWARE. This can happen on
>> first packet because the hardware key stuff is called asynchronously
>> with
>> todo workqueue.
>>
>> This patch workaround that by always calling update_tkip_key if
>> the packet wasn't decrypted by the hardware.
>>
>> Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
>> Index: linux-2.6/net/mac80211/tkip.c
>> ===================================================================
>> --- linux-2.6.orig/net/mac80211/tkip.c  2009-06-07 19:32:26.000000000
>> +0000
>> +++ linux-2.6/net/mac80211/tkip.c       2009-06-07 21:31:31.000000000
>> +0000
>> @@ -298,19 +298,19 @@
>>                         printk("\n");
>>                 }
>>  #endif
>> -               if (key->local->ops->update_tkip_key &&
>> -                       key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
>> -                       u8 bcast[ETH_ALEN] =
>> -                               {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
>> -                       u8 *sta_addr = key->sta->sta.addr;
>> +       }
>> +       if (key->local->ops->update_tkip_key &&
>> +               key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
>> +               u8 bcast[ETH_ALEN] =
>> +                       {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
>> +               u8 *sta_addr = key->sta->sta.addr;
>
> There's a quite obvious disconnect between what your patch does and what
> your description says, please fix one of them. As it is, the patch only
> skips the IV rollover which is *completely* wrong because it will call
> the function for *every* packet.
I don't understand what you mean : the callback will be called for
every packet the hardware doesn't decrypted. If the hardware decrypt
the packet, only_iv is set and we don't go here.


Gregor

  reply	other threads:[~2009-06-08 17:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <83a869cd0906071445i13a5398y5e94ea3d91123c3b@mail.gmail.com>
2009-06-07 21:49 ` [PATCH] mac80211 : fix a race with update_tkip_key gregor kowski
2009-06-08  6:29   ` Johannes Berg
2009-06-08 17:51     ` gregor kowski [this message]
2009-06-09 14:02       ` Johannes Berg
2009-06-09 17:48         ` gregor kowski
2009-06-09 17:52           ` Johannes Berg
2009-06-10 19:42             ` gregor kowski
2009-06-10 22:17               ` gregor kowski
2009-06-11 20:11                 ` Johannes Berg
2009-06-11 20:07               ` Johannes Berg
2009-06-12 20:41                 ` gregor kowski
2009-06-12 20:47                   ` Johannes Berg
2009-06-19 19:33                     ` gregor kowski
2009-06-19 19:37                       ` gregor kowski
2009-06-21  9:21                         ` Johannes Berg
2009-06-22 20:48                           ` gregor kowski
2009-08-21 22:13 gregor kowski
2009-08-22  7:45 ` Johannes Berg
2009-11-07 18:10   ` gregor kowski
2009-11-07 19:22     ` Johannes Berg
2009-11-16 21:53       ` gregor kowski
2009-11-16 21:56         ` Johannes Berg
2009-12-07 21:05           ` gregor kowski
2009-12-07 21:06           ` gregor kowski
2009-12-09 22:21             ` gregor kowski
2009-12-09 22:25               ` gregor kowski
2009-12-28 16:46                 ` gregor kowski
2009-12-28 17:23                   ` John W. Linville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a869cd0906081051h2e82bba2q731be9f84bc1846a@mail.gmail.com \
    --to=gregor.kowski@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.