1. 07 May, 2010 6 commits
    • Johannes Berg's avatar
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg authored
      
      
      Currently, when one interface switches HT mode,
      all others will follow along. This is clearly
      undesirable, since the new one might switch to
      no-HT while another one is operating in HT.
      
      Address this issue by keeping track of the HT
      mode per interface, and allowing only changes
      that are compatible, i.e. switching into HT40+
      is not possible when another interface is in
      HT40-, in that case the second one needs to
      fall back to HT20.
      
      Also, to allow drivers to know what's going on,
      store the per-interface HT mode (channel type)
      in the virtual interface's bss_conf.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
    • Johannes Berg's avatar
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f444de05
    • Johannes Berg's avatar
      mac80211: fix BSS info reconfiguration · ac8dd506
      Johannes Berg authored
      
      
      When reconfiguring an interface due to a previous
      hardware restart, mac80211 will currently include
      the new IBSS flag on non-IBSS interfaces which may
      confuse drivers.
      
      Instead of doing the ~0 trick, simply spell out
      which things are going to be reconfigured.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ac8dd506
    • David Kilroy's avatar
      orinoco: refactor xmit path · bac6fafd
      David Kilroy authored
      
      
      ... so orinoco_usb can share some common functionality.
      
      Handle 802.2 encapsulation and MIC calculation in that function.
      The 802.3 header is prepended to the SKB. The calculated MIC is written
      to a specified buffer. Also modify the transmit control word that will
      be passed onto the hardware to specify whether the MIC is present, and
      the key used.
      Signed-off-by: default avatarDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bac6fafd
    • Felix Fietkau's avatar
      ath9k: fix another source of corrupt frames · 3ef83d74
      Felix Fietkau authored
      
      
      Atheros hardware supports receiving frames that span multiple
      descriptors and buffers. In this case, the rx status of every
      descriptor except for the last one is invalid and may contain random
      data. Because the driver does not support this, it needs to drop such
      frames.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3ef83d74
    • Christian Lamparter's avatar
      ar9170usb: remove deprecated aggregation code · f3926b49
      Christian Lamparter authored
      
      
      This patch removes the incomplete AMPDU implementation in ar9170usb.
      
      The code in question is:
       * too big and complex (more than 550 SLOC.)
         This is enough to qualify for a new separate code file!
      
       * unbalanced quantity & quality
      	over-engineered areas like:
      		* xmit scheduling and queuing frames for multiple HT peers
      		* redundant frame sorting
      	are confronted by gaping holes:
      		* accurate transmission feedback
      		* firmware error-handling and device reset
      		* HT rate control algorithm
      
       * error-prone
      	Since its inclusion, hardly anything was done to fix
      	any of the outlined flaws from the initial commit message.
      
         => This also indicates poor maintainability.
      
       * relies heavily on several spinlocks.
      
      As a result of this shortcomings, the code is slow and does not
      even support the most basic 11n requirement: HT station mode.
      
      Therefore, I request to purge my heap of **** from the kernel:
      "ar9170: implement transmit aggregation".
      
      The next item on the agenda is: (re-)start from scratch with
      an adequate design to accommodate the special requirements
      and features of the available frameworks and tools.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f3926b49
  2. 05 May, 2010 2 commits
  3. 04 May, 2010 6 commits
  4. 03 May, 2010 17 commits
  5. 30 Apr, 2010 9 commits