12 Jan, 2012

1 commit

  • Since:

    commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
    Author: Christian Lamparter
    Date: Sat Apr 30 15:24:30 2011 +0200

    mac80211: consolidate MIC failure report handling

    is possible to that we dereference rx->key == NULL when driver set
    RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
    promiscuous mode. This happen with rt73usb and rt61pci at least.

    Before the commit we always check rx->key against NULL, so I assume
    fix should be done in mac80211 (also mic_fail path has similar check).

    References:
    https://bugzilla.redhat.com/show_bug.cgi?id=769766
    http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html

    Cc: stable@vger.kernel.org # 3.0+
    Reported-by: Stuart D Gathman
    Reported-by: Kai Wohlfahrt
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: John W. Linville

    Stanislaw Gruszka
     

22 Nov, 2011

1 commit

  • We are currently linking the skbs by using skb->next
    directly. This works, but the preferred way is to use
    a struct sk_buff_head instead. That also prepares for
    passing that to drivers directly.

    While at it I noticed we calculate the duration for
    fragments twice -- remove one of them.

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

    Johannes Berg
     

12 Nov, 2011

1 commit


09 Nov, 2011

1 commit


12 Oct, 2011

1 commit

  • The purpose of this is two-fold:
    1) by moving it out of tx_data.flags, we can in
    another patch move the radiotap parsing so it
    no longer is in the hotpath
    2) if a device implements fragmentation but can
    optionally skip it, the radiotap request for
    not doing fragmentation may be honoured

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

    Johannes Berg
     

08 Jul, 2011

5 commits

  • The current rx->queue value is slightly confusing.
    It is set to 16 on non-QoS frames, including data,
    and then used for sequence number and PN/IV checks.
    Until recently, we had a TKIP IV checking bug that
    had been introduced in 2008 to fix a seqno issue.
    Before that, we always used TID 0 for checking the
    PN or IV on non-QoS packets.

    Go back to the old status for PN/IV checks using
    the TID 0 counter for non-QoS by splitting up the
    rx->queue value into "seqno_idx" and "security_idx"
    in order to avoid confusion in the future. They
    each have special rules on the value used for non-
    QoS data frames.

    Since the handling is now unified, also revert the
    special TKIP handling from my patch
    "mac80211: fix TKIP replay vulnerability".

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

    Johannes Berg
     
  • mac80211 has a defnition of AES_BLOCK_SIZE and
    multiple definitions of AES_BLOCK_LEN. Remove
    them all and use crypto/aes.h.

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

    Johannes Berg
     
  • Just like TKIP and CCMP, CMAC has the PN race.
    It might not actually be possible to hit it now
    since there aren't multiple ACs for management
    frames, but fix it anyway.

    Also move scratch buffers onto the stack.

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

    Johannes Berg
     
  • Since we can process multiple packets at the
    same time for different ACs, but the PN is
    allocated from a single counter, we need to
    use an atomic value there. Use atomic64_t to
    make this cheaper on 64-bit platforms, other
    platforms will support this through software
    emulation, see lib/atomic64.c.

    We also need to use an on-stack scratch buf
    so that multiple packets won't corrupt each
    others scratch buffers.

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

    Johannes Berg
     
  • 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
     

28 Jun, 2011

1 commit

  • Sometimes when reporting a MIC failure rx->key may be unset. This
    code path is hit when receiving a packet meant for a multicast
    address, and decryption is performed in HW.

    Fortunately, the failing key_idx is not used for anything up to
    (and including) usermode, so we allow ourselves to drop it on the
    way up when a key cannot be retrieved.

    Signed-off-by: Arik Nemtsov
    Cc: stable@kernel.org
    Signed-off-by: John W. Linville

    Arik Nemtsov
     

03 May, 2011

1 commit

  • Currently, mac80211 handles MIC failures differently
    depending on whenever they are detected by the stack's
    own software crypto or when are handed down from the
    driver.

    This patch tries to unify both by moving the special
    branch out of mac80211 rx hotpath and into into the
    software crypto part. This has the advantage that we
    can run a few more sanity checks on the data and verify
    if the key type was TKIP. This is very handy because
    several devices generate false postive MIC failure
    reports. Like carl9170, ath9k and wl12xx:

    "mac80211: report MIC failure for truncated packets in AP mode"

    Cc: Luciano Coelho
    Cc: Arik Nemtsov
    Signed-off-by: Christian Lamparter
    Signed-off-by: John W. Linville

    Christian Lamparter
     

