1. 15 2月, 2013 2 次提交
  2. 03 1月, 2013 1 次提交
  3. 05 12月, 2012 1 次提交
  4. 27 11月, 2012 1 次提交
  5. 26 11月, 2012 2 次提交
    • J
      nl80211/cfg80211: support VHT channel configuration · 3d9d1d66
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      3d9d1d66
    • J
      cfg80211: pass a channel definition struct · 683b6d3b
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      683b6d3b
  6. 18 10月, 2012 2 次提交
  7. 20 8月, 2012 1 次提交
    • J
      cfg80211: add P2P Device abstraction · 98104fde
      Johannes Berg 提交于
      In order to support using a different MAC address
      for the P2P Device address we must first have a
      P2P Device abstraction that can be assigned a MAC
      address.
      
      This abstraction will also be useful to support
      offloading P2P operations to the device, e.g.
      periodic listen for discoverability.
      
      Currently, the driver is responsible for assigning
      a MAC address to the P2P Device, but this could be
      changed by allowing a MAC address to be given to
      the NEW_INTERFACE command.
      
      As it has no associated netdev, a P2P Device can
      only be identified by its wdev identifier but the
      previous patches allowed using the wdev identifier
      in various APIs, e.g. remain-on-channel.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      98104fde
  8. 13 7月, 2012 1 次提交
    • J
      cfg80211: reduce monitor interface tracking · 4290cb4b
      Johannes Berg 提交于
      Revert commit b78e8cea
      ("cfg80211: track monitor channel") and remove the
      set_monitor_enabled() callback.
      
      Due to the tracking happening in NETDEV_PRE_UP, it had
      introduced bugs because the monitor interface callback
      would be called before the device was started. It looks
      like there's no way to fix this, and using NETDEV_PRE_UP
      is broken anyway (since there's no NETDEV_UP_FAIL), so
      remove all that code, track interfaces in NETDEV_UP and
      also stop tracking the monitor channel in cfg80211.
      
      This mostly reverts to before the tracking, except that
      we keep the interface count tracking so that setting the
      monitor channel can be rejected properly.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4290cb4b
  9. 12 7月, 2012 2 次提交
  10. 29 6月, 2012 3 次提交
  11. 07 6月, 2012 1 次提交
  12. 06 6月, 2012 1 次提交
  13. 17 5月, 2012 1 次提交
  14. 07 12月, 2011 1 次提交
  15. 19 11月, 2010 1 次提交
  16. 17 11月, 2010 1 次提交
  17. 03 6月, 2010 1 次提交
  18. 22 5月, 2010 1 次提交
  19. 08 5月, 2010 1 次提交
    • J
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg 提交于
      Currently (all tested with hwsim) you can do stupid
      things like setting up an AP on a certain channel,
      then adding another virtual interface and making
      that associate on another channel -- this will make
      the beaconing to move channel but obviously without
      the necessary IEs data update.
      
      In order to improve this situation, first make the
      configuration APIs (cfg80211 and nl80211) aware of
      multi-channel operation -- we'll eventually need
      that in the future anyway. There's one userland API
      change and one API addition. The API change is that
      now SET_WIPHY must be called with virtual interface
      index rather than only wiphy index in order to take
      effect for that interface -- luckily all current
      users (hostapd) do that. For monitor interfaces, the
      old setting is preserved, but monitors are always
      slaved to other devices anyway so no guarantees.
      
      The second userland API change is the introduction
      of a per virtual interface SET_CHANNEL command, that
      hostapd should use going forward to make it easier
      to understand what's going on (it can automatically
      detect a kernel with this command).
      
      Other than mac80211, no existing cfg80211 drivers
      are affected by this change because they only allow
      a single virtual interface.
      
      mac80211, however, now needs to be aware that the
      channel settings are per interface now, and needs
      to disallow (for now) real multi-channel operation,
      which is another important part of this patch.
      
      One of the immediate benefits is that you can now
      start hostapd to operate on a hardware that already
      has a connection on another virtual interface, as
      long as you specify the same channel.
      
      Note that two things are left unhandled (this is an
      improvement -- not a complete fix):
      
       * different HT/no-HT modes
      
         currently you could start an HT AP and then
         connect to a non-HT network on the same channel
         which would configure the hardware for no HT;
         that can be fixed fairly easily
      
       * CSA
      
         An AP we're connected to on a virtual interface
         might indicate switching channels, and in that
         case we would follow it, regardless of how many
         other interfaces are operating; this requires
         more effort to fix but is pretty rare after all
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f444de05
  20. 29 12月, 2009 1 次提交
    • J
      cfg80211: add remain-on-channel command · 9588bbd5
      Jouni Malinen 提交于
      Add new commands for requesting the driver to remain awake
      on a specified channel for the specified amount of time
      (and another command to cancel such an operation). This
      can be used to implement userspace-controlled off-channel
      operations, like Public Action frame exchange on another
      channel than the operation channel.
      
      The off-channel operation should behave similarly to scan,
      i.e. the local station (if associated) moves into power
      save mode to request the AP to buffer frames for it and
      then moves to the other channel to allow the off-channel
      operation to be completed. The duration parameter can be
      used to request enough time to receive a response from
      the target station.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9588bbd5
  21. 14 8月, 2009 2 次提交