06 Jul, 2011

1 commit

  • There was a deadlock when rfkill-blocking a wireless interface,
    because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop
    sched_scans that were eventually running. The rfkill block code was
    already holding a mutex under rdev:

    kernel: =======================================================
    kernel: [ INFO: possible circular locking dependency detected ]
    kernel: 3.0.0-rc1-00049-g1fa7b6a #57
    kernel: -------------------------------------------------------
    kernel: kworker/0:1/4525 is trying to acquire lock:
    kernel: (&rdev->mtx){+.+.+.}, at: [] cfg80211_netdev_notifier_call+0x131/0x5b0
    kernel:
    kernel: but task is already holding lock:
    kernel: (&rdev->devlist_mtx){+.+.+.}, at: [] cfg80211_rfkill_set_block+0x4f/0xa0
    kernel:
    kernel: which lock already depends on the new lock.

    To fix this, add a new mutex specifically for sched_scan, to protect
    the sched_scan_req element in the rdev struct, instead of using the
    global rdev mutex.

    Reported-by: Duane Griffin
    Signed-off-by: Luciano Coelho
    Signed-off-by: John W. Linville

    Luciano Coelho
     

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
     

08 Jun, 2011

1 commit

  • When one of the SSID's length passed in a scan or sched_scan request
    is larger than 255, there will be an overflow in the u8 that is used
    to store the length before checking. This causes the check to fail
    and we overrun the buffer when copying the SSID.

    Fix this by checking the nl80211 attribute length before copying it to
    the struct.

    This is a follow up for the previous commit
    208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem
    entirely.

    Reported-by: Ido Yariv
    Signed-off-by: Luciano Coelho
    Signed-off-by: John W. Linville

    Luciano Coelho
     

02 Jun, 2011

1 commit

  • Commit 0a35d36 ("cfg80211: Use capability info to detect mesh beacons")
    assumed that probe response with both ESS and IBSS bits cleared
    means that the frame was sent by a mesh sta.

    However, these capabilities are also being used in the p2p_find phase,
    and the mesh-validation broke it.

    Rename the WLAN_CAPABILITY_IS_MBSS macro, and verify that mesh ies
    exist before assuming this frame was sent by a mesh sta.

    Signed-off-by: Eliad Peller
    Signed-off-by: John W. Linville

    Eliad Peller
     

28 May, 2011

1 commit


27 May, 2011

1 commit

  • In both trigger_scan and sched_scan operations, we were checking for
    the SSID length before assigning the value correctly. Since the
    memory was just kzalloc'ed, the check was always failing and SSID with
    over 32 characters were allowed to go through.

    This was causing a buffer overflow when copying the actual SSID to the
    proper place.

    This bug has been there since 2.6.29-rc4.

    Cc: stable@kernel.org
    Signed-off-by: Luciano Coelho
    Signed-off-by: John W. Linville

    Luciano Coelho
     

25 May, 2011

1 commit


20 May, 2011

1 commit

  • Some stack variables (name *ssid and *channel) are only used to define
    the size of the memory block that needs to be allocated for the
    request structure in the nl80211_trigger_scan() and
    nl80211_start_sched_scan() functions.

    This is unnecessary because the sizes of the actual elements in the
    structure can be used instead.

    Signed-off-by: Luciano Coelho
    Signed-off-by: John W. Linville

    Luciano Coelho
     

19 May, 2011

1 commit

  • cfg80211 scan code adds separate BSS entries if the same BSS shows up
    on multiple channels. However, sme implementation does not use the
    frequency when fetching the BSS entry. Fix this by adding channel
    information to cfg80211_roamed() and include it in cfg80211_get_bss()
    calls.

    Please note that drivers using cfg80211_roamed() need to be modified to
    fully implement this fix. This commit includes only minimal changes to
    avoid compilation issues; it maintains the old (broken) behavior for
    most drivers. ath6kl was the only one that I could test, so I updated
    it to provide the operating frequency in the roamed event.

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

    Jouni Malinen
     

17 May, 2011