04 Feb, 2011

2 commits

  • TKIP countermeasures depend on devices being able to detect Michael
    MIC failures on received frames and for stations to report errors to
    the AP. In order to test that behavior, it is useful to be able to
    send out TKIP frames with incorrect Michael MIC. This testing behavior
    has minimal effect on the TX path, so it can be added to mac80211 for
    convenient use.

    The interface for using this functionality is a file in mac80211
    netdev debugfs (tkip_mic_test). Writing a MAC address to the file
    makes mac80211 generate a dummy data frame that will be sent out using
    invalid Michael MIC value. In AP mode, the address needs to be for one
    of the associated stations or ff:ff:ff:ff:ff:ff to use a broadcast
    frame. In station mode, the address can be anything, e.g., the current
    BSSID. It should be noted that this functionality works correctly only
    when associated and using TKIP.

    Signed-off-by: Jouni Malinen
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville

    Jouni Malinen
     
  • The TKIP implementation was originally prepared to be a bit more
    flexible in the way Michael MIC TX/RX keys are configured. However, we
    are now taking care of the TX/RX MIC key swapping in user space, so
    this code will not be needed. Similarly, there were some remaining WPA
    testing code that won't be used in their current form. Remove the
    unneeded extra complexity.

    Signed-off-by: Jouni Malinen
    Reviewed-by: Johannes Berg
    Signed-off-by: John W. Linville

    Jouni Malinen
     

28 Sep, 2010

1 commit

  • commit 8c0c709eea5cbab97fb464cd68b06f24acc58ee1
    Author: Johannes Berg
    Date: Wed Nov 25 17:46:15 2009 +0100

    mac80211: move cmntr flag out of rx flags

    moved the CMNTR flag into the skb RX flags for
    some aggregation cleanups, but this was wrong
    since the optimisation this flag tried to make
    requires that it is kept across the processing
    of multiple interfaces -- which isn't true for
    flags in the skb. The patch not only broke the
    optimisation, it also introduced a bug: under
    some (common!) circumstances the flag will be
    set on an already freed skb!

    However, investigating this in more detail, I
    found that most of the flags that we set should
    be per packet, _except_ for this one, due to
    a-MPDU processing. Additionally, the flags used
    for processing (currently just this one) need
    to be reset before processing a new packet.

    Since we haven't actually seen bugs reported as
    a result of the wrong flags handling (which is
    not too surprising -- the only real bug case I
    can come up with is an a-MSDU contained in an
    a-MPDU), I'll make a different fix for rc.

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

    Johannes Berg
     

17 Aug, 2010

2 commits

  • The decryption code verifies whether or not
    a given frame was decrypted and verified by
    hardware. This is unnecessary, as the crypto
    RX handler already does it long before the
    decryption code is even invoked, so remove
    that code to avoid confusion.

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

    Johannes Berg
     
  • Currently, mac80211 translates the cfg80211
    cipher suite selectors into ALG_* values.
    That isn't all too useful, and some drivers
    benefit from the distinction between WEP40
    and WEP104 as well. Therefore, convert it
    all to use the cipher suite selectors.

    Signed-off-by: Johannes Berg
    Acked-by: Gertjan van Wingerde
    Signed-off-by: John W. Linville

    Johannes Berg
     

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
     

16 Jun, 2010

1 commit

  • When management frame protection (IEEE 802.11w) is used, we must use a
    separate counter for tracking received CCMP packet number for the
    management frames. The previously used NUM_RX_DATA_QUEUESth queue was
    shared with data frames when QoS was not used and that can cause
    problems in detecting replays incorrectly for robust management frames.
    Add a new counter just for robust management frames to avoid this issue.

    Signed-off-by: Jouni Malinen
    Signed-off-by: John W. Linville

    Jouni Malinen
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

20 Jan, 2010

1 commit

  • When mac80211 asks a driver to encrypt a frame, it
    must assign the control.hw_key pointer for it to
    know which key to use etc. Currently, mac80211 does
    this whenever it would software-encrypt a frame.

    Change the logic of this code to assign the hw_key
    pointer when selecting the key, and later check it
    when deciding whether to encrypt the frame or let
    it be encrypted by the hardware. This allows us to
    later simply skip the encryption function since it
    no longer modifies the TX control.

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

    Johannes Berg
     

19 Nov, 2009

1 commit

  • The RX data contains the netdev, which is
    duplicated since we have the sdata, and the
    RX status pointer, which is duplicate since
    we have the skb. Remove those two fields to
    have fewer fields that depend on each other
    and simply load them as necessary.

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

    Johannes Berg
     

