- 25 Nov, 2013 26 commits
-
-
Luciano Coelho authored
There is no reason why we should have only one channel switch announcement at a time for a single phy. When support for channel switch with multiple contexts and multiple vifs per context is implemented, we will need the chandef data for each vif. Move the csa_chandef structure to sdata to prepare for this. Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> [Fixed compilation with mesh] Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Chun-Yeow Yeoh authored
Use put_unaligned_le16 and put_unaligned_le32 for mesh_path_error_tx and mesh_path_sel_frame_tx. Signed-off-by:
Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by:
-
Chun-Yeow Yeoh authored
Use put_unaligned_le16 in mesh_plink_frame_tx. Signed-off-by:
-
Chun-Yeow Yeoh authored
use put_unaligned_le16 for precedence value in mesh channel switch support Signed-off-by:
-
Max Stepanov authored
This adds generic cipher scheme support to mac80211, such schemes are fully under control by the driver. On hw registration drivers may specify additional HW ciphers with a scheme how these ciphers have to be handled by mac80211 TX/RR. A cipher scheme specifies a cipher suite value, a size of the security header to be added to or stripped from frames and how the PN is to be verified on RX. Signed-off-by:
Max Stepanov <Max.Stepanov@intel.com> Signed-off-by:
-
Janusz Dziedzic authored
To report channel width correctly we have to send correct channel parameters from mac80211 when calling cfg80211_cac_event(). This is required in case of using channel width higher than 20MHz and we have to set correct dfs channel state after CAC (NL80211_DFS_AVAILABLE). Signed-off-by:
Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
-
Johannes Berg authored
There's no code calling ieee80211_key_replace() with both arguments NULL and it wouldn't make sense, but in the interest of maintainability add a warning for it. As a side effect, this also shuts up a smatch warning. Signed-off-by: -
Johannes Berg authored
Coverity points out that checking assoc_data->ie is completely useless since it's an array in the struct and can't be NULL - remove the useless checks. Signed-off-by: -
Thomas Pedersen authored
802.11-2012 13.3.1 implicitly limits the mesh local link ID range to that of AID, since for mesh PS the local link ID must be indicated in the TIM IE, which only holds IEEE80211_MAX_AID bits. Also the code was allowing a local link ID of 0, but this is not correct since that TIM bit is used for indicating buffered mcast frames. Generate a random, unique, link ID from 1 - 2007, and drop a modulo conversion for the local link ID, but keep it for the peer link ID in case he chose something > MAX_AID. Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Thomas Pedersen authored
If we store the peer link ID right after initializing a new neighbor, there is no need to do it later in the peering FSM. Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Thomas Pedersen authored
Signed-off-by:
-
Bob Copeland authored
Said function was removed some time ago. Signed-off-by:
Bob Copeland <bob@cozybit.com> Signed-off-by:
-
Bob Copeland authored
All other paths return an error code, do the same here. Signed-off-by:
-
Bob Copeland authored
The ignore_plink_timer flag is set when doing mod_timer() if the timer was not previously active. This is to avoid executing the timeout if del_timer() was subsequently called. However, del_timer() only happens if we are moving to ESTAB state or get a close frame while in HOLDING. We cannot leave HOLDING and re-enter ESTAB unless we receive a close frame (in which case ignore_plink_timer is already set) or if the timeout expires, so there actually isn't a case where this is needed on mod_timer(). Signed-off-by:
-
Bob Copeland authored
The matches_local check can just be done when looking at the individual action types. Signed-off-by:
-
Bob Copeland authored
Use C instead of cpp for type checking. Also swap the arguments into the usual sdata -> sta order. Signed-off-by:
-
Bob Copeland authored
The initial frame checks differ depending on whether this is a new peer or not, but they were all intermixed with sta checks as necessary. Group them together so the two cases are clearer. Signed-off-by:
-
Bob Copeland authored
Reject and accepted close events always put the host in the holding state and compute a reason code based only on the current state. Likewise on establish we always do the same setup. Put these in functions to save some duplicated code. Signed-off-by:
-
Bob Copeland authored
Rather than unlock at the end of each case, do it once after all is said and done. Signed-off-by:
-
Thomas Pedersen authored
Do all frame transfers in one place at the end of the big switch statements. sta->plid and sta->reason can be passed in any case, since they are only used for the frames that need them. Remove assignments to locals for values already stored in the sta structure. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Bob Copeland authored
According to IEEE 802.11-2012 (8.4.2.104), no peering management element exists with length 7. This code is checking to see if llid is present to ignore close frames with different llid, which would be IEs with length 8. Signed-off-by:
-
Karl Beldan authored
Currently, frames that go into the reordering buffer are stored at index ieee80211_sn_sub(sn, tid_rx->ssn) % tid_rx->buf_size. The offset calculation to the starting sequence number (SSN) is useless and just adds overhead so simply use sn % tid_rx->buf_size. This means the reordering buffer will start to be filled somewhere in the middle (at SSN % buf_size) and continue to get used from there, but there's no reason to start from the beginning. Signed-off-by:
Karl Beldan <karl.beldan@rivierawaves.com> [rewrite commit message] Signed-off-by:
-
Luis R. Rodriguez authored
These two flags are used for the same purpose, just combine them into a no-ir flag to annotate no initiating radiation is allowed. Old userspace sending either flag will have it treated as the no-ir flag. To be considerate to older userspace we also send both the no-ir flag and the old no-ibss flags. Newer userspace will have to be aware of older kernels. Update all places in the tree using these flags with the following semantic patch: @@ @@ -NL80211_RRF_PASSIVE_SCAN +NL80211_RRF_NO_IR @@ @@ -NL80211_RRF_NO_IBSS +NL80211_RRF_NO_IR @@ @@ -IEEE80211_CHAN_PASSIVE_SCAN +IEEE80211_CHAN_NO_IR @@ @@ -IEEE80211_CHAN_NO_IBSS +IEEE80211_CHAN_NO_IR @@ @@ -NL80211_RRF_NO_IR | NL80211_RRF_NO_IR +NL80211_RRF_NO_IR @@ @@ -IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_NO_IR +IEEE80211_CHAN_NO_IR @@ @@ -(NL80211_RRF_NO_IR) +NL80211_RRF_NO_IR @@ @@ -(IEEE80211_CHAN_NO_IR) +IEEE80211_CHAN_NO_IR Along with some hand-optimisations in documentation, to remove duplicates and to fix some indentation. Signed-off-by:
-
- 28 Oct, 2013 11 commits
-
-
Michal Kazior authored
CSA completion could call in a driver bss_info_changed() with a garbled `changed` flag leading to all sorts of problems. Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
-
Chun-Yeow Yeoh authored
Trigger the mesh channel switching procedure if the mesh STA happens to miss the CSA action frame but able to receive the beacon containing the CSA and MCSP elements from its peer mesh STAs. Signed-off-by:
Chun-Yeow Yeoh <yeohchunyeow@cozybit.com> [fix locking in ieee80211_mesh_process_chnswitch()] Signed-off-by:
-
Chun-Yeow Yeoh authored
Implement the required procedures for mesh channel switching as defined in the IEEE Std 802.11-2012 section 10.9.8.4.3 and also handle the CSA and MCSP elements as followed: * Add the function for updating the beacon and probe response frames with CSA and MCSP elements during the period of switching to the new channel. Both CSA and MCSP elements must be included in beacon and probe response frames until the intended channel switch time. * The ifmsh->csa_settings is set to NULL and the CSA and MCSP elements will then be removed from the beacon or probe response frames once the new channel is switched to. Signed-off-by:
-
Chun-Yeow Yeoh authored
Allow the triggering of CSA frame using mesh interface. The rules are more or less same with IBSS, such as not allowed to change between the band and channel width has to be same from the previous mode. Also, move the ieee80211_send_action_csa to a common space so that it can be re-used by mesh interface. Signed-off-by:
-
Chun-Yeow Yeoh authored
Process the CSA frame according to the procedures define in IEEE Std 802.11-2012 section 10.9.8.4.3 as follow: * The mesh channel switch parameters element (MCSP) must be availabe. * If the MCSP's TTL is 1, drop the frame but still process the CSA. * If the MCSP's precedence value is less than or equal to the current precedence value, drop the frame and do not process the CSA. * The CSA frame is forwarded after TTL is decremented by 1 and the initiator field is set to 0. Transmit restrict field and others are maintained as is. * No beacon or probe response frame are handled here. Also, introduce the debug message used for mesh CSA purpose. Signed-off-by:
-
Chun-Yeow Yeoh authored
Refactor the channel switch IE parsing to reduce the number of function parameters. Signed-off-by:
-
Felix Fietkau authored
This can be used by a driver to prepare skbs for transmission, which were obtained via functions such as ieee80211_probereq_get or ieee80211_nullfunc_get. This is useful for drivers that want to send those frames directly, but need rate control information to be prepared first. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Marco Porsch authored
This patch fixes errors in the mesh powersave logic which cause that remote peers do not get peer power mode change notifications and mesh peer service periods (MPSPs) got stuck. When closing a peer link, set the (now invalid) peer-specific power mode to 'unknown'. Avoid overhead when local power mode is unchanged. Reliably clear MPSP flags on peering status update. Avoid MPSP flags getting stuck by not requesting a further MPSP ownership if we already are an MPSP owner. Signed-off-by:
Marco Porsch <marco@cozybit.com> Signed-off-by:
-
Seth Forshee authored
6c17b77b ensures that a device's mac80211 queues will remain stopped while offchannel. Since the vif can no longer be offchannel when the queues wake it's not necessary to check for this before waking its netdev queues. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Simon Wunderlich authored
Allow changing to DFS channels if the channel is available for beaconing and userspace controls DFS operation. Channel switch announcement from other stations on DFS channels will be interpreted as radar event. These channels will then be marked as unvailable. Signed-off-by:
Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by:
Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by:
-
Emmanuel Grumbach authored
When the driver requests to move to STATIC or DYNAMIC SMPS, we send an action frame to each associated station and reconfigure the channel context / driver. Of course, non-MIMO stations are ignored. The beacon isn't updated. The association response will include the original capabilities. Stations that associate while in non-OFF SMPS mode will get an action frame right after association to inform them about our current state. Note that we wait until the end of the EAPOL. Sending an action frame before the EAPOL is finished can be an issue for a few clients. Clients aren't likely to send EAPOL frames in MIMO anyway. When the SMPS configuration gets more permissive (e.g. STATIC -> OFF), we don't wake up stations that are asleep We remember that they don't know about the change and send the action frame when they wake up. When the SMPS configuration gets more restrictive (e.g. OFF -> STATIC), we set the TIM bit for every sleeping STA. uAPSD stations might send MIMO until they poll the action frame, but this is for a short period of time. Signed-off-by:
-
- 17 Oct, 2013 1 commit
-
-
Johannes Berg authored
Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The spec mandates that the value of AIFSN is at least 2, and some cards (e.g. Intel with the iwldvm driver) can't transmit when the invalid QoS parameters are actually uploaded to the firmware. Since there's little chance of being able to guess the values that the AP actually meant, disable WMM if such an invalid case is found. Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2 and ECWmin <= ECWmax. Reviewed-by:
Eliad Peller <eliad@wizery.com> Reported-by:
Antonio Quartulli <antonio@meshcoding.com> Signed-off-by:
-
- 15 Oct, 2013 2 commits
-
-
Andrei Otcheretianski authored
Bitrate mask were not respected in transmissions, causing (for example) P2P GO/client to use CCK rates for auth and assoc frames. Fix it by considering the rate mask in __rate_control_send_low(). Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by:
-
Andrei Otcheretianski authored
Transmissions with the IEEE80211_TX_CTL_NO_CCK_RATE flag set (which can come from userspace) were no longer guaranteed to be transmitted with allowed rates since commit 2103dec1 ("mac80211: select and adjust bitrates according to channel mode") due to a missing rate_flags check in that commit. The commit also introduced the need to check the 5/10 MHz flags but accidentally didn't. Fix it by adding the missing check. Signed-off-by:
-
