- 11 Sep, 2008 28 commits
-
-
Johannes Berg authored
This reorders the mlme code a bit so we don't need all the forward function declarations. It also removes the ERP_INFO_USE_PROTECTION define that is unused, but otherwise contains no real changes. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
During testing of the disassociation fixes, Tomas noticed that it was possible to run into a situation where you'd suddenly get a few "wlan0: dropped frame to <AP> (unauthorized port)" messages and I found this to be due to the AP's sta_info having been removed but netif_carrier_off not having removed/stopped traffic yet. To avoid that, stop the queue for the interface (and avoid bringing them up when another vif scans when they weren't up.) Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch moves disassociation code from ieee80211_set_associated to ieee80211_set_disassoc. To reduce code duplication, it introduces the ieee80211_sta_send_apinfo function. Additionally, it fixes a lapse where BSS_CHANGED_HT wasn't set when notifying the driver of changes due to disassociation. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch makes the MLME cleanly disassociate from the current BSS when leaving it for a new one. This is not just nicer to the old AP (we're leaving it, might as well tell it!) but also required for some drivers that keep track of the station we're associated with, they'd get confused because they'd think we are associated with two APs. Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch restructure the flow of disassociation and deauthentication flows to be consistent under all circumstances. It ensures that BA session is treated down before deauthentication or disassociation, adds the removal of the obsolete sta form station table and fixes a related bug (sta_info_destroy without sta_info_unlink) in ieee80211_associated() and reduce some code duplication Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
This reverts: b93ce437 rt2x00: Fix the beacon length bug The workaround is no longer required since it has been correctly fixed in rt2x00usb now. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Since IE parsing is required for the mlme and mesh code, it's not a static function anyway, and it's much better to have it in util rather than the overly large mlme.c Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This says chan_switch.action_code but really means measurement.action_code, of course the actual offset in the frame is the same, it's just harder to understand this way. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The action frame length checks are one too small, there's not just an action code as the comment makes you believe, there's a category code too, and the category code is required in each action frame (hence part of IEEE80211_MIN_ACTION_SIZE). Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When we receive information about a BSS we check at some point whether or not we think we're allowed to use the channel it is on, but we do that fairly late. I don't think we should do it that late, so do it earlier to avoid doing IBSS/mesh stuff on that channel and then getting confused because it's disabled. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The conf_tx callback currently needs to be atomic, this requirement is just because it can be called from scanning. This rearranges it slightly to only update while not scanning (which is fine, we'll be getting beacons when associated) and thus removes the atomic requirement. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The if itself doesn't need to be protected, so move in the RCU locking to avoid doing anything at all when the condition isn't true. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ehud Gavron authored
Recent changes in the specifications have improved the performance of the BCM4306/2 devices that use b43legacy as the driver. These "errors" in the specs have been present from the very first implementation of bcm43xx. Signed-off-by: Ehud Gavron <gavron@wetwork.net> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@kernel.org> [2.6.26], [2.6.25] Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
We don't need the workqueue anymore, as we can now sleep in the callback. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
It causes compile errors on m68k and it is not needed. Remove it. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This fixes the initialization of the default QoS parameters. This got broken by "wireless: fix warnings from QoS patch". Reported-by: Lorenzo Nava Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch brings the 5GHz Phy in any prism54 devices (of course, only those who have one) to life. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
I hope this patch is enough to cover at least the basic requirements of IEEE 802.11h's TPC. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
The firmware can provide lots of useful statistics about noise floor, mac time and lots of numbers about successful transfers and dropped frames. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch adds new filters settings to make the card more useful in monitor mode. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
tcpdump: 02:15:42.874518 61112184us tsft 48.0 Mb/s 2437 MHz (0x0480) antenna 1 [0x0000000e] CF +QoS Data IV 02:15:42.874557 >>>4356079526us<<< tsft 24.0 Mb/s 2437 MHz (0x0480) antenna 1 [0x0000000e] Acknowledgment 02:15:42.976844 61214513us tsft 1.0 Mb/s 2437 MHz (0x0480) antenna 0 [0x0000000e] Beacon as one can see on the huge jump, it's very plausible that firmware does not report the full 64-bit mac time, just the lower 32bit and some kinds of flags... Therefore if we want a useful timestamp we have to emulate the high bits. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
The patch fixes compile warning for ‘iwl4965_hw_channel_switch’ defined but not used. Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Emmanuel Grumbach authored
This patch cleans up iwlwifi by removing uneeded declarations and removing uneeded symbol export reducing the namespace pollution. It also fixes some typos in comments. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grumbach, Emmanuel authored
This patch makes usage of the results from disconnected antenna alg to know how many antennas are connected. It also synchronizes between the chain noise alg and the W/A that disables power management during association. All the antennas must be enables during the chain noise algorithm. Hence, power management is restored only after the completion of the algorithm. In the future, we will need to update the AP that we don't support MIMO if there is only one antenna connected. We also need to update the rate scaling algorithm. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ron Rindjunsky authored
This patch renames iwl_priv.ps_mode for clearer iwl_priv.current_ht_config.sm_ps (spatial multiplexing power save). Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch follows 11n spec naming more rigorously replacing MIMO_PS with SM_PS (Spatial Multiplexing Power Save). (Originally submitted as 4 patches, "mac80211: change MIMO_PS to SM_PS", "iwlwifi: change MIMO_PS to SM_PS", "ath9k: change MIMO_PS to SM_PS", and "iwlwifi: remove double definition of SM PS". -- JWL) Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
David S. Miller authored
Johannes Berg reported that occaisionally, bringing an interface down or unregistering it would hang for up to 30 seconds. Using debugging output he provided it became clear that ICMP6 routes were the culprit. The problem is that ICMP6 routes live in their own world totally separate from normal ipv6 routes. So there are all kinds of special cases throughout the ipv6 code to handle this. While we should really try to unify all of this stuff somehow, for the time being let's fix this by purging the ICMP6 routes that match the device in question during rt6_ifdown(). Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 10 Sep, 2008 4 commits
-
-
David S. Miller authored
Otherwise entries stay on the GC todo list forever, even after we free them. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
Now that we save states within a walk we need synchronisation so that the list the saved state is on doesn't disappear from under us. As it stands this is done by keeping the state on the list which is bad because it gets in the way of the management of the state life-cycle. An alternative is to make our own pseudo-RCU system where we use counters to indicate which state can't be freed immediately as it may be referenced by an ongoing walk when that resumes. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
-
David S. Miller authored
-
- 09 Sep, 2008 8 commits
-
-
-
David S. Miller authored
The previous default behavior is definitely the least user friendly. Hanging there forever just because the keying daemon is wedged or the refreshing of the policy can't move forward is anti-social to say the least. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Neil Horman authored
This fixes kernel bugzilla 11469: "TUN with 1024 neighbours: ip6_dst_lookup_tail NULL crash" dst->neighbour is not necessarily hooked up at this point in the processing path, so blindly dereferencing it is the wrong thing to do. This NULL check exists in other similar paths and this case was just an oversight. Also fix the completely wrong and confusing indentation here while we're at it. Based upon a patch by Evgeniy Polyakov. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
The commit commit 4c563f76 ("[XFRM]: Speed up xfrm_policy and xfrm_state walking") inadvertently removed larval states and socket policies from netlink dumps. This patch restores them. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
-
Yitchak Gertner authored
When EEH detects an i/o error it resets the device thus it cannot be accessed. In this case the driver needs to unload its interface only with OS, kernel and network stack but not with the device. After successful recovery, the driver can load normally. Signed-off-by: Yitchak Gertner <gertner@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://eden-feed.erg.abdn.ac.uk/dccp_expGerrit Renker authored
as it accentally contained the wrong set of patches. These will be submitted separately. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
-