1. 19 Feb, 2010 34 commits
  2. 16 Feb, 2010 3 commits
  3. 15 Feb, 2010 3 commits
    • Jouni Malinen's avatar
      cfg80211/mac80211: allow registering for and sending action frames · 026331c4
      Jouni Malinen authored
      This implements a new command to register for action frames
      that userspace wants to handle instead of the in-kernel
      rejection. It is then responsible for rejecting ones that
      it decided not to handle. There is no unregistration, but
      the socket can be closed for that.
      
      Frames that are not registered for will not be forwarded
      to userspace and will be rejected by the kernel, the
      cfg80211 API helps implementing that.
      
      Additionally, this patch adds a new command that allows
      doing action frame transmission from userspace. It can be
      used either to exchange action frames on the current
      operational channel (e.g., with the AP with which we are
      currently associated) or to exchange off-channel Public
      Action frames with the remain-on-channel command.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      026331c4
    • Johannes Berg's avatar
      mac80211: reject unhandled action frames · 84040805
      Johannes Berg authored
      802.11-2007 7.3.1.11 mandates that we need to
      reject action frames we don't handle by setting
      the 0x80 bit in the category and returning them
      to the sender, so do that. In AP mode, hostapd
      is responsible for this.
      
      Additionally, drop completely malformed action
      frames or ones that should've been encrypted as
      unusable, userspace shouldn't see those.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      84040805
    • Gertjan van Wingerde's avatar
      rt2x00: rt2800 - Make rt30xx and rt35xx chipsets configurable. · de1ebdce
      Gertjan van Wingerde authored
      Support for rt30xx- and rt35xx-based devices is currently not functional
      in rt2800pci and rt2800usb.
      In order to not confuse users we shouldn't claim the PCI and USB device
      ID's for these devices. However, to allow for testing it is good to still
      have them available, although disabled by default.
      Make support for these device configuration options that default to off.
      
      For rt2800usb a 3rd class of devices is added, which are the unknown
      devices. For these devices it is known that they are either based on
      rt28xx, rt30xx or rt35xx, but it is not known on what chipset exactly.
      These devices are disabled by default as well, until it can be established
      on what chipset exactly they are based.
      Signed-off-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      de1ebdce