- 17 10月, 2012 7 次提交
-
-
由 Mahesh Palivela 提交于
Save the AP's VHT capabilities (in managed mode) and make them available to the driver in the station information. Unlike HT capabilities, they aren't restricted to the common capabilities, so drivers must be aware of their own capabilities. Signed-off-by: NMahesh Palivela <maheshp@posedge.com> [fix endian conversion bug ...] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Mahesh Palivela 提交于
Rename struct ieee80211_vht_capabilities to ieee80211_vht_cap and renamed its member vht_capabilities_info to vht_cap_info. Signed-off-by: NMahesh Palivela <maheshp@posedge.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Jouni Malinen 提交于
SAE uses two rounds of Authentication frames and both rounds require considerable calculation to be done. This commit extends the existing station mode authentication request to allow more control for user space programs to build the SAE fields and to run the authentication step ones. Only the second round with authentication transaction sequence 2 will result in moving to authenticated state. Signed-off-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Jouni Malinen 提交于
This is useful when debugging authentication process issues. Signed-off-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Jouni Malinen 提交于
Non-zero status code may be needed for Authentication frames, e.g., when using SAE. Signed-off-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 9月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
When we disassociate, it's not really useful to send delBA action frames since we're going to send disassoc/deauth anyway, so change that. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 14 9月, 2012 2 次提交
-
-
由 Johannes Berg 提交于
Make the function acquire the necessary mutex itself to simplify the callers. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Currently, mac80211 uses the power constraint IE, and reduces the regulatory max TX power by it. This can cause issues if the AP is advertising a large power constraint value matching a high TX power in its country IE, for example in this case: ... Country: US Environment: Indoor/Outdoor ... Channels [157 - 157] @ 30 dBm ... Power constraint: 13 dB ... What happened here is that our local regulatory TX power is 15 dBm, and gets reduced by 13 dB so we end up with only 2 dBm effective TX power, which is way too low. Instead, handle the country IE/power constraint IE combined and restrict our TX power to the max of the regulatory power and the maximum power advertised by the AP, in this case 17 dBm (= 30 dBm - 13 dB). Also print a message when this happens to let the user know and help us debug issues with it. Reported-by: NCarl A. Cook <CACook@quantum-equities.com> Tested-by: NCarl A. Cook <CACook@quantum-equities.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 07 9月, 2012 1 次提交
-
-
由 Antonio Quartulli 提交于
Move ieee80211_send_deauth_disassoc() to util.c to make it available for the rest of the mac80211 code. Signed-off-by: NAntonio Quartulli <ordex@autistici.org> [reword commit message] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 06 9月, 2012 2 次提交
-
-
由 Johannes Berg 提交于
The power constraint IE is always a single byte so check the size when parsing instead of later. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Disconnect from the AP if channel switching in the driver failed or if the new channel is unavailable. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 04 9月, 2012 1 次提交
-
-
由 Eliad Peller 提交于
ifmgd->bssid wasn't cleared properly in some auth/assoc failure cases, causing mac80211 and the low-level driver to go out of sync. Clear ifmgd->bssid on failure, and notify the driver. Cc: stable@kernel.org # 3.4+ Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 20 8月, 2012 6 次提交
-
-
由 Johannes Berg 提交于
In multi-channel scenarios, the channel that we will transmit a probe request on isn't always the current channel (which will be NULL anyway) but will instead be the channel that the AP is on. Pass the channel to the ieee80211_send_probe_req() function so it can be used in the different scenarios. The scan code continues to pass the current channel, of course. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to declare the function in the header file since it's only used in a single place, so make it static. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The channel switch IE has a fixed size, so we can discard it in parsing if it's not the right size and use the right struct pointer. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The time until the channel switch is in TU, not in milliseconds, so use TU_TO_EXP_TIME() to correctly program the timer. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Clean up the CSA handling code by moving some of it out of the if and using a C99 initializer for the struct passed to the driver method. While at it, also add a comment that we should wait for a beacon after switching the channel. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to copy the BSSID just to print it, remove the unnecessary variable. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 8月, 2012 2 次提交
-
-
由 Johannes Berg 提交于
There's a corner case that can happen when we suspend with a timer running, then resume and disconnect. If we connect again, suspend and resume we might start timers that shouldn't be running. Reset the timer flags to avoid this. This affects both mesh and managed modes. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When associating anew, the old station MLME flags should be cleared. The only exception is the 40 MHz disable flag as it might have been set while the channel was set in a previous authentication attempt so it needs to be kept intact. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 31 7月, 2012 9 次提交
-
-
由 Johannes Berg 提交于
When sending probe requests, e.g. during software scanning, these will go out on the *current* channel, so their IEs need to be built from the current channel. At other times, e.g. for beacons or probe request templates, the IEs will be used on the *operating* channel and using the current channel instead might result in errors. Add the appropriate parameters to respect the difference. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Using hw.conf.channel is wrong as it could be the temporary channel if any function like the beacon get function is called while scanning or during other temporary out-of-channel activities. Use oper_channel instead. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to set up the channel during auth and again during assoc, just do it once. Currently this doesn't result in any changes since calling hw_config() with an unchanged channel will return early, but with the channel context work this has an impact on channel context assignment. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In ieee80211_prep_connection(), the station (if not NULL) is the new station (representing the AP) that needs to be added. Rename the variable to "new_sta" to clarify this. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
If HT/VHT isn't supported by us we shouldn't print a message that we disabled it, do that only if the AP didn't support WMM and we therefore disable it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Eliad Peller 提交于
Currently, ps mode is indicated per device (rather than per interface), which doesn't make a lot of sense. Moreover, there are subtle bugs caused by the inability to indicate ps change along with other changes (e.g. when the AP deauth us, we'd like to indicate CHANGED_PS | CHANGED_ASSOC, as changing PS before notifying about disassociation will result in null-packets being sent (if IEEE80211_HW_SUPPORTS_DYNAMIC_PS) while the sta is already disconnected.) Keep the current per-device notifications, and add parallel per-vif notifications. In order to keep it simple, the per-device ps and the per-vif ps are orthogonal - the per-vif ps configuration is determined only by the user configuration (enable/disable) and the connection state, and is not affected by other vifs state and (temporary) dynamic_ps/offchannel operations (unlike per-device ps). Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
This doesn't make any sense since we are expected to be on the medium or at least to Tx only when we are on the right channel and the AP/GO can hear us. Move the call to mgd_prepare_tx() for deauth to be only done in case we're sending a deauth while not associated. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
If the HW is monitoring connection loss (as advertised by IEEE80211_HW_CONNECTION_MONITOR) but not filtering beacons (IEEE80211_VIF_BEACON_FILTER) then mac80211 will still start the beacon loss timer and if a few beacons are lost, e.g. due to scanning, drop the connection. If the hardware doesn't advertise connection monitoring, then it won't drop the connection right away but probe the AP, which is intended, but due to the logic in the timer when connection monitoring is done it assumes the connection was actually lost. Fix this problem by not starting the timer when the HW does connection monitoring. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Mahesh Palivela 提交于
Insert VHT IEs into association frames to allow mac80211 to connect as a VHT client. Signed-off-by: NMahesh Palivela <maheshp@posedge.com> [clarify commit message] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 17 7月, 2012 1 次提交
-
-
由 Eliad Peller 提交于
on disassoc, ieee80211_set_disassoc() goes out of PS before indicating BSS_CHANGED_ASSOC (not sure why this is needed, but some drivers might count on the current behavior). However, it does it after sending the disassoc frame, which results in null-data frame being sent (in order to go out of ps) after we were already sent the disassoc, which is invalid. Fix it by going out of ps before sending the disassoc. Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 7月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
Some drivers (iwlegacy, iwlwifi and rt2x00) today use the bss_conf.last_tsf value. By itself though that value is completely worthless since it may be ancient. What really is needed is synchronisation between some device time and the TSF. To clarify this, rename bss_conf.last_tsf to sync_tsf and add sync_device_ts which is obtained from rx_status which gets a new field device_timestamp for this purpose. This is intentionally not using the mactime field since that is used for other things and in IBSS is expected to sync with the IBSS's TSF which isn't necessarily true for the device timestamp. Also, since we have the information and it's useful even before the connection has been established, give all the timing details to the driver before authenticating. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 10 7月, 2012 1 次提交
-
-
由 Eliad Peller 提交于
If association failed due to internal error (e.g. no supported rates IE), we call ieee80211_destroy_assoc_data() with assoc=true, while we actually reject the association. This results in the BSSID not being zeroed out. After passing assoc=false, we no longer have to call sta_info_destroy_addr() explicitly. While on it, move the "associated" message after the assoc_success check. Cc: stable@vger.kernel.org [3.4+] Signed-off-by: NEliad Peller <eliad@wizery.com> Reviewed-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 7月, 2012 2 次提交
-
-
由 Johannes Berg 提交于
ieee80211_mlme_notify_scan_completed() iterates all interfaces and doesn't need to assign anything to the sdata variable before the loop. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When the AC parameters change, drivers might rely on getting a bss_info_changed notification with BSS_CHANGED_QOS in addition to the conf_tx call. Always call the function when userspace updates are made (in AP/GO modes) and also set the change flag when updates were made by the AP (in managed mode.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 03 7月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
Some drivers require setup before being able to send management frames in managed mode, in particular in multi-channel cases. Introduce API to allow the drivers to do such setup while being able to sleep waiting for the setup to finish in the device. This isn't possible inside the TX call since that can't sleep. A future patch may also restructure the TX retry to wait for the driver to report the frame status, as suggested by Arik in http://mid.gmane.org/CA+XVXffKSEL6ZQPQ98x-zO-NL2=TNF1uN==mprRyUmAaRn254g@mail.gmail.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 7月, 2012 1 次提交
-
-
由 Eliad Peller 提交于
Drivers might need getting the probe request (e.g. in order to extract the ssid) even during auth/assoc. Make ieee80211_ap_probereq_get() support it by considering auth_data/assoc_data as well. Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 28 6月, 2012 2 次提交
-
-
由 Eliad Peller 提交于
beacon_ies is needed only in order to extract the dtim period. However, even if it's missing we can still enter ps with dtim=1 (which also happens if the TIM ie is invalid). Most drivers don't use conf.max_sleep_period/ps_dtim_period anyway, and this check prevents them from entering ps if they don't have beacon (but only probe response), even though the beacon is not needed at all. Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Eliad Peller 提交于
On deauth/disassoc we tear down all BA sessions. These DELBA packets are sent on the appropriate TID, while deauth/disassoc is always sent on VO. This sometimes ends with the DELBA being sent after the deauth was already sent. Fix it by flushing all the pending frames before sending deauth/disassoc. Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-