1. 13 4月, 2011 2 次提交
  2. 08 4月, 2011 1 次提交
  3. 02 3月, 2011 1 次提交
  4. 11 1月, 2011 1 次提交
  5. 21 12月, 2010 3 次提交
  6. 17 12月, 2010 1 次提交
    • J
      nl80211: Add notification for dropped Deauth/Disassoc · cf4e594e
      Jouni Malinen 提交于
      Add a new notification to indicate that a received, unprotected
      Deauthentication or Disassociation frame was dropped due to
      management frame protection being in use. This notification is
      needed to allow user space (e.g., wpa_supplicant) to implement
      SA Query procedure to recover from association state mismatch
      between an AP and STA.
      
      This is needed to avoid getting stuck in non-working state when MFP
      (IEEE 802.11w) is used and a protected Deauthentication or
      Disassociation frame is dropped for any reason. After that, the
      station would silently discard any unprotected Deauthentication or
      Disassociation frame that could be indicating that the AP does not
      have association for the STA (when the Reason Code would be 6 or 7).
      IEEE Std 802.11w-2009, 11.13 describes this recovery mechanism.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cf4e594e
  7. 16 12月, 2010 1 次提交
  8. 14 12月, 2010 1 次提交
  9. 09 12月, 2010 1 次提交
  10. 08 12月, 2010 1 次提交
  11. 07 12月, 2010 2 次提交
  12. 30 11月, 2010 1 次提交
  13. 25 11月, 2010 2 次提交
  14. 19 11月, 2010 1 次提交
  15. 17 11月, 2010 2 次提交
    • F
    • B
      cfg80211: Add nl80211 antenna configuration · afe0cbf8
      Bruno Randolf 提交于
      Allow setting of TX and RX antennas configuration via nl80211.
      
      The antenna configuration is defined as a bitmap of allowed antennas to use.
      This API can be used to mask out antennas which are not attached or should not
      be used for other reasons like regulatory concerns or special setups.
      
      Separate bitmaps are used for RX and TX to allow configuring different antennas
      for receiving and transmitting. Each bitmap is 32 bit long, each bit
      representing one antenna, starting with antenna 1 at the first bit. If an
      antenna bit is set, this means the driver is allowed to use this antenna for RX
      or TX respectively; if the bit is not set the hardware is not allowed to use
      this antenna.
      
      Using bitmaps has the benefit of allowing for a flexible configuration
      interface which can support many different configurations and which can be used
      for 802.11n as well as non-802.11n devices. Instead of relying on some hardware
      specific assumptions, drivers can use this information to know which antennas
      are actually attached to the system and derive their capabilities based on
      that.
      
      802.11n devices should enable or disable chains, based on which antennas are
      present (If all antennas belonging to a particular chain are disabled, the
      entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
      Antenna selection) should be calculated based on the available chains after
      applying the antenna masks. Should a 802.11n device have diversity antennas
      attached to one of their chains, diversity can be enabled or disabled based on
      the antenna information.
      
      Non-802.11n drivers can use the antenna masks to select RX and TX antennas and
      to enable or disable antenna diversity.
      
      While covering chainmasks for 802.11n and the standard "legacy" modes "fixed
      antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare,
      but useful configurations as follows:
      
      1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
      have a low gain antenna for TX in order to keep within the regulatory
      constraints and a high gain antenna for RX in order to receive weaker signals
      ("speak softly, but listen harder"). This can be useful for building long-shot
      outdoor links. Another usage of this setup is having a low-noise pre-amplifier
      on antenna 1 and a power amplifier on the other antenna. This way transmit
      noise is mostly kept out of the low noise receive channel.
      (This would be bitmaps: tx 1 rx 2).
      
      2) Another similar setup is: Use RX diversity on both antennas, but always send
      on antenna 1. Again that would allow us to benefit from a higher gain RX
      antenna, while staying within the legal limits.
      (This would be: tx 0 rx 3).
      
      3) And finally there can be special experimental setups in research and
      development even with pre 802.11n hardware where more than 2 antennas are
      available. It's good to keep the API simple, yet flexible.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      
      --
      v7:	Made bitmasks 32 bit wide and rebased to latest wireless-testing.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afe0cbf8
  16. 16 11月, 2010 1 次提交
    • L
      cfg80211: fix disabling channels based on hints · ca4ffe8f
      Luis R. Rodriguez 提交于
      After a module loads you will have loaded the world roaming regulatory
      domain or a custom regulatory domain. Further regulatory hints are
      welcomed and should be respected unless the regulatory hint is coming
      from a country IE as the IEEE spec allows for a country IE to be a subset
      of what is allowed by the local regulatory agencies.
      
      So disable all channels that do not fit a regulatory domain sent
      from a unless the hint is from a country IE and the country IE had
      no information about the band we are currently processing.
      
      This fixes a few regulatory issues, for example for drivers that depend
      on CRDA and had no 5 GHz freqencies allowed were not properly disabling
      5 GHz at all, furthermore it also allows users to restrict devices
      further as was intended.
      
      If you recieve a country IE upon association we will also disable the
      channels that are not allowed if the country IE had at least one
      channel on the respective band we are procesing.
      
      This was the original intention behind this design but it was
      completely overlooked...
      
      Cc: David Quan <david.quan@atheros.com>
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      cc: Easwar Krishnan <easwar.krishnan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ca4ffe8f
  17. 12 10月, 2010 1 次提交
  18. 07 10月, 2010 2 次提交
  19. 06 10月, 2010 3 次提交
  20. 17 9月, 2010 1 次提交
  21. 28 8月, 2010 1 次提交
  22. 25 8月, 2010 2 次提交
  23. 25 6月, 2010 2 次提交
  24. 03 6月, 2010 1 次提交
  25. 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
  26. 28 4月, 2010 1 次提交
  27. 08 4月, 2010 1 次提交
    • J
      cfg80211: Add local-state-change-only auth/deauth/disassoc · d5cdfacb
      Jouni Malinen 提交于
      cfg80211 is quite strict on allowing authentication and association
      commands only in certain states. In order to meet these requirements,
      user space applications may need to clear authentication or
      association state in some cases. Currently, this can be done with
      deauth/disassoc command, but that ends up sending out Deauthentication
      or Disassociation frame unnecessarily. Add a new nl80211 attribute to
      allow this sending of the frame be skipped, but with all other
      deauth/disassoc operations being completed.
      
      Similar state change is also needed for IEEE 802.11r FT protocol in
      the FT-over-DS case which does not use Authentication frame exchange
      in a transition to another BSS. For this to work with cfg80211, an
      authentication entry needs to be created for the target BSS without
      sending out an Authentication frame. The nl80211 authentication
      command can be used for this purpose, too, with the new attribute to
      indicate that the command is only for changing local state. This
      enables wpa_supplicant to complete FT-over-DS transition successfully.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d5cdfacb
  28. 25 3月, 2010 2 次提交