- Jun 10, 2015
-
-
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:
Alexis Green <agreen@cococorp.com> CC: Jesse Jones <jjones@cococorp.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Alexis Green <agreen@cococorp.com> CC: Jesse Jones <jjones@cococorp.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Alexis Green <agreen@cococorp.com> CC: Jesse Jones <jjones@cococorp.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Jakub Kicinski authored
FIF_PROMISC_IN_BSS was removed in commit df140465 ("mac80211: remove support for IFF_PROMISC"). Signed-off-by:
Jakub Kicinski <kubakici@wp.pl> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Johannes Berg <johannes.berg@intel.com>
-
- Jun 03, 2015
-
-
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:
Johannes Berg <johannes.berg@intel.com>
-
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:
Johannes Berg <johannes.berg@intel.com>
-
- Jun 02, 2015
-
-
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:
Johannes Berg <johannes.berg@intel.com>
-
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:
Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- Jun 01, 2015
-
-
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:
Johannes Berg <johannes.berg@intel.com>
-
- May 29, 2015
-
-
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:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
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:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- May 26, 2015
-
-
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:
Matthieu Mauger <matthieux.mauger@intel.com> Tested-by:
Matthieu Mauger <matthieux.mauger@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- May 20, 2015
-
-
Arik Nemtsov authored
When a station does a channel switch, it's not well defined what its TDLS peers would do. Avoid a situation when the local side marks a potentially disconnected peer as a TDLS peer. Keeping peers connected through CSA is doubly problematic with the upcoming TDLS WIDER-BW feature which allows peers to widen the BSS channel. The new channel transitioned-to might not be compatible and would require a re-negotiation anyway. Make sure to disallow new TDLS link during CSA. Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Michal Kazior authored
Drivers with fast-xmit (e.g. ath10k) running in AP_VLAN setups would fail to communicate with connected 4addr stations. The reason was when new station associates it first goes into master AP interface. It is not until later that a dedicated AP_VLAN is created for it and the station itself is moved there. After that Tx directed at the station should use 4addr header. However fast-xmit wasn't recalculated and 3addr header remained to be used. This in turn caused the connected 4addr stations to drop packets coming from the AP until some other event would cause fast-xmit to recalculate for that station (which could never come). Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The kernel-doc description for the drv_priv member of struct ieee80211_txq was missing, leading to errors. Add a suitable description to fix that. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Lars-Peter Clausen authored
Use dev_pm_ops instead of the legacy suspend/resume callbacks for the wiphy class suspend and resume operations. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Lars-Peter Clausen authored
Use dev_pm_ops instead of the legacy suspend/resume callbacks for the rfkill class suspend and resume operations. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
My recent change here introduced a possible memory leak if the driver registers an invalid cipher schemes. This won't really happen in practice, but fix the leak nonetheless. Fixes: e3a55b53 ("mac80211: validate cipher scheme PN length better") Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- May 12, 2015
-
-
Johannes Berg authored
As I was testing with hwsim, I missed that my previous commit to make LED work depend on activation broke the code because I missed removing the old trigger struct and some code was still using it, now erroneously, causing crashes. Fix this by always using the correct struct. Reported-by:
Felix Fietkau <nbd@openwrt.org> Tested-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- May 11, 2015
-
-
Arik Nemtsov authored
The chandef of the current channel context might be wider (though compatible). The TDLS link cares only about the channel of the BSS. In addition make sure to specify the VHT operation IE when VHT is supported on a non-2.4GHz band, as required by IEEE802.11ac-2013. This is not the same as HT-operation, to be specified only if the BSS doesn't support HT. Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When an IBSS station gets QoS enabled after having been added, check fast-xmit to make sure the QoS header gets added to the cache properly and frames can go out with QoS and higher rates. Reported-by:
Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- May 07, 2015
-
-
Andrei Otcheretianski authored
When a vif starts using a reserved channel context (during CSA, for example) the required chandef was recalculated, however it was never applied. This could result in using chanctx with narrower width than actually required. Fix this by calling ieee80211_change_chanctx with the recalculated chandef. This both changes the chanctx's width and recalcs min_def. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- May 06, 2015
-
-
Johannes Berg authored
This was missed in the previous patch, add some documentation for rate_ctrl_lock to avoid docbook warnings. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
The GO_CONCURRENT regulatory definition can be extended to station interfaces requesting to IR as part of TDLS off-channel operations. Rename the GO_CONCURRENT flag to IR_CONCURRENT and allow the added use-case. Change internal users of GO_CONCURRENT to use the new definition. Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Ilan Peer authored
Declare that MCS 0-9 are supported for all Rx chains. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Ilan Peer authored
Previously, VHT capabilities and supported MCSs where set for all bands, although VHT is only allowed on 5.2 GHz band. Fix it. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Avraham Stern authored
If a P2P GO was allowed on a channel because of the GO concurrent relaxation, i.e., another station interface was associated to an AP on the same channel or the same UNII band, and the station interface disconnected from the AP, allow the following use cases unless the channel is marked as indoor only and the device is not operating in an indoor environment: 1. Allow the P2P GO to stay on its current channel. The rationale behind this is that if the channel or UNII band were allowed by the AP they could still be used to continue the P2P GO operation, and avoid connection breakage. 2. Allow another P2P GO to start on the same channel or another channel that is in the same UNII band as the previous instantiated P2P GO. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Currently, a cipher scheme can advertise an arbitrarily long sequence counter, but mac80211 only supports up to 16 bytes and the initial value from userspace will be truncated. Fix two things: * don't allow the driver to register anything longer than the 16 bytes that mac80211 reserves space for * require userspace to specify a starting value with the correct length (or none at all) Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
For ciphers not supported by mac80211, the function currently doesn't return any PN data. Fix this by extending the driver's get_key_seq() a little more to allow moving arbitrary PN data. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Extend the function to read the TKIP IV32/IV16 to read the IV/PN for all ciphers in order to allow drivers with full hardware crypto to properly support this. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- May 05, 2015
-
-
Johannes Berg authored
No current (and planned, as far as I know) wifi devices support encapsulation checksum offload, so remove the useless test here. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When LED triggers are compiled in, but not used, mac80211 will still call them to update the status. This isn't really a problem for the assoc and radio ones, but the TX/RX (and to a certain extend TPT) ones can be called very frequently (for every packet.) In order to avoid that when they're not used, track their activation and call the corresponding trigger (and in the TPT case, account for throughput) only when the trigger is actually used by an LED. Additionally, make those trigger functions inlines since theyre only used once in the remaining code. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This is just a code cleanup, make the LED trigger names const as they're not expected to be modified by drivers. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Remove items that can be retrieved through nl80211. This also removes two items (tx_packets and tx_bytes) where only the VO counter was exposed since they are split up per AC but in the debugfs file only the first AC was shown. Also remove the useless "dev" file - the stations have long been in a sub-directory of the netdev so there's no need for that any more. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-