1. 10 Jun, 2015 1 commit
    • Alexis Green's avatar
      mac80211: Fix a case of incorrect metric used when forwarding a PREQ · 5ec596c4
      Alexis Green authored
      This patch fixes a bug in hwmp_preq_frame_process where the wrong metric
      can be used when forwarding a PREQ. This happens because the code uses
      the same metric variable to record the value of the metric to the source
      of the PREQ and the value of the metric to the target of the PREQ.
      
      This comes into play when both reply and forward are set which happens
      when IEEE80211_PREQ_PROACTIVE_PREP_FLAG is set and when MP_F_DO | MP_F_RF
      is set. The original code had a special case to handle the first case
      but not the second.
      
      The patch uses distinct variables for the two metrics which makes the
      code flow much clearer and removes the need to restore the original
      value of metric when forwarding.
      Signed-off-by: default avatarAlexis Green <agreen@cococorp.com>
      CC: Jesse Jones <jjones@cococorp.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5ec596c4
  2. 09 Jun, 2015 7 commits
    • Alexis Green's avatar
      mac80211: Always check rates and capabilities in mesh mode · e060e7ad
      Alexis Green authored
      In mesh mode there is a race between establishing links and processing
      rates and capabilities in beacons. This is very noticeable with slow
      beacons (e.g. beacon intervals of 1s) and manifested for us as stations
      using minstrel when minstrel_ht should be used. Fixed by changing
      mesh_sta_info_init so that it always checks rates and such if it has not
      already done so.
      Signed-off-by: default avatarAlexis Green <agreen@cococorp.com>
      CC: Jesse Jones <jjones@cococorp.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      e060e7ad
    • Chun-Yeow Yeoh's avatar
      mac80211: fix the beacon csa counter for mesh and ibss · 8df734e8
      Chun-Yeow Yeoh authored
      The csa counter has moved from sdata to beacon/presp but
      it is not updated accordingly for mesh and ibss. Fix this.
      
      Fixes: af296bdb ("mac80211: move csa counters from sdata to beacon/presp")
      Signed-off-by: default avatarChun-Yeow Yeoh <yeohchunyeow@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8df734e8
    • Alexis Green's avatar
      mac80211: Fix incorrectly named last_hop_metric variable in mesh_rx_path_sel_frame · afd2efb9
      Alexis Green authored
      The last hop metric should refer to link cost (this is how
      hwmp_route_info_get uses it for example). But in mesh_rx_path_sel_frame
      we are not dealing with link cost but with the total cost to the origin
      of a PREQ or PREP.
      Signed-off-by: default avatarAlexis Green <agreen@cococorp.com>
      CC: Jesse Jones <jjones@cococorp.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      afd2efb9
    • Sara Sharon's avatar
      mac80211: ignore invalid scan RSSI values · 74d803b6
      Sara Sharon authored
      Channels in 2.4GHz band overlap, this means that if we
      send a probe request on channel 1 and then move to channel
      2, we will hear the probe response on channel 2. In this
      case, the RSSI will be lower than if we had heard it on
      the channel on which it was sent (1 in this case).
      
      The scan result ignores those invalid values and the
      station last signal should not be updated as well.
      
      In case the scan determines the signal to be invalid turn on
      the flag so the station last signal will not be updated with
      the value and thus user space probing for NL80211_STA_INFO_SIGNAL
      and NL80211_STA_INFO_SIGNAL_AVG will not get this invalid RSSI
      value.
      Signed-off-by: default avatarSara Sharon <sara.sharon@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      74d803b6
    • Michal Kazior's avatar
      mac80211: release channel on auth failure · d01f858c
      Michal Kazior authored
      There were a few rare cases when upon
      authentication failure channel wasn't released.
      This could cause stale pointers to remain in
      chanctx assigned_vifs after interface removal and
      trigger general protection fault later.
      
      This could be triggered, e.g. on ath10k with the
      following steps:
      
       1. start an AP
       2. create 2 extra vifs on ath10k host
       3. connect vif1 to the AP
       4. connect vif2 to the AP
          (auth fails because ath10k firmware isn't able
           to maintain 2 peers with colliding AP mac
           addresses across vifs and consequently
           refuses sta_info_insert() in
           ieee80211_prep_connection())
       5. remove the 2 extra vifs
       6. goto step 2; at step 3 kernel was crashing:
      
       general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
       Modules linked in: ath10k_pci ath10k_core ath
       ...
       Call Trace:
        [<ffffffff81a2dabb>] ieee80211_check_combinations+0x22b/0x290
        [<ffffffff819fb825>] ? ieee80211_check_concurrent_iface+0x125/0x220
        [<ffffffff8180f664>] ? netpoll_poll_disable+0x84/0x100
        [<ffffffff819fb833>] ieee80211_check_concurrent_iface+0x133/0x220
        [<ffffffff81a0029e>] ieee80211_open+0x3e/0x80
        [<ffffffff817f2d26>] __dev_open+0xb6/0x130
        [<ffffffff817f3051>] __dev_change_flags+0xa1/0x170
       ...
       RIP  [<ffffffff81a23140>] ieee80211_chanctx_radar_detect+0xa0/0x170
      
       (gdb) l * ieee80211_chanctx_radar_detect+0xa0
       0xffffffff81a23140 is in ieee80211_chanctx_radar_detect (/devel/src/linux/net/mac80211/util.c:3182).
       3177             */
       3178            WARN_ON(ctx->replace_state == IEEE80211_CHANCTX_REPLACES_OTHER &&
       3179                    !list_empty(&ctx->assigned_vifs));
       3180
       3181            list_for_each_entry(sdata, &ctx->assigned_vifs, assigned_chanctx_list)
       3182                    if (sdata->radar_required)
       3183                            radar_detect |= BIT(sdata->vif.bss_conf.chandef.width);
       3184
       3185            return radar_detect;
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d01f858c
    • Jakub Kicinski's avatar
      mac80211: remove obsolete sentence from documentation · c2d3955b
      Jakub Kicinski authored
      FIF_PROMISC_IN_BSS was removed in commit df140465
      ("mac80211: remove support for IFF_PROMISC").
      Signed-off-by: default avatarJakub Kicinski <kubakici@wp.pl>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c2d3955b
    • Johannes Berg's avatar
      mac80211: handle aggregation session timeout on fast-xmit path · 472be00d
      Johannes Berg authored
      The conversion to the fast-xmit path lost proper aggregation session
      timeout handling - the last_tx wasn't set on that path and the timer
      would therefore incorrectly tear down the session periodically (with
      those drivers/rate control algorithms that have a timeout.)
      
      In case of iwlwifi, this was every 5 seconds and caused significant
      throughput degradation.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      472be00d
  3. 02 Jun, 2015 5 commits
    • Johannes Berg's avatar
      mac80211: rename single hw-scan flag to follow naming convention · c526a467
      Johannes Berg authored
      The naming convention is to always have the flags prefixed with
      IEEE80211_HW_ so they're 'namespaced', make this flag follow it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c526a467
    • Johannes Berg's avatar
      mac80211: remove short slot/short preamble incapable flags · ea1b2b45
      Johannes Berg authored
      There are no drivers setting IEEE80211_HW_2GHZ_SHORT_SLOT_INCAPABLE
      or IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE, so any code using the
      two flags is dead; it's also exceedingly unlikely that any new driver
      could ever need to set these flags.
      
      The wcn36xx code is almost certainly broken, but this preserves the
      previous behaviour.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ea1b2b45
    • Johannes Berg's avatar
      mac80211: stop using pointers as userspace cookies · 3b79af97
      Johannes Berg authored
      Even if the pointers are really only accessible to root and used
      pretty much only by wpa_supplicant, this is still not great; even
      for debugging it'd be easier to have something that's easier to
      read and guaranteed to never get reused.
      
      With the recent change to make mac80211 create an ack_skb for the
      mgmt-tx path this becomes possible, only the client probe method
      needs to also allocate an ack_skb, and we can store the cookie in
      that skb.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3b79af97
    • Johannes Berg's avatar
      mac80211: copy nl80211 mgmt TX SKB for status · b2eb0ee6
      Johannes Berg authored
      When we return the TX status for an nl80211 mgmt TX SKB, we
      should also return the original frame with the status to
      allow userspace to match up the submission (it could also
      use the cookie but both ways are permissible.)
      
      As TX SKBs could be encrypted, at least in the case of ANQP
      while associated with the AP, copy the original SKB, store
      it with an ACK frame ID and restructure the status path to
      use that to return status with the original SKB. Otherwise,
      userspace (in particular wpa_supplicant) will get confused.
      Reported-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b2eb0ee6
    • Johannes Berg's avatar
      mac80211: move TX PN to public part of key struct · db388a56
      Johannes Berg authored
      For drivers supporting TSO or similar features, but that still have
      PN assignment in software, there's a need to have some memory to
      store the current PN value. As mac80211 already stores this and it's
      somewhat complicated to add a per-driver area to the key struct (due
      to the dynamic sizing thereof) it makes sense to just move the TX PN
      to the keyconf, i.e. the public part of the key struct.
      
      As TKIP is more complicated and we won't able to offload it in this
      way right now (fast-xmit is skipped for TKIP unless the HW does it
      all, and our hardware needs MMIC calculation in software) I've not
      moved that for now - it's possible but requires exposing a lot of
      the internal TKIP state.
      
      As an bonus side effect, we can remove a lot of code by assuming the
      keyseq struct has a certain layout - with BUILD_BUG_ON to verify it.
      
      This might also improve performance, since now TX and RX no longer
      share a cacheline.
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      db388a56
  4. 01 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: act upon and report deauth while associating · c9c99f89
      Johannes Berg authored
      When trying to associate, the AP could send a deauth frame instead.
      Currently mac80211 drops that frame and doesn't report it to the
      supplicant, which, in some versions and/or in certain circumstances
      will simply keep trying to associate over and over again instead of
      trying authentication again.
      
      Fix this by reacting to deauth frames while associating, reporting
      them to the supplicant and dropping the association attempt (which
      is bound to fail.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c9c99f89
  5. 29 May, 2015 3 commits
    • Uwe Kleine-König's avatar
      net: rfkill: gpio: make better use of gpiod API · f7959e9c
      Uwe Kleine-König authored
      Since 39b2bbe3 (gpio: add flags argument to gpiod_get*() functions)
      which appeared in v3.17-rc1, the gpiod_get* functions take an additional
      parameter that allows to specify direction and initial value for output.
      
      Furthermore there is devm_gpiod_get_optional which is designed to get
      optional gpios.
      
      Simplify driver accordingly.
      
      Note this makes error checking more strict because only -ENOENT is
      ignored when searching for the GPIOs which is good.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f7959e9c
    • Michal Kazior's avatar
      cfg80211: ignore netif running state when changing iftype · 6cbfb1bb
      Michal Kazior authored
      It was possible for mac80211 to be coerced into an
      unexpected flow causing sdata union to become
      corrupted. Station pointer was put into
      sdata->u.vlan.sta memory location while it was
      really master AP's sdata->u.ap.next_beacon. This
      led to station entry being later freed as
      next_beacon before __sta_info_flush() in
      ieee80211_stop_ap() and a subsequent invalid
      pointer dereference crash.
      
      The problem was that ieee80211_ptr->use_4addr
      wasn't cleared on interface type changes.
      
      This could be reproduced with the following steps:
      
       # host A and host B have just booted; no
       # wpa_s/hostapd running; all vifs are down
       host A> iw wlan0 set type station
       host A> iw wlan0 set 4addr on
       host A> printf 'interface=wlan0\nssid=4addrcrash\nchannel=1\nwds_sta=1' > /tmp/hconf
       host A> hostapd -B /tmp/conf
       host B> iw wlan0 set 4addr on
       host B> ifconfig wlan0 up
       host B> iw wlan0 connect -w hostAssid
       host A> pkill hostapd
       # host A crashed:
      
       [  127.928192] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c8
       [  127.929014] IP: [<ffffffff816f4f32>] __sta_info_flush+0xac/0x158
       ...
       [  127.934578]  [<ffffffff8170789e>] ieee80211_stop_ap+0x139/0x26c
       [  127.934578]  [<ffffffff8100498f>] ? dump_trace+0x279/0x28a
       [  127.934578]  [<ffffffff816dc661>] __cfg80211_stop_ap+0x84/0x191
       [  127.934578]  [<ffffffff816dc7ad>] cfg80211_stop_ap+0x3f/0x58
       [  127.934578]  [<ffffffff816c5ad6>] nl80211_stop_ap+0x1b/0x1d
       [  127.934578]  [<ffffffff815e53f8>] genl_family_rcv_msg+0x259/0x2b5
      
      Note: This isn't a revert of f8cdddb8
      ("cfg80211: check iface combinations only when
      iface is running") as far as functionality is
      considered because b6a55015 ("cfg80211/mac80211:
      move more combination checks to mac80211") moved
      the logic somewhere else already.
      
      Fixes: f8cdddb8 ("cfg80211: check iface combinations only when iface is running")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6cbfb1bb
    • Michal Kazior's avatar
      mac80211: prevent possible crypto tx tailroom corruption · ab499db8
      Michal Kazior authored
      There was a possible race between
      ieee80211_reconfig() and
      ieee80211_delayed_tailroom_dec(). This could
      result in inability to transmit data if driver
      crashed during roaming or rekeying and subsequent
      skbs with insufficient tailroom appeared.
      
      This race was probably never seen in the wild
      because a device driver would have to crash AND
      recover within 0.5s which is very unlikely.
      
      I was able to prove this race exists after
      changing the delay to 10s locally and crashing
      ath10k via debugfs immediately after GTK
      rekeying. In case of ath10k the counter went below
      0. This was harmless but other drivers which
      actually require tailroom (e.g. for WEP ICV or
      MMIC) could end up with the counter at 0 instead
      of >0 and introduce insufficient skb tailroom
      failures because mac80211 would not resize skbs
      appropriately anymore.
      
      Fixes: 8d1f7ecd ("mac80211: defer tailroom counter manipulation when roaming")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ab499db8
  6. 26 May, 2015 1 commit
    • Johannes Berg's avatar
      cfg80211: properly send NL80211_ATTR_DISCONNECTED_BY_AP in disconnect · 80279fb7
      Johannes Berg authored
      When we disconnect from the AP, drivers call cfg80211_disconnect().
      This doesn't know whether the disconnection was initiated locally
      or by the AP though, which can cause problems with the supplicant,
      for example with WPS. This issue obviously doesn't show up with any
      mac80211 based driver since mac80211 doesn't call this function.
      
      Fix this by requiring drivers to indicate whether the disconnect is
      locally generated or not. I've tried to update the drivers, but may
      not have gotten the values correct, and some drivers may currently
      not be able to report correct values. In case of doubt I left it at
      false, which is the current behaviour.
      
      For libertas, make adjustments as indicated by Dan Williams.
      Reported-by: default avatarMatthieu Mauger <matthieux.mauger@intel.com>
      Tested-by: default avatarMatthieu Mauger <matthieux.mauger@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      80279fb7
  7. 20 May, 2015 6 commits
  8. 11 May, 2015 3 commits
  9. 07 May, 2015 1 commit
  10. 06 May, 2015 8 commits
  11. 05 May, 2015 4 commits