1. 07 May, 2010 11 commits
    • John W. Linville's avatar
      mac80211: set IEEE80211_TX_CTL_FIRST_FRAGMENT for beacons · a472e71b
      John W. Linville authored
      Also simplify the flags assignment into a single statement at the
      end of ieee80211_beacon_get_tim.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a472e71b
    • Ivo van Doorn's avatar
      rt2x00: Fix RF3052 channel initialization · 55f9321a
      Ivo van Doorn authored
      Update channel initialization for the RF3052 chipset.
      According to the Ralink drivers, the rt3x array must be
      used for this chipset, rather then the rt2x array.
      
      Furthermore RF3052 supports the 5GHz band, extend
      the rt3x array with the 5GHz channels, and use them
      for the RF3052 chip.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      55f9321a
    • Helmut Schaa's avatar
      rt2x00: rt2800: don't overwrite SIFS values on erp changes · 809bfe81
      Helmut Schaa authored
      The SIFS value is a constant and doesn't need to be updated on erp changes.
      Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
      which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
      initial SIFS values" for details).
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      809bfe81
    • Helmut Schaa's avatar
      rt2x00: rt2800: update initial SIFS values · a21c2ab4
      Helmut Schaa authored
      Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
      used by the Ralink driver nor specified in 802.11.
      
      Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
      Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
      11g + CTS protected connections. Add a comment to the code why we don't use 10us
      for CCK SIFS value.
      
      The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
      Ralink drivers).
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a21c2ab4
    • Sujith's avatar
      ath9k_htc: Fix beaconing in IBSS mode · 9c6dda4e
      Sujith authored
      The current way of managing beaconing in ad-hoc
      mode has a subtle race - the beacon obtained from mac80211
      is freed in the SWBA handler rather than the TX
      completion routine. But transmission of beacons goes
      through the normal SKB queue maintained in hif_usb,
      leading to a situation where __skb_dequeue() in the TX
      completion handler goes kaput.
      
      Fix this by simply getting a beacon from mac80211 for
      every SWBA and free it in its completion routine.
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9c6dda4e
    • 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 4 commits