1. 17 4月, 2015 5 次提交
    • J
      ath10k: enable ibss-rsn · 0cd9bc14
      Janusz Dziedzic 提交于
      With latest additions to the driver it seems
      viable to enable support for IBSS-RSN.
      
      It seems to work on QCA988X and 999.999.0.636 but
      is a bit slow to exchange RSN keys for some
      reason. This may be a firmware quirk or ath10k is
      missing something. Nevertheless it makes sense to
      finally enable IBSS-RSN in ath10k even if somewhat
      handicapped.
      
      QCA6174 firmware doesn't seem to be able to Tx
      EAPOL frames at all now (they get stuck in hw
      queues for some reason) so it never gets to set
      the keys in driver. It's fairly safe to assume that
      once this is fixed IBSS-RSN will work with QCA6174
      firmware without any additional changes. Hence no
      special handling for advertising
      IEEE80211_HW_SUPPORTS_PER_STA_GTK and
      WIPHY_FLAG_IBSS_RSN is done now.
      Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0cd9bc14
    • M
      ath10k: set def key idx for ibss · 8461baf7
      Michal Kazior 提交于
      Some time ago there was a weird issue with AP
      using wrong multicast keys and generating
      corrupted traffic on 10.1 firmware.
      
      Apparently a very similar problem applies for
      IBSS-RSN on 999.999.0.636.
      
      ath10k doesn't have IBSS-RSN enabled yet. This
      patch is a prerequisite to support it.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      8461baf7
    • M
      ath10k: fix multiple key static wep with ibss · ce90b271
      Michal Kazior 提交于
      Apparently firmware requires both pairwise and
      groupwise keys to be installed per-peer for static
      WEP in IBSS. This wasn't necessary for AP mode
      (and installing both doesn't seem to break AP
      mode thus there's no special handling).
      
      Also there seems to be some kind of issue with
      mapping tx/rx keys in firmware properly which
      resulted in wrong keys being used and broken
      communication between devices.
      
      It can be argued the vdev param part is more of a
      workaround than a real fix. However I couldn't
      figure out how to fix this differently. It works
      and isn't super ugly.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ce90b271
    • M
      ath10k: don't use reassoc flag · 73dc5a1d
      Michal Kazior 提交于
      Firmware actually re-creates peer entry when
      reassoc flag is set. This is undesired and could
      cause trouble with IBSS crypto-wise. This is also
      important for upcomming bitrate mask improvement.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      73dc5a1d
    • M
      ath10k: change static wep key handling for client mode · 29a10006
      Michal Kazior 提交于
      mac80211 sets static WEP keys as groupwise while
      firmware requires them to be installed twice as
      both pairwise and groupwise.
      
      Until now these keys were installed once as
      pairwise only and, due to that special handling,
      needed additional tricks to support 802.1x as
      well.
      
      Without this patch in some cases (when AP and
      ath10k client use different default tx keys)
      multicast communication was broken.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      29a10006
  2. 15 4月, 2015 2 次提交
  3. 09 4月, 2015 3 次提交
  4. 02 4月, 2015 8 次提交
  5. 30 3月, 2015 15 次提交
  6. 23 3月, 2015 5 次提交
  7. 19 3月, 2015 2 次提交
    • J
      ath10k: setup maximum number of supported stations · 37a0b394
      Janusz.Dziedzic@tieto.com 提交于
      Setup maximum number of associated stations supported in
      AP/P2P_GO mode.
      
      This allow hostapd/wpa_supplicant to play with that limit
      and set more information (eg. P2P group limit bit for P2P_GO).
      Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      37a0b394
    • M
      ath10k: strip qos data bit always · 8bad8dcd
      Michal Kazior 提交于
      NativeWifi tx mode expects QoS Data frames to be
      delivered as Data frames with QoS part (e.g. tid)
      being delievered out-of-band in fw tx command.
      
      The QoS bit wasn't stripped before submitting to
      firmware.
      
      Stripping fixes two known problems:
      
       * qca6174 IOT with some APs, e.g.
         Cisco AIR-AP 1252 (which would crash after
         ath10k association). Some ath9k APs would
         crash as well.
      
       * sniffing own tx frames via radiotap because,
         e.g. wireshark was seeing QoS bit set but
         since QoS Control was stripped in ath10k it
         would parse beginning of LLC/SNAP
      
      >From debugability point of view this removes the
      ability to distinguish QoS from non-QoS frames
      when sniffing own tx via radiotap. On the other
      hand frames can be now parsed correctly without
      special software modification.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      8bad8dcd