4 commits

  • …wireless-next-2.6 into for-davem

    Conflicts:
    drivers/net/wireless/iwlwifi/iwl-agn-tx.c
    net/mac80211/sta_info.h

    John W. Linville
     
  • Currently the devices that have already stripped IEEE 802.11
    header from the AMSDU SKB can not use ieee80211_amsdu_to_8023s
    routine. This patch enhances ieee80211_amsdu_to_8023s() API by
    changing mandatory removing of IEEE 802.11 header from AMSDU
    to optional.

    Signed-off-by: Yogesh Ashok Powar
    Signed-off-by: Bing Zhao
    Signed-off-by: John W. Linville

    Yogesh Ashok Powar
     
  • These definitions need to be exposed now that we can set the peer link
    states via NL80211_ATTR_STA_PLINK_STATE. They were already being
    (opaquely) reported by NL80211_STA_INFO_PLINK_STATE.

    Signed-off-by: Javier Cardona
    Signed-off-by: John W. Linville

    Javier Cardona
     
  • Add the ability to advertise interface combinations in nl80211.
    This allows the driver to indicate what the combinations are
    that it supports. "Combinations" of just a single interface are
    implicit, as previously. Note that cfg80211 will enforce that
    the restrictions are met, but not for all drivers yet (once all
    drivers are updated, we can remove the flag and enforce for all).

    When no combinations are actually supported, an empty list will
    be exported so that userspace can know if the kernel exported
    this info or not (although it isn't clear to me what tools using
    the info should do if the kernel didn't export it).

    Since some interface types are purely virtual/software and don't
    fit the restrictions, those are exposed in a new list of pure SW
    types, not subject to restrictions. This mainly exists to handle
    AP-VLAN and monitor interfaces in mac80211.

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

    Johannes Berg
     

13 May, 2011

2 commits

  • When sched_scan_stopped was called by the driver, mac80211 calls
    cfg80211, which in turn was calling mac80211 back with a flag
    "driver_initiated". This flag was used so that mac80211 would do the
    necessary cleanup but would not call the driver. This was enough to
    prevent the bounce back between the driver and mac80211, but not
    between mac80211 and cfg80211.

    To fix this, we now do the cleanup in mac80211 before calling
    cfg80211. To help with locking issues, the workqueue was moved from
    cfg80211 to mac80211.

    Reported-by: Johannes Berg
    Signed-off-by: Luciano Coelho
    Signed-off-by: John W. Linville

    Luciano Coelho
     
  • Multiple virtual AP interfaces can currently try
    to use different beacon intervals, but that just
    leads to problems since it won't actually be done
    that way by drivers. Return an error in this case
    to make sure it won't be done wrong.

    Also, ignore attempts to change the DTIM period
    or beacon interval during the lifetime of the BSS.

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

    Johannes Berg
     

12 May, 2011

9 commits


11 May, 2011

1 commit

  • These warnings are exposed by gcc 4.6.
    net/wireless/reg.c: In function 'freq_reg_info_regd':
    net/wireless/reg.c:675:38: warning: variable 'pr' set but not used
    [-Wunused-but-set-variable]
    net/wireless/lib80211_crypt_wep.c: In function 'lib80211_wep_build_iv':
    net/wireless/lib80211_crypt_wep.c:99:12: warning: variable 'len' set but
    not used [-Wunused-but-set-variable]

    Signed-off-by: Rajkumar Manoharan
    Signed-off-by: John W. Linville

    Rajkumar Manoharan
     

06 May, 2011

3 commits

  • This is based on (but now quite far from) the
    original work from Luis and Eliad. Add support
    for configuring WoWLAN triggers, and getting
    the configuration out again. Changes from the
    original patchset are too numerous to list,
    but one important change needs highlighting:
    the suspend() callback is passed NULL for the
    trigger configuration if userspace has not
    configured WoWLAN at all.

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

    Johannes Berg
     
  • Commit dbd2fd656f2060abfd3a16257f8b51ec60f6d2ed added a mechanism for
    user space to indicate whether a default key is being configured for
    only unicast or only multicast frames instead of all frames. This
    commit added a driver capability flag for indicating whether separate
    default keys are supported and validation of the set_key command based
    on that capability.

    However, this single capability flag is not enough to cover possible
    difference based on mode (AP/IBSS/STA) and the way this change was
    introduced resulted in a regression with drivers that do not indicate
    the new capability (i.e.., more or less any non-mac80211 driver using
    cfg80211) when using a recent wpa_supplicant snapshot.

    Fix the regression by removing the new check which is not strictly
    speaking needed. The new separate default key functionality is needed
    only for RSN IBSS which has a separate capability indication.

    Cc: stable@kernel.org
    Signed-off-by: Jouni Malinen
    Signed-off-by: John W. Linville

    Jouni Malinen
     
  • …wireless-next-2.6 into for-davem

    Conflicts:
    drivers/net/wireless/libertas/if_cs.c
    drivers/net/wireless/rtlwifi/pci.c
    net/bluetooth/l2cap_sock.c

    John W. Linville
     

27 Apr, 2011

1 commit

  • The patch "cfg80211: add a timer for invalid user reg hints"
    introduced a regression for the case where a secondary identical
    regulatory hint from a user is sent. What would happen is the
    second hint would schedule delayed work in to catch a timeout
    but since we are never processing it given that the hint was already
    applied we'd always hit the timeout and and restore regulatory
    settings back to world regulatory domain. This is fixed by simply
    avoiding sheduling work if the hint was already applied.

    Tested-by: Felix Fietkau
    Reported-by: Felix Fietkau
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     

26 Apr, 2011

2 commits


13 Apr, 2011

8 commits


08 Apr, 2011

1 commit