1. 06 Mar, 2013 2 commits
  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 2 commits
  18. 26 Nov, 2012 3 commits
    • Johannes Berg's avatar
      nl80211/cfg80211: add VHT MCS support · db9c64cf
      Johannes Berg authored
      Add support for reporting and calculating VHT MCSes.
      
      Note that I'm not completely sure that the bitrate
      calculations are correct, nor that they can't be
      simplified.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      db9c64cf
    • Johannes Berg's avatar
      nl80211/cfg80211: support VHT channel configuration · 3d9d1d66
      Johannes Berg authored
      Change nl80211 to support specifying a VHT (or HT)
      using the control channel frequency (as before) and
      new attributes for the channel width and first and
      second center frequency. The old channel type is of
      course still supported for HT.
      
      Also change the cfg80211 channel definition struct
      to support these by adding the relevant fields to
      it (and removing the _type field.)
      
      This also adds new helper functions:
       - cfg80211_chandef_create to create a channel def
         struct given the control channel and channel type,
       - cfg80211_chandef_identical to check if two channel
         definitions are identical
       - cfg80211_chandef_compatible to check if the given
         channel definitions are compatible, and return the
         wider of the two
      
      This isn't entirely complete, but that doesn't matter
      until we have a driver using it. In particular, it's
      missing
       - regulatory checks on the usable bandwidth (if that
         even makes sense)
       - regulatory TX power (database can't deal with it)
       - a proper channel compatibility calculation for the
         new channel types
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3d9d1d66
    • Johannes Berg's avatar
      cfg80211: pass a channel definition struct · 683b6d3b
      Johannes Berg authored
      Instead of passing a channel pointer and channel type
      to all functions and driver methods, pass a new channel
      definition struct. Right now, this struct contains just
      the control channel and channel type, but for VHT this
      will change.
      
      Also, add a small inline cfg80211_get_chandef_type() so
      that drivers don't need to use the _type field of the
      new structure all the time, which will change.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      683b6d3b