- 21 5月, 2009 8 次提交
-
-
由 Johannes Berg 提交于
We forgot to cancel all timers in mac80211 when suspending. In particular we forgot to deal with some things that can cause hardware reconfiguration -- while it is down. While at it we go ahead and add a warning in ieee80211_sta_work() if its run while the suspend->resume cycle is in effect. This should not happen and if it does it would indicate there is a bug lurking in either mac80211 or mac80211 drivers. With this now wpa_supplicant doesn't blink when I go to suspend and resume where as before there where issues with some timers running during the suspend->resume cycle. This caused a lot of incorrect assumptions and would at times bring back the device in an incoherent, but mostly recoverable, state. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The channel switch code is currently in the spectrum management file, where arguably it belongs. However, it is for managed mode only and uses the structures for that mode only so having it in a more generic file can be confusing. Additionally, my next patch gets simpler with the code here. When/if we ever implement this for IBSS or mesh then we will need to rework the structures it uses anyway at which point we could move the code back. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
Validate RSC (NL80211_ATTR_KEY_SEQ) length in nl80211/cfg80211 instead of having to do this in all the drivers. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
While the probe request poll is expected to work, it looks like it does not always result in getting a response. The exact reason for this is unclear, but anyway, if we do receive a Beacon frame from our AP, there is no need to disconnect based on the probereq poll. This seems to help keep the connection bit more stable in cases where beacon loss is occurring semi-frequently. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
The STA may drop the very first frame if it happens to be a retried frame. This is because we maintian the last received sequence number per TID for QoS frames and it is initialized to zero through kzalloc during sta_info_alloc and the sequence number of the very first date frame received would be ZERO (as per IEEE 802.11-2007, 7.1.3.4.1). If the frame dropped happens to be an EAP Request Identity(very first frame from the AP), then wpa_supplicnat disconnects the STA and the whole procedure starts again. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This moves the cfg80211 specific stuff to new cfg80211 debugfs entries. Non-mac80211 will also get these entries now. There were only 4 which we take: rts_threshold fragmentation_threshold short_retry_limit long_retry_limit Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
We weren't checking this at all. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This is more consistent with our nl80211 naming convention for HT40-/+. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 5月, 2009 9 次提交
-
-
由 Johannes Berg 提交于
There's this internal wifi_wme_noack_test variable that we use to set the QoS control if set. For one, it is unlikely that it is set. Secondly, if set it needs to influence the IEEE80211_TX_CTL_NO_ACK TX control flag, and finally we should also be able to set it at all, so make it available in debugfs. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Currently mac80211 announces a rate set with no basic rates, this fixes it to use 1/2 or 6/9 Mbit as basic rates by default. Additionally, mac80211 will currently adopt the peer's entire rate set, rather than just the basic rate set; fix that too. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Even when we find an IBSS with the SSID we're looking for, we may not be able to connect to it because it has a key and we don't, or vice versa. Avoid such situations by checking the privacy capability bit. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The time we wait for a probe response after probing an AP due to beacon loss is currently the same as the monitoring interval, 2s. This is far too long, APs should respond to probes within a fraction of that time. To be able to adjust both values, add a new constant IEEE80211_PROBE_WAIT, use it for checking the probe response, and adjust it down to 200ms instead of 2 seconds. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The driver might keep reporting beacon loss until we disassociate -- catch that and don't respond to any subsequent events until the probe is either successful or we disassociate. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
When setting a key with NL80211_CMD_NEW_KEY, we should allow the key sequence number (RSC) to be set in order to allow replay protection to work correctly for group keys. This patch documents this use for nl80211 and adds the couple of missing pieces in nl80211/cfg80211 and mac80211 to support this. In addition, WEXT SIOCSIWENCODEEXT compat processing in cfg80211 is extended to handle the RSC (this was already specified in WEXT, but just not implemented in cfg80211/mac80211). Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
Add a new NL80211_ATTR_CONTROL_PORT flag for NL80211_CMD_ASSOCIATE to allow user space to indicate that it will control the IEEE 802.1X port in station mode. Previously, mac80211 was always marking the port authorized in station mode. This was enough when drop_unencrypted flag was set. However, drop_unencrypted can currently be controlled only with WEXT and the current nl80211 design does not allow fully secure configuration. Fix this by providing a mechanism for user space to control the IEEE 802.1X port in station mode (i.e., do the same that we are already doing in AP mode). Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
It is currently not possible to modify station flags, but that capability would be very useful. This patch introduces a new nl80211 attribute that contains a set/mask for station flags, and updates the internal API (and mac80211) to mirror that. The new attribute is parsed before falling back to the old so that userspace can specify both (if it can) to work on all kernels. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Move key handling wireless extension ioctls from mac80211 to cfg80211 so that all drivers that implement the cfg80211 operations get wext compatibility. Note that this drops the SIOCGIWENCODE ioctl support for getting IW_ENCODE_RESTRICTED/IW_ENCODE_OPEN. This means that iwconfig will no longer report "Security mode:open" or "Security mode:restricted" for mac80211. However, what we displayed there (the authentication algo used) was actually wrong -- linux/wireless.h states that this setting is meant to differentiate between "Refuse non-encoded packets" and "Accept non-encoded packets". (Combined with "cfg80211: fix a couple of bugs with key ioctls". -- JWL) Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 5月, 2009 10 次提交
-
-
由 Johannes Berg 提交于
The address pointed to by mac_addr can be marked as const. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
When we disassociate, we set the channel to non-HT which obviously invalidates any ht_operation_mode setting. But when we then associate with the next AP again, we might still have the ht_operation_mode from the previous AP cached and fail to configure the hardware with the new (but unchanged) operation mode. This patch fixes it by separately tracking whether our cache is valid. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
There really is no need to have a separate struct for a single variable. The fact that it exists is due to the code legacy, but we can remove that now. Very simple. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The call to ieee80211_hw_config() is supposed to apply changes synchronously, so once it returns the parameters are applied to the hardware. Thus, there really is no need to delay the probing by the channel switch time again since the channel switch has already happened once we get to this code. Additionally, there is no need to wait for a NAV update (probe delay) when the channel is passively scanned. Remove that extra time too. This cuts scanning time from over 7 seconds to under 4 on ar9170, which is due to the number of channels scanned and ar9170's switch time being advertised as 135ms (my test now indicates it is about 77ms with the current driver, but the difference might also be due to using a different machine with different USB controllers). Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
When management frame protection (IEEE 802.11w) is used, unprotected Robust Action frames are not allowed prior to key configuration. However, unprotected Deauthentication and Disassociation frames are allowed at that point, but not after key configuration. Make ieee80211_drop_unencrypted() handle the special cases for MFP by separating the basic Data frame case from Management frame processing and handle the Management frames only if MFP has been negotiated. In addition, do not use sdata->drop_unencrypted for Management frames since the decision on whether to accept the frame depends on the key being configured. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
When using nl80211, we do not have a mechanism to set sdata->drop_unencrypted. Currently, this breaks code that is supposed to drop unencrypted frames when protection is expected since ieee80211_rx_h_decrypt() is optimized to not set rx->key when the frame is not protected. This patch modifies ieee80211_rx_h_decrypt() to set rx->key for all frames and only skip decryption if the frame is not protected. This allows ieee80211_drop_unencrypted() to correctly drop frames even if drop_unencrypted is not set. The changes here are not enough to handle all cases, though. Additional patches will be needed to implement proper IEEE 802.1X PAE for station mode (currently, this is only used for AP mode) and some additional rules are needed for MFP to drop unprotected Robust Action frames prior to having PTK and IGTK configured. In theory, the unprotected frames could and should be dropped in ieee80211_rx_h_decrypt(). However, due to the special case with EAPOL frames that have to be allowed to be received unprotected even when keys are set, it is simpler to only set rx->key and allow the ieee80211_frame_allowed() function to handle the actual dropping of data frames after 802.11->802.3 header conversion. In addition, unprotected robust management frames are dropped before they are processed. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
We've never really cared about the default QoS (WMM) values, but we really should if the AP doesn't send any. This patch makes mac80211 use the default values according to 802.11-2007, and additionally syncs the default values when we disassociate so whatever the last AP said gets "unconfigured". Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
When a software scan starts, it first sets sw_scanning, but leaves the scan_channel "unset" (it currently actually gets initialised to a default). Now, when something else tries to (re)configure the hardware in the window between these two events (after sw_scanning = true, but before scan_channel is set), the current code switches to the (unset!) scan_channel. This causes trouble, especially when switching bands and sending frames on the wrong channel. To work around this, leave scan_channel initialised to NULL and use it to determine whether or not a switch to a different channel should occur (and also use the same condition to check whether to adjust power for scan or not). Additionally, avoid reconfiguring the hardware completely when recalculating idle resulted in no changes, this was the problem that originally led us to discover the race condition in the first place, which was helpfully bisected by Pavel. This part of the patch should not be necessary with the other fixes, but not calling the ieee80211_hw_config function when we know it to be unnecessary is certainly a correct thing to do. Unfortunately, this patch cannot and does not fix the race condition completely, but due to the way the scan code is structured it makes the particular problem Pavel discovered (race while changing channel at the same time as transmitting frames) go away. To fix it completely, more work especially with locking configuration is needed. Bisected-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
NL80211_CMD_ASSOCIATE request must be able to indicate whether management frame protection (IEEE 802.11w) is being used. mac80211 was able to use MFP in client mode only with WEXT, but the new NL80211_ATTR_USE_MFP attribute will allow this to be done with nl80211, too. Since we are currently using nl80211 for MFP only with drivers that use user space SME, only MFP disabled and required values are used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can be extended with MFP optional in the future, if that is needed with some drivers (e.g., if the RSN IE is generated by the driver). Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
"There is another problem with this piece of code. The sband will be NULL after second iteration on single band device and cause null pointer dereference. Everything is working with dual band card. Sorry, but i don't know how to explain this clearly in English. I have looked on the second patch for pid algorithm and found similar bug." Reported-by: NKarol Szuster <qflon@o2.pl> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 07 5月, 2009 13 次提交
-
-
由 Jouni Malinen 提交于
We are currently processing block ack reordering as a separate task before all other RX handlers. In theory, this is wrong since this step should be done only after duplicate removal (see Figure 6-1 in IEEE 802.11n). However, moving this needs some work and the current situation is not too bad. Add a comment here so that this small detail does not get forgotten and who knows, maybe someone has some extra time to take a look at cleaning this up. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
This patch allows skbs to be released from the RX reorder buffer in case they have been there for an unexpectedly long time without us having received the missing frames before them. Previously, these frames were only released when the reorder window moved and that could take very long time unless new frames were received constantly (e.g., TCP connections could be killed more or less indefinitely). This situation should not happen very frequently, but it looks like there are some scenarious that trigger it for some reason. As such, this should be considered mostly a workaround to speed up recovery from unexpected siutation that could result in connections hanging for long periods of time. The changes here will only check for timeout situation when adding new RX frames to the reorder buffer. It does not handle all possible cases, but seems to help for most cases that could result from common network usage (e.g., TCP retrying at least couple of times). For more completely coverage, a timer could be used to periodically check whether there are any frames remaining in the reorder buffer if no new frames are received. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
No need to duplicate the same code in two places (and that would be three after the followup patch). Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
net/mac80211/mlme.c:2079:28: warning: symbol 'ssid_len' shadows an earlier one net/mac80211/mlme.c:2022:12: originally declared here ssid_len is already being declared and checked above so there is no need for it again. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
It's not very helpful to see, in iwconfig, the current frequency the card is tuned to if that frequency is currently somewhere across the board because we're scanning. Since we keep track of the frequency the user wants, display that instead. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
When we aren't doing anything in mac80211, we can turn off much of the hardware, depending on the driver/hw. Not doing anything, aka being idle, means: * no monitor interfaces * no AP/mesh/wds interfaces * any station interfaces are in DISABLED state * any IBSS interfaces aren't trying to be in a network * we aren't trying to scan By creating a new function that verifies these conditions and calling it at strategic points where the states of those conditions change, we can easily make mac80211 tell the driver when we are idle to save power. Additionally, this fixes a small quirk where a recalculated powersave state is passed to the driver even if the hardware is about to stopped completely. This patch intentionally doesn't touch radio_enabled because that is currently implemented to be a soft rfkill which is inappropriate here when we need to be able to wake up with low latency. One thing I'm not entirely sure about is this: phy0: device no longer idle - in use wlan0: direct probe to AP 00:11:24:91:07:4d try 1 wlan0 direct probe responded wlan0: authenticate with AP 00:11:24:91:07:4d wlan0: authenticated > phy0: device now idle > phy0: device no longer idle - in use wlan0: associate with AP 00:11:24:91:07:4d wlan0: RX AssocResp from 00:11:24:91:07:4d (capab=0x401 status=0 aid=1) wlan0: associated Is it appropriate to go into idle state for a short time when we have just authenticated, but not associated yet? This happens only with the userspace SME, because we cannot really know how long it will wait before asking us to associate. Would going idle after a short timeout be more appropriate? We may need to revisit this, depending on what happens. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gábor Stefanik 提交于
To deter future rate scaling algorithm writers from requesting NO_ACK packets to be retried, throw a WARN_ON_ONCE if the algorithm hands us a try count over 1 for NO_ACK packet. Signed-off-by: NGábor Stefanik <netrolller.3d@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gábor Stefanik 提交于
Make PID check for IEEE80211_TX_CTL_NO_ACK instead of is_multicast_ether_addr when determining whether to use the lowest rate, and set the retry count to 0 (total try count = 1) if IEEE80211_TX_CTL_NO_ACK is set. Signed-off-by: NGábor Stefanik <netrolller.3d@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gábor Stefanik 提交于
Make the retry count zero (total try count = 1) for frames with IEEE80211_TX_CTL_NO_ACK set. Also remove the check for is_multicast_ether_addr in use_low_rate, which is redundant because all multicasts have IEEE80211_TX_CTL_NO_ACK set. Signed-off-by: NGábor Stefanik <netrolller.3d@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Due to the use of a _REQ_DIRECT_PROBE bit, which is unnecessary (and I wonder why it was done that way), an interesting situation can arise: 1) we try to probe an access point 2) the AP doesn't response in time 3) we tell userspace that we gave up 4) the AP suddenly responds 5) we auth/assoc with the AP I've seen 4) happen in testing with hostapd SIGSTOPped, and when SIGCONTinued it processes the probe requests that came in and send responses. But 5) is not supposed to happen after we tell everybody we've given up on the AP. To fix this, remove the _REQ_DIRECT_PROBE request bit, and process probe responses when we're in the relevant MLME state, namely IEEE80211_STA_MLME_DIRECT_PROBE. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
If the direct probe times out, we need to send the authentication timeout event to notify SME in the same way as we notify on timeout with authentication frames since the direct probe is run as part of the authentication attempt. Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
In order to later add tracing or verifications to the driver calls mac80211 makes, this patch adds static inline wrappers for all operations. All calls are now written as drv_<op>(local, ...); instead of local->ops-><op>(&local->hw, ...); Where necessary, the wrappers also do existence checking and return default values as appropriate. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The config_interface method is a little strange, it contains the BSSID and beacon updates, while bss_info_changed contains most other BSS information for each interface. This patch removes config_interface and rolls all the information it previously passed to drivers into bss_info_changed. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-