08 Jul, 2011

1 commit

  • Our current TKIP code races against itself on TX
    since we can process multiple packets at the same
    time on different ACs, but they all share the TX
    context for TKIP. This can lead to bad IVs etc.

    Also, the crypto offload helper code just obtains
    the P1K/P2K from the cache, and can update it as
    well, but there's no guarantee that packets are
    really processed in order.

    To fix these issues, first introduce a spinlock
    that will protect the IV16/IV32 values in the TX
    context. This first step makes sure that we don't
    assign the same IV multiple times or get confused
    in other ways.

    Secondly, change the way the P1K cache works. I
    add a field "p1k_iv32" that stores the value of
    the IV32 when the P1K was last recomputed, and
    if different from the last time, then a new P1K
    is recomputed. This can cause the P1K computation
    to flip back and forth if packets are processed
    out of order. All this also happens under the new
    spinlock.

    Finally, because there are argument differences,
    split up the ieee80211_get_tkip_key() API into
    ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
    and give them the correct arguments.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

05 Apr, 2011

1 commit

  • The only thing that using crypto_blkcipher with ecb does over just using
    arc4 directly is wrapping the encrypt/decrypt function into a for loop,
    looping over each individual character.
    To be able to do this, it pulls in around 40 kb worth of unnecessary
    kernel modules (at least on a MIPS embedded device).
    Using arc4 directly not only eliminates those dependencies, it also makes
    the code smaller.

    Signed-off-by: Felix Fietkau
    Signed-off-by: John W. Linville

    Felix Fietkau
     

09 Jul, 2010

1 commit

  • The current mac80211 code assumes that WEP is always available. If WEP
    fails to initialize, ieee80211_register_hw will always fail.

    In some cases (e.g. FIPS certification), the cryptography used by WEP is
    unavailable. However, in such cases there is no good reason why CCMP
    encryption (or even no link level encryption) cannot be used. So, this
    patch removes mac80211's assumption that WEP (and TKIP) will always be
    available for use.

    Signed-off-by: John W. Linville

    John W. Linville
     

15 Jun, 2008

1 commit


22 May, 2008

1 commit


08 May, 2008

1 commit


09 Apr, 2008

1 commit


26 Mar, 2008

1 commit

  • This patch makes mac80211 able to send a phase1 key for TKIP
    decryption.
    This is needed for drivers that don't do the rekeying by themselves
    (i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW,
    if decryption is ok, mac80211 calls to update_tkip_key with a new
    phase 1 RX key.

    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Tomas Winkler
    Signed-off-by: John W. Linville

    Emmanuel Grumbach
     

11 Oct, 2007

1 commit


06 May, 2007

1 commit