11 Jul, 2009

1 commit

  • Instead of hardcoding GFP_ATOMIC everywhere, add a
    new function parameter that gets the flags from the
    caller. Obviously then I need to update all callers
    (all of them in mac80211), and it turns out that now
    it's ok to use GFP_KERNEL in almost all places.

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

    Johannes Berg
     

23 Apr, 2009

1 commit

  • Define a new nl80211 event, NL80211_CMD_MICHAEL_MIC_FAILURE, to be
    used to notify user space about locally detected Michael MIC failures.
    This matches with the MLME-MICHAELMICFAILURE.indication() primitive.

    Since we do not actually have TSC in the skb anymore when
    mac80211_ev_michael_mic_failure() is called, that function is changed
    to take in the TSC as an optional parameter instead of as a
    requirement to include the TSC after the hdr field (which we did not
    really follow). For now, TSC is not included in the events from
    mac80211, but it could be added at some point.

    Signed-off-by: Jouni Malinen
    Signed-off-by: John W. Linville

    Jouni Malinen
     

28 Mar, 2009

1 commit

  • Fragmentation currently uses an allocated array to store the
    fragment skbs, and then keeps track of which have been sent
    and which are still pending etc. This is rather complicated;
    make it simpler by just chaining the fragments into skb->next
    and removing from that list when sent. Also simplifies all
    code that needs to touch fragments, since it now only needs
    to walk the skb->next list.

    This is a prerequisite for fixing the stored packet code,
    which I need to do for proper aggregation packet storing.

    Signed-off-by: Johannes Berg
    Reviewed-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Johannes Berg
     

30 Jan, 2009

3 commits

  • If driver/firmware/hardware does not support CCMP for management
    frames, it can now request mac80211 to take care of encrypting and
    decrypting management frames (when MFP is enabled) in software. The
    will need to add this new IEEE80211_KEY_FLAG_SW_MGMT flag when a CCMP
    key is being configured for TX side and return the undecrypted frames
    on RX side without RX_FLAG_DECRYPTED flag to use software CCMP for
    management frames (but hardware for data frames).

    Signed-off-by: Jouni Malinen
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville

    Jouni Malinen
     
  • Implement Broadcast/Multicast Integrity Protocol for management frame
    protection. This patch adds the needed definitions for the new
    information element (MMIE) and implementation for the new "encryption"
    type (though, BIP is actually not encrypting data, it provides only
    integrity protection). These routines will be used by a follow-on patch
    that enables BIP for multicast/broadcast robust management frames.

    Signed-off-by: Jouni Malinen
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville

    Jouni Malinen
     
  • Extend CCMP to support encryption and decryption of unicast management
    frames.

    Signed-off-by: Jouni Malinen
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville

    Jouni Malinen
     

01 Nov, 2008

1 commit


28 Oct, 2008

1 commit


07 Oct, 2008

1 commit


16 Sep, 2008

1 commit

  • This patch changes mac80211 to share some more data about
    stations with drivers. Should help iwlwifi and ath9k when
    they get around to updating, and might also help with
    implementing rate control algorithms without internals.

    Signed-off-by: Johannes Berg
    Cc: Sujith Manoharan
    Signed-off-by: John W. Linville

    Johannes Berg
     

23 Aug, 2008

1 commit

  • This patch replaces net_device arguments to mac80211 internal functions
    with ieee80211_{local,sub_if_data} as appropriate.

    It also does the same for many 802.11s mesh functions, and changes the
    mesh path table to be indexed on sub_if_data rather than net_device.

    If the mesh part needs to be a separate patch let me know, but since
    mesh uses a lot of mac80211 functions which were being converted anyway,
    the changes go hand-in-hand somewhat.

    This patch probably does not convert all the functions which could be
    converted, but it is a large chunk and followup patches will be
    provided.

    Signed-off-by: Jasper Bryant-Greene
    Signed-off-by: John W. Linville

    Jasper Bryant-Greene
     

09 Jul, 2008

5 commits


03 Jul, 2008

1 commit

  • This patch reworks the mac80211 debug settings making them more focused
    and adding help text for those that didn't have one. It also removes a
    number of printks that can be triggered remotely and add no value, e.g.
    "too short deauthentication frame received - ignoring".

    If somebody really needs to debug that they should just add a monitor
    interface and look at the frames in wireshark.

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

    Johannes Berg
     

27 Jun, 2008

1 commit