1. 06 3月, 2013 14 次提交
  2. 01 3月, 2013 1 次提交
    • J
      nl80211: increase wiphy dump size dynamically · 645e77de
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      645e77de
  3. 27 2月, 2013 1 次提交
  4. 26 2月, 2013 2 次提交
    • J
      nl80211: remove TCP WoWLAN information · 162589f7
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      162589f7
    • J
      nl80211: remove radar information · 1c33a059
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      1c33a059
  5. 19 2月, 2013 1 次提交
  6. 15 2月, 2013 5 次提交
  7. 13 2月, 2013 2 次提交
  8. 12 2月, 2013 1 次提交
    • J
      cfg80211: move TSF into IEs · 8cef2c9d
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      8cef2c9d
  9. 05 2月, 2013 1 次提交
    • V
      cfg80211: expand per-station byte counters to 64bit · 42745e03
      Vladimir Kondratiev 提交于
      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: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      [change to also have 32-bit counters if driver advertises 64-bit]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42745e03
  10. 31 1月, 2013 1 次提交
  11. 26 1月, 2013 1 次提交
  12. 17 1月, 2013 6 次提交
  13. 03 1月, 2013 4 次提交
    • J
      cfg80211: disallow more station changes · ba23d206
      Johannes Berg 提交于
      The following changes are invalid and should be
      disallowed when a station already exists:
       * supported rates changes, except for TDLS peers
       * listen interval changes
       * HT capability changes
      
      Disallow them and also update a mac80211 comment
      explaining how they would be racy.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ba23d206
    • J
      nl80211/mac80211: support full station state in AP mode · d582cffb
      Johannes Berg 提交于
      Today, stations are added already associated. That is
      inefficient if, for example, the driver has no room
      for stations any more because then the station will
      go through the entire auth/assoc handshake, only to
      be kicked out afterwards.
      
      To address this a bit better, at least with drivers
      using the new station state callback, allow hostapd
      to add stations in unauthenticated mode, just after
      receiving the AUTH frame, before even replying. Thus
      if there's no more space at that point, it can send
      a negative auth frame back. It still needs to handle
      later state transition errors though, of course.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d582cffb
    • J
      regulatory: use RCU to protect global and wiphy regdomains · 458f4f9e
      Johannes Berg 提交于
      To simplify the locking and not require cfg80211_mutex
      (which nl80211 uses to access the global regdomain) and
      also to make it possible for drivers to access their
      wiphy->regd safely, use RCU to protect these pointers.
      Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      458f4f9e
    • J
      regulatory: fix reg_is_valid_request handling · 6913b49a
      Johannes Berg 提交于
      There's a bug with the world regulatory domain, it
      can be updated any time which is different from all
      other regdomains that can only be updated once after
      a request for them. Fix this by adding a check for
      "processed" to the reg_is_valid_request() function
      and clear that when doing a request.
      
      While looking at this I also found another locking
      bug, last_request is protected by the reg_mutex not
      the cfg80211_mutex so the code in nl80211 is racy.
      Remove that code as it only tries to prevent an
      allocation in an error case, which isn't necessary.
      Then the function can also become static and locking
      in nl80211 can have a smaller scope.
      
      Also change __set_regdom() to do the checks earlier
      and not different for world/other regdomains.
      Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6913b49a