1. 06 Mar, 2013 6 commits
    • Johannes Berg's avatar
      nl80211: conditionally add back radar information · cdc89b97
      Johannes Berg authored
      
      
      If userspace is updated to deal with large split wiphy
      information dumps, add back the radar information that
      could otherwise push the data over the limit of the
      netlink dump messages.
      
      Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      cdc89b97
    • Johannes Berg's avatar
      nl80211: allow splitting wiphy information in dumps · 3713b4e3
      Johannes Berg authored
      
      
      The per-wiphy information is getting large, to the point
      where with more than the typical number of channels it's
      too large and overflows, and userspace can't get any of
      the information at all.
      
      To address this (in a way that doesn't require making all
      messages bigger) allow userspace to specify that it can
      deal with wiphy information split across multiple parts
      of the dump, and if it can split up the data. This also
      splits up each channel separately so an arbitrary number
      of channels can be supported.
      
      Additionally, since GET_WIPHY has the same problem, add
      support for filtering the wiphy dump and get information
      for a single wiphy only, this allows userspace apps to
      use dump in this case to retrieve all data from a single
      device.
      
      As userspace needs to know if all this this is supported,
      add a global nl80211 feature set and include a bit for
      this behaviour in it.
      
      Cc: Dennis H Jensen <dennis.h.jensen@siemens.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3713b4e3
    • Johannes Berg's avatar
      cfg80211: comprehensively check station changes · 77ee7c89
      Johannes Berg authored
      
      
      The station change API isn't being checked properly before
      drivers are called, and as a result it is difficult to see
      what should be allowed and what not.
      
      In order to comprehensively check the API parameters parse
      everything first, and then have the driver call a function
      (cfg80211_check_station_change()) with the additionally
      information about the kind of station that is being changed;
      this allows the function to make better decisions than the
      old code could.
      
      While at it, also add a few checks, particularly in mesh
      and clarify the TDLS station lifetime in documentation.
      
      To be able to reduce a few checks, ignore any flag set bits
      when the mask isn't set, they shouldn't be applied then.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      77ee7c89
    • Johannes Berg's avatar
      cfg80211: unify station WME parsing · ff276691
      Johannes Berg authored
      
      
      Instead of copying the code, create a new function
      to parse the station's WME information.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ff276691
    • Johannes Berg's avatar
      cfg80211: clean up station WME attribute parsing · 984c311b
      Johannes Berg authored
      
      
      Parse the attributes first, and then disable the apply
      flag if needed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      984c311b
    • Johannes Berg's avatar
      cfg80211: clean up mesh plink station change API · f8bacc21
      Johannes Berg authored
      
      
      Make the ability to leave the plink_state unchanged not use a
      magic -1 variable that isn't in the enum, but an explicit change
      flag; reject invalid plink states or actions and move the needed
      constants for plink actions to the right header file. Also
      reject plink_state changes for non-mesh interfaces.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f8bacc21
  2. 01 Mar, 2013 1 commit
    • Johannes Berg's avatar
      nl80211: increase wiphy dump size dynamically · 645e77de
      Johannes Berg authored
      
      
      Given a device with many channels capabilities the wiphy
      information can still overflow even though its size in
      3.9 was reduced to 3.8 levels. For new userspace and
      kernel 3.10 we're going to implement a new "split dump"
      protocol that can use multiple messages per wiphy.
      
      For now though, add a workaround to be able to send more
      information to userspace. Since generic netlink doesn't
      have a way to set the minimum dump size globally, and we
      wouldn't really want to set it globally anyway, increase
      the size only when needed, as described in the comments.
      As userspace might not be prepared for large buffers, we
      can only use 4k.
      
      Also increase the size for the get_wiphy command.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      645e77de
  3. 27 Feb, 2013 1 commit
  4. 25 Feb, 2013 2 commits
    • Johannes Berg's avatar
      nl80211: remove TCP WoWLAN information · 162589f7
      Johannes Berg authored
      
      
      Just like the radar information, the TCP WoWLAN capability
      data can increase the wiphy information and make it too
      big. Remove the TCP WoWLAN information; no driver supports
      it and new userspace tools will be required as well.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      162589f7
    • Johannes Berg's avatar
      nl80211: remove radar information · 1c33a059
      Johannes Berg authored
      
      
      The wiphy information is getting very close to being too
      much for a typical netlink dump message and adding the
      radar attributes to channels and interface combinations
      can push it over the limit, which means userspace gets no
      information whatsoever. Therefore, remove these again for
      now, no driver actually supports radar detection anyway
      and a modified userspace is required as well.
      
      We're working on a solution that will allow userspace to
      request splitting the information across multiple netlink
      messages, which will allow us to add this back.
      
      Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1c33a059
  5. 18 Feb, 2013 1 commit
  6. 15 Feb, 2013 5 commits
  7. 13 Feb, 2013 2 commits
  8. 11 Feb, 2013 1 commit
    • Johannes Berg's avatar
      cfg80211: move TSF into IEs · 8cef2c9d
      Johannes Berg authored
      
      
      While technically the TSF isn't an IE, it can be
      necessary to distinguish between the TSF from a
      beacon and a probe response, in particular in
      order to know the next DTIM TBTT, as not all APs
      are spec compliant wrt. TSF==0 being a DTIM TBTT
      and thus the DTIM count needs to be taken into
      account as well.
      
      To allow this, move the TSF into the IE struct
      so it can be known whence it came.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8cef2c9d
  9. 04 Feb, 2013 1 commit
    • Vladimir Kondratiev's avatar
      cfg80211: expand per-station byte counters to 64bit · 42745e03
      Vladimir Kondratiev authored
      
      
      In per-station statistics, present 32bit counters are too small
      for practical purposes - with gigabit speeds, it get overlapped
      every few seconds.
      
      Expand counters in the struct station_info to be 64-bit.
      Driver can still fill only 32-bit and indicate in @filled
      only bits like STATION_INFO_[TR]X_BYTES; in case driver provides
      full 64-bit counter, it should also set in @filled
      bit STATION_INFO_[TR]RX_BYTES64
      
      Netlink sends both 32-bit and 64-bit counters, if present, to not
      break userspace.
      Signed-off-by: default avatarVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      [change to also have 32-bit counters if driver advertises 64-bit]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      42745e03
  10. 31 Jan, 2013 1 commit
  11. 25 Jan, 2013 1 commit
  12. 16 Jan, 2013 6 commits
  13. 03 Jan, 2013 7 commits
  14. 30 Nov, 2012 1 commit
    • Johannes Berg's avatar
      cfg80211: fix BSS struct IE access races · 9caf0364
      Johannes Berg authored
      
      
      When a BSS struct is updated, the IEs are currently
      overwritten or freed. This can lead to races if some
      other CPU is accessing the BSS struct and using the
      IEs concurrently.
      
      Fix this by always allocating the IEs in a new struct
      that holds the data and length and protecting access
      to this new struct with RCU.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9caf0364
  15. 29 Nov, 2012 2 commits
  16. 28 Nov, 2012 1 commit
  17. 27 Nov, 2012 1 commit