- Sep 01, 2010
-
-
Helmut Schaa authored
Variables containing queue ids are called qid everywhere else, hence rename the queue field in txentry_desc to qid as well. Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
According to the hardware documentation, the MIC failure bit is only valid if the frame was decrypted using a valid TKIP key and is not a fragment. In some setups I've seen hardware-reported MIC failures on an AP that was configured for CCMP only, so it's clear that additional checks are necessary. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by:
-
Julia Lawall authored
The same expression is tested twice and the result is the same each time. The sematic match that finds this problem is as follows: (http://coccinelle.lip6.fr/ ) // <smpl> @expression@ expression E; @@ ( * E || ... || E | * E && ... && E ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Denis 'GNUtoo' Carikli authored
This patch was adapted from 06f7bc7d (from linus's linux-2.6 tree of kernel.org) here's the original message: The queue stopping/waking functionality was broken in a way that could cause huge latencies in TX transfers and even cause the TX to stall in the right circumstances. Correct these problems. Signed-off-by:
Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Acked-by:
Kalle Valo <kvalo@adurom.com> Signed-off-by:
-
Jouni Malinen authored
The signal strength value in a single RX frame is not that reliable, so it is better to delay start of CQM events until there is a real average signal strength from more than a single Beacon frame available. Signed-off-by:
Jouni Malinen <j@w1.fi> Signed-off-by:
-
Jouni Malinen authored
The ave_beacon_signal value uses 1/16 dB unit and as such, must be initialized with the signal level of the first Beacon frame multiplied by 16. This fixes an issue where the initial CQM events are reported incorrectly with a burst of events while the running average approaches the correct value after the incorrect initialization. This could cause user space -based roaming decision process to get quite confused at the moment when we would like to go through authentication and DHCP. Cc: stable@kernel.org Signed-off-by:
-
John W. Linville authored
Merge branch 'wireless-next-2.6' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6
-
- Aug 28, 2010
-
-
Johannes Berg authored
Somebody noticed this problem, and I outlined to them how to fix it, but haven't heard back from them. So while I was adding the state field I figured I could use it to fix it. The problem, as I understand it, is that when we go offchannel while the driver has a queue stopped, the driver will likely start draining the queue and then enable it while offchannel. This in turn will enable the interface queue, and that leads to transmitting data frames on the wrong channel. Fix this by keeping track of offchannel status per interface, and not enabling the interface queues on interfaces that are offchannel when the driver enables a queue. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Add the trivial support for runtime interface type changes to mac80211_hwsim for testing. Signed-off-by:
-
Johannes Berg authored
Add support to mac80211 for changing the interface type even when the interface is UP, if the driver supports it. To achieve this * add a new driver callback for switching, * split some of the interface up/down code out into new functions (do_open/do_stop), and * maintain an own __SDATA_RUNNING bit that will not be set during interface type, so that any other code doesn't use the interface. Signed-off-by:
-
Johannes Berg authored
Split the concurrent virtual interface checks into a new function that can be used to check for any given new interface type. Signed-off-by:
-
Johannes Berg authored
The libertas_tf special code for zero addresses is a bit too complex, it compares against a stack value instead of using is_zero_ether_addr() and tries to update all interfaces even if just the one that's being brought up needs to be changed. Additionally, the repeated check for a valid MAC address need only be done if we actually changed it on the fly. Signed-off-by:
-
Johannes Berg authored
Since the introduction of ieee80211_sdata_running(), some new code was introduced that uses netif_running() instead. Switch all these instances over. Signed-off-by:
-
Johannes Berg authored
There's a lot of redundant code in mac80211's interface cleanup/down, for example freeing AP beacons is done both when the interface is set DOWN as well as when it is torn down, of which only the former has any effect. Also, a bunch of things should be closer to where they matter, like the MLME timers that we should cancel when disassociating, rather than only when the interface is set DOWN. Clean up all this code. Signed-off-by:
-
Johannes Berg authored
There are subqueue helpers so that we don't need to get the TX queue and then wake/stop it, use those helpers. Signed-off-by:
-
Johannes Berg authored
Some vendor specified mechanisms for 802.1X-style functionality use a different protocol than EAP (even if EAP is vendor-extensible). Support this in mac80211 via the cfg80211 API for it. Signed-off-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by:
-
Johannes Berg authored
Some vendor specified mechanisms for 802.1X-style functionality use a different protocol than EAP (even if EAP is vendor-extensible). Allow setting the ethertype for the protocol when a driver has support for this. The default if unspecified is EAP, of course. Note: This is suitable only for station mode, not for AP implementation. Signed-off-by: -
Johannes Berg authored
Allow drivers to specify their own set of cipher suites to advertise vendor-specific ciphers. The driver is then required to implement hardware crypto offload for it. Signed-off-by:
-
Johannes Berg authored
cfg80211 currently rejects all cipher suites it doesn't know about for key length checking purposes. This can lead to inconsistencies when a driver advertises an algorithm that cfg80211 doesn't know about. Remove this rejection so drivers can specify any algorithm they like. Signed-off-by:
-
Johannes Berg authored
My previous patch erroneously included an !A line (for some checking I am working on) that isn't yet supported by the docbook tools, so remove it. Signed-off-by:
-
Rajkumar Manoharan authored
While scanning, ANI is triggered unnecessarily where sta is in unassociated state. And cancelling ani work in ath9k_htc_stop is not required. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
-
Johannes Berg authored
With the scan callback now being callable from any context, these unlocks/locks can go away. This makes the code easier to understand, since callers of these functions must no longer be aware that the mutex may be dropped. As Stanislaw is working on iwlwifi scanning, I didn't change it to take advantage of the new mac80211 semantics. Signed-off-by:
-
Johannes Berg authored
The ieee80211_scan_completed() function was a frequent source of potential deadlocks, since it is called by drivers but may call back into drivers, so drivers had to make sure to call it without any locks held, which frequently lead to more complex code in drivers. Avoid that problem by allowing the function to be called in any context, and queueing the actual work it does. Also update the documentation for it to indicate this. Signed-off-by:
-
Johannes Berg authored
Since cfg80211 manages the BSS list completely, this define hasn't been used for a long time and will never be used again. Signed-off-by:
-
Vivek Natarajan authored
All major Atheros customers require the led to be in continuous ON state rather than the blinking pattern. Signed-off-by:
Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by:
-
Bob Copeland authored
If the symbol offset is 46, it will be counted in both the third and fourth bytes of the mask, and in this case the shift will be negative which can pollute high order bits in the mask. This may negatively impact OFDM symbol detection. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Dan Carpenter authored
There was a small misordering here. In the original code, if we were to go to err_free_ah then it wouldn't free the irq. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Johannes Berg authored
We're now ready to start using multiple contexts. We do this by keeping track of the valid interface types per context (exclusive [ibss] and normal) and checking which context is "free" when a new interface is added. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Johannes Berg authored
It is necessary that the PAN context always use the same beacon interval as the BSS context unless it is in dual-station mode, ie. the PAN context is a station as well, so implement that. Signed-off-by:
-
Johannes Berg authored
The PAN context requires also getting RXON timing when we send an unassociated RXON in some cases. Signed-off-by:
-
Johannes Berg authored
Sometimes we need to send RXON timing even when we don't have a virtual interface yet, so pass the context and allow passing one without a virtual interface pointer. Signed-off-by:
-
Johannes Berg authored
In order for the microcode to be able to handle multiple interfaces, we need to give it the PAN parameters that state how to allocate the time between the two interfaces. Do this, and update it wherever necessary. Signed-off-by:
-
Johannes Berg authored
Newer AGN microcode requires know the beacon before starting the AP so that it can start beaconing right away. Implement that. Signed-off-by:
-
Johannes Berg authored
The PAN functionality requires us to send the timing including a valid DTIM period to the microcode before associating, so request this data from mac80211 and send it to the device. Signed-off-by:
-
Johannes Berg authored
Frames for different contexts need to be put on different queues, and multicast after DTIM frames have a special queue yet which also depends on the context, so put all this into the context. Signed-off-by:
-
Johannes Berg authored
Since we have the beacon context now, we no longer need to rely on iw_mode but can check the beacon context interface's type. However, that check must be in the work item instead due to locking constraints (mutex must be held when dereferencing beacon_ctx pointer). Signed-off-by:
-
Johannes Berg authored
Detect whether or not the ucode is PAN capable and adjust the valid contexts accordingly. To be able to do this, add the PAN context to the array as well. Signed-off-by:
-
Johannes Berg authored
Define the new host commands and notifications REPLY_WIPAN_PARAMS REPLY_WIPAN_RXON REPLY_WIPAN_RXON_TIMING REPLY_WIPAN_RXON_ASSOC REPLY_WIPAN_QOS_PARAM REPLY_WIPAN_WEPKEY REPLY_WIPAN_P2P_CHANNEL_SWITCH REPLY_WIPAN_NOA_NOTIFICATION and their corresponding structures along with the PAN station flag, the PAN AP sta ID and new dev types for the second context. Signed-off-by:
-
Johannes Berg authored
Only one context can be beaconing at a time, but we need to track which one. Introduce a new variable priv->beacon_ctx to do that. Signed-off-by:
-
Johannes Berg authored
A lot of HT configuration semantically belongs into the context, even if right now it will never be different between contexts. Move it so we're better prepared for future changes in mac80211. Signed-off-by:
-
