1. 19 Nov, 2014 1 commit
  2. 04 Nov, 2014 1 commit
    • Rostislav Lisovy's avatar
      cfg80211: 802.11p OCB mode handling · 6e0bd6c3
      Rostislav Lisovy authored
      This patch adds new iface type (NL80211_IFTYPE_OCB) representing
      the OCB (Outside the Context of a BSS) mode.
      When establishing a connection to the network a cfg80211_join_ocb
      function is called (particular nl80211_command is added as well).
      A mandatory parameters during the ocb_join operation are 'center
      frequency' and 'channel width (5/10 MHz)'.
      
      Changes done in mac80211 are minimal possible required to avoid
      many warnings (warning: enumeration value 'NL80211_IFTYPE_OCB'
      not handled in switch) during compilation. Full functionality
      (where needed) is added in the following patch.
      Signed-off-by: default avatarRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6e0bd6c3
  3. 31 Oct, 2014 1 commit
  4. 27 Oct, 2014 1 commit
  5. 11 Sep, 2014 1 commit
  6. 05 Sep, 2014 1 commit
  7. 26 Aug, 2014 1 commit
  8. 25 Aug, 2014 1 commit
  9. 23 Jun, 2014 1 commit
    • Johannes Berg's avatar
      cfg80211: make ethtool the driver's responsibility · b7ffbd7e
      Johannes Berg authored
      Currently, cfg80211 tries to implement ethtool, but that doesn't
      really scale well, with all the different operations. Make the
      lower-level driver responsible for it, which currently only has
      an effect on mac80211. It will similarly not scale well at that
      level though, since mac80211 also has many drivers.
      
      To cleanly implement this in mac80211, introduce a new file and
      move some code to appropriate places.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b7ffbd7e
  10. 26 May, 2014 1 commit
  11. 15 May, 2014 1 commit
  12. 09 May, 2014 1 commit
  13. 06 May, 2014 1 commit
  14. 29 Apr, 2014 1 commit
  15. 25 Apr, 2014 2 commits
  16. 09 Apr, 2014 2 commits
    • Luciano Coelho's avatar
      cfg80211/mac80211: move more combination checks to mac80211 · b6a55015
      Luciano Coelho authored
      Get rid of the cfg80211_can_add_interface() and
      cfg80211_can_change_interface() functions by moving that functionality
      to mac80211.  With this patch all interface combination checks are now
      out of cfg80211 (except for the channel switch case which will be
      addressed in a future commit).
      
      Additionally, modify the ieee80211_check_combinations() function so
      that an undefined chandef can be passed, in order to use it before a
      channel is defined.
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b6a55015
    • Johannes Berg's avatar
      cfg80211: allow userspace to take ownership of interfaces · 78f22b6a
      Johannes Berg authored
      When dynamically creating interfaces from userspace, e.g. for P2P usage,
      such interfaces are usually owned by the process that created them, i.e.
      wpa_supplicant. Should wpa_supplicant crash, such interfaces will often
      cease operating properly and cause problems on restarting the process.
      
      To avoid this problem, introduce an ownership concept for interfaces. If
      an interface is owned by a netlink socket, then it will be destroyed if
      the netlink socket is closed for any reason, including if the process it
      belongs to crashed. This gives us a race-free way to get rid of any such
      interfaces.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      78f22b6a
  17. 03 Mar, 2014 1 commit
  18. 25 Feb, 2014 1 commit
    • Ilan Peer's avatar
      cfg80211: send stop AP event only due to internal reason · 7c8d5e03
      Ilan Peer authored
      Commit "nl80211: send event when AP operation is stopped" added an
      event to notify user space that an AP interface has been stopped, to
      handle cases such as suspend etc. The event is sent regardless
      if the stop AP flow was triggered by user space or due to internal state
      change.
      
      This might cause issues with wpa_supplicant/hostapd flows that consider
      stop AP flow as a synchronous one, e.g., AP/GO channel change in the
      absence of CSA support. In such cases, the flow will restart the AP
      immediately after the stop AP flow is done, and only handle the stop
      AP event after the current flow is done, and as a result stop the AP
      again.
      
      Change the current implementation to only send the event in case the
      stop AP was triggered due to an internal reason.
      Signed-off-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7c8d5e03
  19. 06 Feb, 2014 3 commits
    • Johannes Berg's avatar
      cfg80211: send scan results from work queue · f9d15d16
      Johannes Berg authored
      Due to the previous commit, when a scan finishes, it is in theory
      possible to hit the following sequence:
       1. interface starts being removed
       2. scan is cancelled by driver and cfg80211 is notified
       3. scan done work is scheduled
       4. interface is removed completely, rdev->scan_req is freed,
          event sent to userspace but scan done work remains pending
       5. new scan is requested on another virtual interface
       6. scan done work runs, freeing the still-running scan
      
      To fix this situation, hang on to the scan done message and block
      new scans while that is the case, and only send the message from
      the work function, regardless of whether the scan_req is already
      freed from interface removal. This makes step 5 above impossible
      and changes step 6 to be
       5. scan done work runs, sending the scan done message
      
      As this can't work for wext, so we send the message immediately,
      but this shouldn't be an issue since we still return -EBUSY.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f9d15d16
    • Johannes Berg's avatar
      cfg80211: fix scan done race · a617302c
      Johannes Berg authored
      When an interface/wdev is removed, any ongoing scan should be
      cancelled by the driver. This will make it call cfg80211, which
      only queues a work struct. If interface/wdev removal is quick
      enough, this can leave the scan request pending and processed
      only after the interface is gone, causing a use-after-free.
      
      Fix this by making sure the scan request is not pending after
      the interface is destroyed. We can't flush or cancel the work
      item due to locking concerns, but when it'll run it shouldn't
      find anything to do. This leaves a potential issue, if a new
      scan gets requested before the work runs, it prematurely stops
      the running scan, potentially causing another crash. I'll fix
      that in the next patch.
      
      This was particularly observed with P2P_DEVICE wdevs, likely
      because freeing them is quicker than freeing netdevs.
      Reported-by: default avatarAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Fixes: 4a58e7c3 ("cfg80211: don't "leak" uncompleted scans")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a617302c
    • Johannes Berg's avatar
      cfg80211: re-enable 5/10 MHz support · 5a6aa705
      Johannes Berg authored
      Unfortunately I forgot this during the merge window, but the
      patch seems small enough to go in as a fix. The userspace API
      bug that was the reason for disabling it has long been fixed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5a6aa705
  20. 04 Feb, 2014 1 commit
  21. 05 Dec, 2013 2 commits
    • Eliad Peller's avatar
      cfg80211: don't "leak" uncompleted scans · 4a58e7c3
      Eliad Peller authored
      ___cfg80211_scan_done() can be called in some cases
      (e.g. on NETDEV_DOWN) before the low level driver
      notified scan completion (which is indicated by
      passing leak=true).
      
      Clearing rdev->scan_req in this case is buggy, as
      scan_done_wk might have already being queued/running
      (and can't be flushed as it takes rtnl()).
      
      If a new scan will be requested at this stage, the
      scan_done_wk will try freeing it (instead of the
      previous scan), and this will later result in
      a use after free.
      
      Simply remove the "leak" option, and replace it with
      a standard WARN_ON.
      
      An example backtrace after such crash:
      Unable to handle kernel paging request at virtual address fffffee5
      pgd = c0004000
      [fffffee5] *pgd=9fdf6821, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] SMP ARM
      PC is at cfg80211_scan_done+0x28/0xc4 [cfg80211]
      LR is at __ieee80211_scan_completed+0xe4/0x2dc [mac80211]
      [<bf0077b0>] (cfg80211_scan_done+0x28/0xc4 [cfg80211])
      [<bf0973d4>] (__ieee80211_scan_completed+0xe4/0x2dc [mac80211])
      [<bf0982cc>] (ieee80211_scan_work+0x94/0x4f0 [mac80211])
      [<c005fd10>] (process_one_work+0x1b0/0x4a8)
      [<c0060404>] (worker_thread+0x138/0x37c)
      [<c0066d70>] (kthread+0xa4/0xb0)
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4a58e7c3
    • Barak Bercovitz's avatar
      cfg80211: stop sched scan only when needed · 24d584d7
      Barak Bercovitz authored
      cfg80211_leave stops sched scan when any station vif
      is leaving. Add an explicit check and call it only
      when the relevant vif (the one we scan on) is leaving.
      Signed-off-by: default avatarBarak Bercovitz <barak@wizery.com>
      [Eliad - changed the commit message a bit]
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      [Johannes - add ASSERT_RTNL since that protects the pointer]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      24d584d7
  22. 02 Dec, 2013 1 commit
  23. 25 Nov, 2013 3 commits
    • Luis R. Rodriguez's avatar
      cfg80211: move regulatory flags to their own variable · a2f73b6c
      Luis R. Rodriguez authored
      We'll expand this later, this will make it easier to
      classify and review what things are related to regulatory
      or not.
      
      Coccinelle only missed 4 hits, which I had to do manually,
      supplying the SmPL in case of merge conflicts.
      
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags |= WIPHY_FLAG_CUSTOM_REGULATORY
      +wiphy->regulatory_flags |= REGULATORY_CUSTOM_REG
      @@
      expression e;
      @@
      -e->flags |= WIPHY_FLAG_CUSTOM_REGULATORY
      +e->regulatory_flags |= REGULATORY_CUSTOM_REG
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags &= ~WIPHY_FLAG_CUSTOM_REGULATORY
      +wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY
      +wiphy->regulatory_flags & REGULATORY_CUSTOM_REG
      
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY
      +wiphy->regulatory_flags |= REGULATORY_STRICT_REG
      @@
      expression e;
      @@
      -e->flags |= WIPHY_FLAG_STRICT_REGULATORY
      +e->regulatory_flags |= REGULATORY_STRICT_REG
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags &= ~WIPHY_FLAG_STRICT_REGULATORY
      +wiphy->regulatory_flags &= ~REGULATORY_STRICT_REG
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY
      +wiphy->regulatory_flags & REGULATORY_STRICT_REG
      
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags |= WIPHY_FLAG_DISABLE_BEACON_HINTS
      +wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS
      @@
      expression e;
      @@
      -e->flags |= WIPHY_FLAG_DISABLE_BEACON_HINTS
      +e->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags &= ~WIPHY_FLAG_DISABLE_BEACON_HINTS
      +wiphy->regulatory_flags &= ~REGULATORY_DISABLE_BEACON_HINTS
      @@
      struct wiphy *wiphy;
      @@
      -wiphy->flags & WIPHY_FLAG_DISABLE_BEACON_HINTS
      +wiphy->regulatory_flags & REGULATORY_DISABLE_BEACON_HINTS
      
      Generated-by: Coccinelle SmPL
      Cc: Julia Lawall <julia.lawall@lip6.fr>
      Cc: Peter Senna Tschudin <peter.senna@gmail.com>
      Cc: Mihir Shete <smihir@qti.qualcomm.com>
      Cc: Henri Bahini <hbahini@qca.qualcomm.com>
      Cc: Tushnim Bhattacharyya <tushnimb@qca.qualcomm.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@do-not-panic.com>
      [fix up whitespace damage, overly long lines]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a2f73b6c
    • Johannes Berg's avatar
      cfg80211: don't allow drivers to unset NL80211_FEATURE_SCAN_FLUSH · 00c3a6ed
      Johannes Berg authored
      As the flag is entirely implemented in cfg80211, it should
      have been a global feature flag (which I believe didn't
      exist at the time). However, there's no reason to allow
      drivers to unset the flag, so don't allow it and remove
      the validation of NL80211_SCAN_FLAG_FLUSH.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      00c3a6ed
    • Johannes Berg's avatar
      cfg80211: disable 5/10 MHz support for all drivers · 9f16d84a
      Johannes Berg authored
      Due to nl80211 API breakage, 5/10 MHz support is broken for
      all drivers. Fixing it requires adding new API, but that
      can't be done as a bugfix commit since that would require
      either updating all APIs in the trees needing the bugfix or
      cause different kernels to have incompatible API.
      
      Therefore, just disable 5/10 MHz support for all drivers.
      
      Cc: stable@vger.kernel.org [3.12]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9f16d84a
  24. 09 Oct, 2013 1 commit
  25. 26 Sep, 2013 1 commit
  26. 31 Jul, 2013 1 commit
  27. 16 Jul, 2013 1 commit
    • Amitkumar Karwar's avatar
      cfg80211/nl80211: Add packet coalesce support · be29b99a
      Amitkumar Karwar authored
      In most cases, host that receives IPv4 and IPv6 multicast/broadcast
      packets does not do anything with these packets. Therefore the
      reception of these unwanted packets causes unnecessary processing
      and power consumption.
      
      Packet coalesce feature helps to reduce number of received
      interrupts to host by buffering these packets in firmware/hardware
      for some predefined time. Received interrupt will be generated when
      one of the following events occur.
      a) Expiration of hardware timer whose expiration time is set to
      maximum coalescing delay of matching coalesce rule.
      b) Coalescing buffer in hardware reaches it's limit.
      c) Packet doesn't match any of the configured coalesce rules.
      
      This patch adds set/get configuration support for packet coalesce.
      User needs to configure following parameters for creating a coalesce
      rule.
      a) Maximum coalescing delay
      b) List of packet patterns which needs to be matched
      c) Condition for coalescence. pattern 'match' or 'no match'
      Multiple such rules can be created.
      
      This feature needs to be advertised during driver initialization.
      Drivers are supposed to do required firmware/hardware settings based
      on user configuration.
      Signed-off-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      [fix kernel-doc, change free function, fix copy/paste error]
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      be29b99a
  28. 24 Jun, 2013 1 commit
  29. 04 Jun, 2013 3 commits
    • Johannes Berg's avatar
      cfg80211: make wiphy index start at 0 again · 9b881963
      Johannes Berg authored
      The change to use atomic_inc_return() for assigning the wiphy
      index made the first wiphy index 1 instead of 0. This is fine,
      but we all habitually type "phy0" when we're testing, so make
      it go back to 0 instead of 1 by subtracting 1 from the index.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9b881963
    • Johannes Berg's avatar
      cfg80211: fix potential deadlock regression · 256c90de
      Johannes Berg authored
      My big locking cleanups caused a problem by registering the
      rfkill instance with the RTNL held, while the callback also
      acquires the RTNL. This potentially causes a deadlock since
      the two locks used (rfkill mutex and RTNL) can be acquired
      in two different orders. Fix this by (un)registering rfkill
      without holding the RTNL. This needs to be done after the
      device struct is registered, but that can also be done w/o
      holding the RTNL.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      256c90de
    • Johannes Berg's avatar
      cfg80211: separate internal SME implementation · ceca7b71
      Johannes Berg authored
      The current internal SME implementation in cfg80211 is
      very mixed up with the MLME handling, which has been
      causing issues for a long time. There are three things
      that the implementation has to provide:
       * a basic SME implementation for nl80211's connect()
         call (for drivers implementing auth/assoc, which is
         really just mac80211) and wireless extensions
       * MLME events for the userspace SME
       * SME events (connected, disconnected etc.) for all
         different SME implementation possibilities (driver,
         cfg80211 and userspace)
      
      To achieve these goals it isn't necessary to track the
      software SME's connection status outside of it's state
      (which is the part that caused many issues.) Instead,
      track it only in the SME data (wdev->conn) and in the
      general case only track whether the wdev is connected
      or not (via wdev->current_bss.)
      
      Also separate the internal implementation to not have
      callbacks from the SME events, but rather call it from
      the API functions that the driver (or rather mac80211)
      calls. This separates the code better.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ceca7b71
  30. 03 Jun, 2013 1 commit
  31. 28 May, 2013 1 commit