1. 30 Jun, 2016 1 commit
    • Arnd Bergmann's avatar
      nl80211: improve nl80211_parse_mesh_config type checking · f151d9db
      Arnd Bergmann authored
      
      
      When building a kernel with W=1, the nl80211.c file causes a number of
      warnings, all about the same problem:
      
      net/wireless/nl80211.c: In function 'nl80211_parse_mesh_config':
      net/wireless/nl80211.c:5287:103: error: comparison is always false due to limited range of data type [-Werror=type-limits]
      net/wireless/nl80211.c:5290:96: error: comparison is always false due to limited range of data type [-Werror=type-limits]
      net/wireless/nl80211.c:5293:124: error: comparison is always false due to limited range of data type [-Werror=type-limits]
      net/wireless/nl80211.c:5295:148: error: comparison is always false due to limited range of data type [-Werror=type-limits]
      net/wireless/nl80211.c:5298:106: error: comparison is always false due to limited range of data type [-Werror=type-limits]
      net/wireless/nl80211.c:5305:116: error: comparison is always false due to limited range of data type [-Werror=type-limits]
      
      The problem is that gcc does not notice that the check is generate
      by a macro, so it complains about comparing an unsigned type against 0.
      
      I've tried to come up with a way to rephrase that code in a way that
      avoids the warnings and otherwise improves the code as well.
      
      This uses a set of new helper functions that perform the range checking,
      and should provide slightly better type safety than the older patch,
      at the expense of adding 44 lines to the code. Binary code size is
      basically unchanged though (20 bytes added to 126561 bytes .text).
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      f151d9db
  2. 09 Jun, 2016 3 commits
  3. 31 May, 2016 3 commits
    • Kanchanapally, Vidyullatha's avatar
      cfg80211: Advertise extended capabilities per interface type to userspace · 019ae3a9
      Kanchanapally, Vidyullatha authored
      
      
      The driver extended capabilities may differ for different
      interface types which the userspace needs to know (for
      example the fine timing measurement initiator and responder
      bits might differ for a station and AP). Add a new nl80211
      attribute to provide extended capabilities per interface type
      to userspace.
      Signed-off-by: default avatarVidyullatha Kanchanapally <vkanchan@qti.qualcomm.com>
      Reviewed-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      019ae3a9
    • Jouni Malinen's avatar
      cfg80211: Allow cfg80211_connect_result() errors to be distinguished · bf1ecd21
      Jouni Malinen authored
      
      
      Previously, the status parameter to cfg80211_connect_result() was
      documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
      status code for the failure is not known. This value can be used by an
      AP (and often is) and as such, user space cannot distinguish between
      explicitly rejected authentication/association and not being able to
      even try to associate or not receiving a response from the AP.
      
      Add a new inline function, cfg80211_connect_timeout(), to be used when
      the driver knows that the connection attempt failed due to a reason
      where connection could not be attempt or no response was received from
      the AP. The internal functions now allow a negative status value (-1) to
      be used as an indication of this special case. This results in the
      NL80211_ATTR_TIMED_OUT to be added to the NL80211_CMD_CONNECT event to
      allow user space to determine this case was hit. For backwards
      compatibility, NL80211_STATUS_CODE with the value
      WLAN_STATUS_UNSPECIFIED_FAILURE is still indicated in the event in such
      a case.
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      [johannes: fix cfg80211_connect_bss() prototype to use int for status,
       add cfg80211_connect_timeout() to docbook, fix docbook]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      bf1ecd21
    • Martin Willi's avatar
      nl80211: Allow privileged operations from user namespaces · 5617c6cd
      Martin Willi authored
      While a wiphy can be transferred to network namespaces, a process having
      CAP_NET_ADMIN in a non-initial user namespace can not administrate such
      devices due to the genetlink GENL_ADMIN_PERM restrictions.
      
      For openvswitch having the same issue, a new GENL_UNS_ADMIN_PERM flag has
      been introduced, commit 4a92602a
      
       ("openvswitch: allow management from
      inside user namespaces"). This patch changes all privileged operations
      operating on a wiphy, dev or wdev to allow their administration using the
      same mechanism. All operations use either NEED_WIPHY, NEED_WDEV or
      NEED_NETDEV, which implies a namespace aware lookup of the device. The only
      exception is NL80211_CMD_SET_WIPHY, which explicitly uses a namespace aware
      phy lookup.
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      [also allow cancel scan, for completeness]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5617c6cd
  4. 12 May, 2016 1 commit
  5. 27 Apr, 2016 1 commit
  6. 26 Apr, 2016 1 commit
  7. 25 Apr, 2016 1 commit
  8. 12 Apr, 2016 2 commits
    • Johannes Berg's avatar
      cfg80211: remove enum ieee80211_band · 57fbcce3
      Johannes Berg authored
      
      
      This enum is already perfectly aliased to enum nl80211_band, and
      the only reason for it is that we get IEEE80211_NUM_BANDS out of
      it. There's no really good reason to not declare the number of
      bands in nl80211 though, so do that and remove the cfg80211 one.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      57fbcce3
    • Dmitry Ivanov's avatar
      nl80211: check netlink protocol in socket release notification · 8f815cdd
      Dmitry Ivanov authored
      A non-privileged user can create a netlink socket with the same port_id as
      used by an existing open nl80211 netlink socket (e.g. as used by a hostapd
      process) with a different protocol number.
      
      Closing this socket will then lead to the notification going to nl80211's
      socket release notification handler, and possibly cause an action such as
      removing a virtual interface.
      
      Fix this issue by checking that the netlink protocol is NETLINK_GENERIC.
      Since generic netlink has no notifier chain of its own, we can't fix the
      problem more generically.
      
      Fixes: 026331c4
      
       ("cfg80211/mac80211: allow registering for and sending action frames")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Ivanov <dima@ubnt.com>
      [rewrite commit message]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8f815cdd
  9. 06 Apr, 2016 2 commits
  10. 05 Apr, 2016 3 commits
  11. 24 Feb, 2016 2 commits
    • Beni Lev's avatar
      cfg80211: Add global RRM capability · 0c9ca11b
      Beni Lev authored
      
      
      Today, the supplicant will add the RRM capabilities
      Information Element in the association request only if
      Quiet period is supported (NL80211_FEATURE_QUIET).
      
      Quiet is one of many RRM features, and there are other RRM
      features that are not related to Quiet (e.g. neighbor
      report). Therefore, requiring Quiet to enable RRM is too
      restrictive.
      Some of the features, like neighbor report, can be
      supported by user space without any help from the kernel.
      Hence adding the RRM capabilities IE to association request
      should be the sole user space's decision.
      Removing the RRM dependency on Quiet in the driver solves
      this problem, but using an old driver with a user space
      tool that would not require Quiet feature would be
      problematic: the user space would add NL80211_ATTR_USE_RRM
      in the association request even if the kernel doesn't
      advertize NL80211_FEATURE_QUIET and the association would
      be denied by the kernel.
      
      This solution adds a global RRM capability, that tells user
      space that it can request RRM capabilities IE publishment
      without any specific feature support in the kernel.
      Signed-off-by: default avatarBeni Lev <beni.lev@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0c9ca11b
    • Lior David's avatar
      cfg80211: basic support for PBSS network type · 34d50519
      Lior David authored
      
      
      PBSS (Personal Basic Service Set) is a new BSS type for DMG
      networks. It is similar to infrastructure BSS, having an AP-like
      entity called PCP (PBSS Control Point), but it has few differences.
      PBSS support is mandatory for 11ad devices.
      
      Add support for PBSS by introducing a new PBSS flag attribute.
      The PBSS flag is used in the START_AP command to request starting
      a PCP instead of an AP, and in the CONNECT command to request
      connecting to a PCP instead of an AP.
      Signed-off-by: default avatarLior David <liord@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      34d50519
  12. 23 Feb, 2016 1 commit
  13. 15 Dec, 2015 2 commits
  14. 04 Dec, 2015 4 commits
  15. 03 Nov, 2015 2 commits
  16. 16 Oct, 2015 1 commit
  17. 13 Oct, 2015 2 commits
    • Avraham Stern's avatar
      cfg80211: Add multiple scan plans for scheduled scan · 3b06d277
      Avraham Stern authored
      
      
      Add the option to configure multiple 'scan plans' for scheduled scan.
      Each 'scan plan' defines the number of scan cycles and the interval
      between scans. The scan plans are executed in the order they were
      configured. The last scan plan will always run infinitely and thus
      defines only the interval between scans.
      The maximum number of scan plans supported by the device and the
      maximum number of iterations in a single scan plan are advertised
      to userspace so it can configure the scan plans appropriately.
      
      When scheduled scan results are received there is no way to know which
      scan plan is being currently executed, so there is no way to know when
      the next scan iteration will start. This is not a problem, however.
      The scan start timestamp is only used for flushing old scan results,
      and there is no difference between flushing all results received until
      the end of the previous iteration or the start of the current one,
      since no results will be received in between.
      Signed-off-by: default avatarAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3b06d277
    • Dmitry Shmidt's avatar
      nl80211: allow BSS data to include CLOCK_BOOTTIME timestamp · 6e19bc4b
      Dmitry Shmidt authored
      
      
      For location and connectivity services, userspace would often like
      to know the time when the BSS was last seen. The current "last seen"
      value is calculated in a way that makes it less useful, especially
      if the system suspended in the meantime.
      
      Add the ability for the driver to report a real CLOCK_BOOTTIME stamp
      that can then be reported to userspace (if present).
      
      Drivers wishing to use this must be converted to the new API to call
      cfg80211_inform_bss_data() or cfg80211_inform_bss_frame_data(). They
      need to ensure the reported value is accurate enough even when the
      frame might have been buffered in the device (e.g. firmware.)
      Signed-off-by: default avatarDmitry Shmidt <dimitrysh@google.com>
      [modified to use struct, inlines]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6e19bc4b
  18. 29 Sep, 2015 1 commit
  19. 22 Sep, 2015 2 commits
  20. 14 Aug, 2015 2 commits
  21. 17 Jul, 2015 1 commit
  22. 06 May, 2015 1 commit
  23. 24 Apr, 2015 1 commit