- 30 Mar, 2015 9 commits
-
-
Arik Nemtsov authored
Seems Broadcom TDLS peers (Nexus 5, Xperia Z3) refuse to allow TDLS connection when channel-switching is supported but the regulatory classes IE is missing from the setup request. Add a chandef to reg-class translation function to cfg80211 and use it to add the required IE during setup. For now add only the current regulatory class as supported - it is enough to resolve the compatibility issue. 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>
-
Luciano Coelho authored
Just clarify that the delay is only before the first cycle. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
David Spinadel authored
Stop scan before authentication or association to make sure that nothing interferes with connection flow. Currently mac80211 defers RX auth and assoc packets (among other ones) until after the scan is complete, so auth during scan is likely to fail if scan took too much time. Signed-off-by: David Spinadel <david.spinadel@intel.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luciano Coelho authored
Pass the initial net-detect delay (NL80211_ATTR_SCHED_SCAN_DELAY) attribute in the WoWLAN info response. Additionally, remove a bogus TODO comment. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
This can allow the driver to take action based on the reason of the deauth. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
This can allow the driver to take action based on the success / failure of the association. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
This can allow the driver to take action based on the success / failure of the authentication. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
We will be able to add more events, such as MLME events and others. The low level driver may be interested in knowing about these events to dump firmware data upon failures, or to change parameters in case connection attempts fail etc... Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The rate control locking caused a potential deadlock here due to the locks being acquired in different orders, so that change cannot yet be applied. However, there's no fundamental reason for this code to hold the sta->lock while transmitting frames. Clearly it's better not to hold the lock for longer periods of time, which can happen here since we call all the way down to the driver. Change the code a bit to not hold it while doing that. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 20 Mar, 2015 6 commits
-
-
Johannes Berg authored
This helps debug issues with VLAN modifications that are otherwise not really visible in any tracing/debugging. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Instead of looking up the destination station twice in the TX path (first to build the header, and then for control processing), save it when building the header and use it later in the TX path. To avoid having to look up the station in the many callers, allow those to pass %NULL which keeps the existing lookup. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
In ieee80211_build_hdr(), the station is looked up to build the header correctly (QoS field) and to check for authorization. For mesh, authorization isn't checked here, and QoS capability is mandatory, so the station lookup can be avoided. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If there's no station on the 4-addr VLAN interface, then frames cannot be transmitted. Drop such frames earlier, before setting up all the information for them. We should keep the old check though since that code might be used for other internally-generated frames. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's no need to look up the destination station twice while building the 802.11 header for a given frame if the frame will actually be transmitted to the station we initially looked up. This happens for 4-addr VLAN interfaces and TDLS connections, which both directly send the frame to the station they looked up, though in the case of TDLS some station conditions need to be checked. To avoid that, add a variable indicating that we've looked up the station that the frame is going to be transmitted to, and avoid the lookup/flag checking if it already has been done. In the TDLS case, also move the authorized/wme_sta flag assignment to the correct place, i.e. only when that station is really used. Before this change, the new lookup should always have succeeded so that the potentially erroneous data would be overwritten. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This mechanism was historic, and only ever used by IBSS, which also doesn't need to have it as it properly manages station's 802.1X PAE state (or, with WEP, always has a key.) Remove the mechanism to clean up the code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 17 Mar, 2015 5 commits
-
-
Cedric Izoard authored
When a key is installed using a cipher scheme, set a new internal key flag (KEY_FLAG_CIPHER_SCHEME) on it, to allow distinguishing such keys more easily. In particular, use this flag on the TX path instead of testing the sta->cipher_scheme pointer, as the station is NULL for broad-/multicast message, and use the key's iv_len instead of the cipher scheme information. Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com> [add missing documentation, rewrite commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Janusz.Dziedzic@tieto.com authored
Put station specific code in ieee80211_update_sta_info function. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Felix Fietkau authored
On very high MCS bitrates, the calculated duration of rates that are next to each other can be very imprecise, due to the small packet size used as reference (1200 bytes). This is most visible in VHT80 nss=2 MCS8/9, for which minstrel shows the same throughput when the probability is also the same. This leads to a bad rate selection for such rates. Fix this issue by introducing an average A-MPDU size factor into the calculation. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Ben authored
It is possible that there are several regulatory requests pending, but the processing of the last one does not call CRDA, and thus the other requests are not handled. Fix this by rescheduling the work until all requests have been processed. Signed-off-by: Ben Rosenfeld <ben.rosenfeld@intel.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Marek Puzyniak authored
Currently when TDLS station in driver goes from authenticated to associated state it can not use rate control parameters because rate control is not initialized yet. Some drivers require parameters already initialized by rate control when entering associated state. It can be done by initializing rate control after station transition to associated state but before notifying driver about that. Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> [fix comment to say 'associated' instead of 'authorized'] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 16 Mar, 2015 4 commits
-
-
Johannes Berg authored
The schedule_work()/mutex unlocking code is duplicated many times, refactor that to a common place in the function. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
This will allow mac80211 drivers to call cfg80211 APIs with the right handle. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add a comment explaining how the RX path lock is used. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Move the netdev stats accounting into the common function ieee80211_deliver_skb() that is called in both places. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 06 Mar, 2015 3 commits
-
-
Ilan peer authored
Timeout was scheduled only in case CRDA was called due to user hints, but was not scheduled for other cases. This can result in regulatory hint processing getting stuck in case that there is no CRDA configured. Change this by scheduling a timeout every time CRDA is called. In addition, in restore_regulatory_settings() all pending requests are restored (and not only the user ones). Signed-off-by: Ilan Peer <ilan.peer@intel.com> Acked-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Ilan peer authored
Previously, the indoor setting configuration assumed that as long as a station interface is connected, the indoor environment setting does not change. However, this assumption is problematic as: - It is possible that a station interface is connected to a mobile AP, e.g., softAP or a P2P GO, where it is possible that both the station and the mobile AP move out of the indoor environment making the indoor setting invalid. In such a case, user space has no way to invalidate the setting. - A station interface disconnection does not necessarily imply that the device is no longer operating in an indoor environment, e.g., it is possible that the station interface is roaming but is still stays indoor. To handle the above, extend the indoor configuration API to allow user space to indicate a change of indoor settings, and allow it to indicate weather it controls the indoor setting, such that: 1. If the user space process explicitly indicates that it is going to control the indoor setting, do not clear the indoor setting internally, unless the socket is released. The user space process should use the NL80211_ATTR_SOCKET_OWNER attribute in the command to state that it is going to control the indoor setting. 2. Reset the indoor setting when restoring the regulatory settings in case it is not owned by a user space process. Based on the above, a user space tool that continuously monitors the indoor settings, i.e., tracking power setting, location etc., can indicate environment changes to the regulatory core. It should be noted that currently user space is the only provided mechanism used to hint to the regulatory core over the indoor/outdoor environment -- while the country IEs do have an environment setting this has been completely ignored by the regulatory core by design for a while now since country IEs typically can contain bogus data. Acked-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: ArikX Nemtsov <arik@wizery.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Ilan peer authored
Directly update the indoor setting without wrapping it as a regulatory request, to simplify the processing. Acked-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 04 Mar, 2015 12 commits
-
-
Johannes Berg authored
Jouni reported that certain combinations of hwsim test cases failed, and we found that beaconing was erroneously enabled too early on any channel switch, which lead to the BI of 2000 TU from the first test case to leak into the second one, which then didn't beacon properly. To fix this, set data->beacon_int to zero when all stop beaconing so that beaconing cannot be started (which was intended as 'restarted') elsewhere. Additionally, Jouni found that due to this 'restart' and the beacon interval handling station interfaces would also have a needlessly running beacon timer all the time, of course not doing anything. To also fix the latter case only use the beacon interval when it's actually needed, i.e. when beaconing gets enabled. Reported-by: Jouni Malinen <j@w1.fi> Tested-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Nicholas Mc Guire authored
timeout was being passed as int but assigned from u32/u16 values and used as unsigned type. This is really only for better readability. Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Nicholas Mc Guire authored
This is primarily an API consolidation and should make things more readable it replaces var * HZ / 1000 by msecs_to_jiffies(var) which also handles corner cases correctly. There is a change of behavior as e.g. for HZ 100, t * HZ / 1000 will return 0 for t < 10 but msecs_to_jiffies will return at least 1 always. Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
SenthilKumar Jegadeesan authored
Some device drivers offload part of aggregation including AddBA/DelBA negotiations to firmware. In such scenario, the PMF configuration of the station needs to be provided to driver to enable encryption of AddBA/DelBA action frames. Signed-off-by: SenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com> [fix commit log, documentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
Sometimes the driver might want to modify private data in interfaces that are down. One possible use-case is cleaning up interface state after HW recovery. Some interfaces that were up before the recovery took place might be down now, but they might still be "dirty". Introduce a new iterate_interfaces() API and a new ACTIVE iterator flag. This way the internal implementation of the both active and inactive APIs remains the same. 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>
-
Johannes Berg authored
If the device supports waking up on 'any' signal - i.e. it continues operating as usual and wakes up the host on pretty much anything that happens, then it makes no sense to also configure the more restricted WoWLAN mode where the device operates more autonomously but also in a more restricted fashion. Currently only cw2100 supports both 'any' and other triggers, but it seems to be broken as it doesn't configure anything to the device, so we can't currently get into a situation where both even can correctly be configured. This is about to change (Intel devices are going to support both and have different behaviour depending on configuration) so make sure the conflicting modes cannot be configured. (It seems that cw2100 advertises 'any' and 'disconnect' as a means of saying that's what it will always do, but that isn't really the way this API was meant to be used nor does it actually mean anything as 'any' always implies 'disconnect' already, and the driver doesn't change device configuration in any way depending on the settings.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The ieee80211_tx_prepare_skb() function currently entirely ignores the fact that the SKB that is passed in might be split into more than one due to fragmentation and doesn't check the list of skbs that the TX handlers may create. In case this happens, it would leak them. Fix this and also don't leave the skb next/prev pointers dangling pointing to the on-stack sk_buff_head. Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luciano Coelho authored
In ieee80211_queue_work() we check if we're quiescing or suspended, so it's not necessary to check for quiescing before calling this function. Remove duplicate checks. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
TDLS off-channel can be allowed in channels marked with GO_CONCURRENT, provided the device is connected to an AP on the same UNII. When relaxing the NO-IR requirements for TDLS, we might hit flows in cfg80211_reg_can_beacon that acquire the wdev lock. Take some measures to allow this during TDLS setup. Acquire the RCU read lock later in the flow that invokes cfg80211_reg_can_beacon. Avoid taking local->mtx when preparing the setup packet to avoid circular deadlocks with mac80211 code that is invoked with wdev-mtx held. 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>
-
Johannes Berg authored
If the driver rejects WoWLAN, restart the queues before returning to cfg80211. cfg80211 will return to mac80211, but not before it disconnects all interfaces. If we don't start the queues, any of the packets needed for disconnecting won't be transmitted, which is strange. Fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luciano Coelho authored
We check local->open_count at the top of the __ieee80211_suspend(), so there's no need to check for it again. open_count is protected by the rtnl, so there's no chance for it to have change between the two calls. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Drivers can't really be expected to suspend properly while auth or assoc is in progress since then they don't have any state they could keep with WoWLAN, nor can they actually finish the authentication or association. In fact, keeping this can cause subtle issues with drivers like iwlwifi that refuse WoWLAN if not associated, but have trouble figuring out what's going on in the middle of association. In any case, regardless of possible driver issues in this area, it doesn't make sense for mac80211 to try to WoWLAN-suspend in the middle of such operations, so stop them before. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 03 Mar, 2015 1 commit
-
-
Luciano Coelho authored
If any interface fails to be added to the driver in during reconfig, we should remove all the successfully added interfaces and report reconfig failure, so things can be cleaned up properly. Failing to do so can lead to subsequent failures and leave the drivers in a messed up state. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-