aboutsummaryrefslogtreecommitdiffstats
path: root/net/mac80211/tx.c
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: enable assoc check for mesh interfacesBob Copeland2015-10-131-3/+0
| | | | | | | | | | | | | | | | | | | | commit 3633ebebab2bbe88124388b7620442315c968e8f upstream. We already set a station to be associated when peering completes, both in user space and in the kernel. Thus we should always have an associated sta before sending data frames to that station. Failure to check assoc state can cause crashes in the lower-level driver due to transmitting unicast data frames before driver sta structures (e.g. ampdu state in ath9k) are initialized. This occurred when forwarding in the presence of fixed mesh paths: frames were transmitted to stations with whom we hadn't yet completed peering. Reported-by: Alexis Green <agreen@cococorp.com> Tested-by: Jesse Jones <jjones@cococorp.com> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* mac80211: Send EAPOL frames at lowest rateJouni Malinen2015-05-091-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 9c1c98a3bb7b7593b60264b9a07e001e68b46697 upstream. The current minstrel_ht rate control behavior is somewhat optimistic in trying to find optimum TX rate. While this is usually fine for normal Data frames, there are cases where a more conservative set of retry parameters would be beneficial to make the connection more robust. EAPOL frames are critical to the authentication and especially the EAPOL-Key message 4/4 (the last message in the 4-way handshake) is important to get through to the AP. If that message is lost, the only recovery mechanism in many cases is to reassociate with the AP and start from scratch. This can often be avoided by trying to send the frame with more conservative rate and/or with more link layer retries. In most cases, minstrel_ht is currently using the initial EAPOL-Key frames for probing higher rates and this results in only five link layer transmission attempts (one at high(ish) MCS and four at MCS0). While this works with most APs, it looks like there are some deployed APs that may have issues with the EAPOL frames using HT MCS immediately after association. Similarly, there may be issues in cases where the signal strength or radio environment is not good enough to be able to get frames through even at couple of MCS 0 tries. The best approach for this would likely to be to reduce the TX rate for the last rate (3rd rate parameter in the set) to a low basic rate (say, 6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly requires some more effort. For now, we can start with a simple one-liner that forces the minimum rate to be used for EAPOL frames similarly how the TX rate is selected for the IEEE 802.11 Management frames. This does result in a small extra latency added to the cases where the AP would be able to receive the higher rate, but taken into account how small number of EAPOL frames are used, this is likely to be insignificant. A future optimization in the minstrel_ht design can also allow this patch to be reverted to get back to the more optimized initial TX rate. It should also be noted that many drivers that do not use minstrel as the rate control algorithm are already doing similar workarounds by forcing the lowest TX rate to be used for EAPOL frames. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Tested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust the controlling if-statement to make this work] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* mac80211: fix AP powersave TX vs. wakeup raceEmmanuel Grumbach2014-04-021-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1d147bfa64293b2723c4fec50922168658e613ba upstream. There is a race between the TX path and the STA wakeup: while a station is sleeping, mac80211 buffers frames until it wakes up, then the frames are transmitted. However, the RX and TX path are concurrent, so the packet indicating wakeup can be processed while a packet is being transmitted. This can lead to a situation where the buffered frames list is emptied on the one side, while a frame is being added on the other side, as the station is still seen as sleeping in the TX path. As a result, the newly added frame will not be send anytime soon. It might be sent much later (and out of order) when the station goes to sleep and wakes up the next time. Additionally, it can lead to the crash below. Fix all this by synchronising both paths with a new lock. Both path are not fastpath since they handle PS situations. In a later patch we'll remove the extra skb queue locks to reduce locking overhead. BUG: unable to handle kernel NULL pointer dereference at 000000b0 IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211] *pde = 00000000 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1 EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211] EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000 ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000) iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9 Stack: e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0 ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210 ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002 Call Trace: [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211] [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211] [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211] [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211] [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211] [<c149ef70>] dev_hard_start_xmit+0x450/0x950 [<c14b9aa9>] sch_direct_xmit+0xa9/0x250 [<c14b9c9b>] __qdisc_run+0x4b/0x150 [<c149f732>] dev_queue_xmit+0x2c2/0xca0 Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com> [reword commit log, use a separate lock] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* mac80211: fix fragmentation code, particularly for encryptionJohannes Berg2014-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f upstream. The "new" fragmentation code (since my rewrite almost 5 years ago) erroneously sets skb->len rather than using skb_trim() to adjust the length of the first fragment after copying out all the others. This leaves the skb tail pointer pointing to after where the data originally ended, and thus causes the encryption MIC to be written at that point, rather than where it belongs: immediately after the data. The impact of this is that if software encryption is done, then a) encryption doesn't work for the first fragment, the connection becomes unusable as the first fragment will never be properly verified at the receiver, the MIC is practically guaranteed to be wrong b) we leak up to 8 bytes of plaintext (!) of the packet out into the air This is only mitigated by the fact that many devices are capable of doing encryption in hardware, in which case this can't happen as the tail pointer is irrelevant in that case. Additionally, fragmentation is not used very frequently and would normally have to be configured manually. Fix this by using skb_trim() properly. Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation") Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* mac80211: fix AP mode EAP tx for VLAN stationsFelix Fietkau2012-05-111-1/+2
| | | | | | | | | | | | | | | commit 66f2c99af3d6f2d0aa1120884cf1c60613ef61c0 upstream. EAP frames for stations in an AP VLAN are sent on the main AP interface to avoid race conditions wrt. moving stations. For that to work properly, sta_info_get_bss must be used instead of sta_info_get when sending EAP packets. Previously this was only done for cooked monitor injected packets, so this patch adds a check for tx->skb->protocol to the same place. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* mac80211: revert on-channel work optimisationsJohannes Berg2012-01-251-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit e76aadc572288a158ae18ae1c10fe395c7bca066 upstream. Backport note: This patch it's a full revert of commit b23b025f "mac80211: Optimize scans on current operating channel.". On upstrem revert e76aadc5 we keep some bits from that commit, which are needed for upstream version of mac80211. The on-channel work optimisations have caused a number of issues, and the code is unfortunately very complex and almost impossible to follow. Instead of attempting to put in more workarounds let's just remove those optimisations, we can work on them again later, after we change the whole auth/assoc design. This should fix rate_control_send_low() warnings, see RH bug 731365. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* net: Add export.h for EXPORT_SYMBOL/THIS_MODULE to non-modulesPaul Gortmaker2011-10-311-0/+1
| | | | | | | | | These files are non modular, but need to export symbols using the macros now living in export.h -- call out the include so that things won't break when we remove the implicit presence of module.h from everywhere. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* mac80211: reformat TX unauthorised checkJohannes Berg2011-10-141-5/+4
| | | | | | | | | Reformat the check, the indentation is completely strange. Also change the last part of the condition to make the code shorter. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: dont orphan TX skbJohannes Berg2011-10-111-5/+0
| | | | | | | | | | | | | | | | | This was another workaround for truesize "bugs". The reason we did this was that when we orphaned the SKB it wouldn't be truesize-checked later. Now that the check is gone (and we just charge the former smaller size to the socket) there's no longer a reason to orphan the skb here. Keep the skb charged to the socket until it is really freed (or orphaned in TX status). This helps flow control and allows us to get at the socket later for other purposes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: dont adjust truesizeJohannes Berg2011-10-111-3/+0
| | | | | | | | | | | | | | | | There's no need to adjust truesize. The history of this was that we always ran into skb_truesize_bug (via skb_truesize_check) which has since been removed in commit 92a0acce186cd. skb_truesize_check() checked that truesize was bigger or equal to the actual allocation, which would trigger in mac80211 due to header adding. The check no longer exists and we shouldn't be messing with the truesize anwyay. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: parse radiotap header earlierJohannes Berg2011-10-111-113/+88
| | | | | | | | | | | We can now move the radiotap header parsing into ieee80211_monitor_start_xmit(). This moves it out of the hotpath, and also helps the code since now the radiotap header will no longer be present in ieee80211_xmit() etc. which is easier to understand. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: move fragment flag to info flag as dont-fragmentJohannes Berg2011-10-111-25/+14
| | | | | | | | | | | | | The purpose of this is two-fold: 1) by moving it out of tx_data.flags, we can in another patch move the radiotap parsing so it no longer is in the hotpath 2) if a device implements fragmentation but can optionally skip it, the radiotap request for not doing fragmentation may be honoured Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: remove tx_data ethertypeJohannes Berg2011-10-111-6/+1
| | | | | | | It's set, but never used, so kill it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: optimise monitor xmitJohannes Berg2011-10-111-59/+49
| | | | | | | | | | Since the only way the interface can be a monitor interface in ieee80211_xmit() is because the frame came from ieee80211_monitor_start_xmit() we can move all the code there. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Allow noack flag overwrite for injected framesHelmut Schaa2011-10-031-2/+13
| | | | | | | | Allow injected unicast frames to be sent without having to wait for an ACK. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: dont assign seqno to or aggregate QoS Null framesJohannes Berg2011-09-301-0/+4
| | | | | | | | | | | | | | | | 802.11 says: "Sequence numbers for QoS (+)Null frames may be set to any value." However, if we use the normal counters then peers will get confused with aggregation since there'll be holes in the sequence number sequence. To avoid that, neither assign a sequence number to QoS null frames nor put them on aggregation. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: optimise station flagsJohannes Berg2011-09-301-30/+38
| | | | | | | | | | | | | | | | | | | | The flaglock in struct sta_info has long been something that I wanted to get rid of, this finally does the conversion to atomic bitops. The conversion itself is straight-forward in most places, a few things needed to change a bit since we can no longer use multiple bits at the same time. On x86-64, this is a fairly significant code size reduction: text data bss dec hex 427861 23648 1008 452517 6e7a5 before 425383 23648 976 450007 6ddd7 after Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: send (QoS) Null if no buffered framesJohannes Berg2011-09-301-2/+1
| | | | | | | | | | | | | For PS-poll, there's a possible race between us expiring a frame and the station polling for it -- send it a null frame in that case. For uAPSD, the standard says that we have to send a frame in each SP, so send null if we don't have any other frames. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: implement uAPSDJohannes Berg2011-09-301-4/+4
| | | | | | | | | | | | | | | | | | | Add uAPSD support to mac80211. This is probably not possible with all devices, so advertising it with the cfg80211 flag will be left up to drivers that want it. Due to my previous patches it is now a fairly straight-forward extension. Drivers need to have accurate TX status reporting for the EOSP frame. For drivers that buffer themselves, the provided APIs allow releasing the right number of frames, but then drivers need to set EOSP and more-data themselves. This is documented in more detail in the new code itself. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: split PS buffers into ACsJohannes Berg2011-09-301-17/+25
| | | | | | | | | | | | | | | | | For uAPSD support we'll need to have per-AC PS buffers. As this is a major undertaking, split the buffers before really adding support for uAPSD. This already makes some reference to the uapsd_queues variable, but for now that will never be non-zero. Since book-keeping is complicated, also change the logic for keeping a maximum of frames only and allow 64 frames per AC (up from 128 for a station). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: unify TIM bit handlingJohannes Berg2011-09-301-9/+6
| | | | | | | | | | | | Currently, the TIM bit for a given station is set and cleared all over the place. Since the logic to set/clear it will become much more complex when we add uAPSD support, as a first step let's collect the entire logic in one place. This requires a few small adjustments to other places. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: data path modification for TDLS peersArik Nemtsov2011-09-301-4/+38
| | | | | | | | | | | | | | | | | | | Mark the STA entries of enabled TDLS peers with a new "peer authorized" flag. During link setup, allow special TDLS setup frames through the AP, but otherwise drop all packets destined to the peer. This is required by the TDLS (802.11z) specification in order to prevent reordering of MSDUs between the AP and direct paths. When setup completes and the peer is authorized, send data directly, bypassing the AP. In the Rx path, allow data to be received directly from TDLS peers. Signed-off-by: Arik Nemtsov <arik@wizery.com> Cc: Kalyan C Gaddam <chakkal@iit.edu> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: standardize adding supported rates IEsArik Nemtsov2011-09-301-2/+2
| | | | | | | | | Relocate the mesh implementation of adding the (extended) supported rates IE to util.c, anticipating its use by other parts of mac80211. Signed-off-by: Arik Nemtsov <arik@wizery.com> Cc: Kalyan C Gaddam <chakkal@iit.edu> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Mesh data frames must have the QoS headerJavier Cardona2011-09-141-1/+1
| | | | | | | | Per sec 7.1.3.5 of draft 12.0 of 802.11s, mesh frames indicate the presence of the mesh control header in their QoS header. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Start implementing QoS support for mesh interfacesJavier Cardona2011-09-141-0/+4
| | | | | | | | | | | | | In order to support QoS in mesh, we need to assign queue mapping only after the next hop has been resolved, both for forwarded and locally originated frames. Also, now that this is fixed, remove the XXX comment in ieee80211_select_queue(). Also, V-Shy Ho reported that the queue mapping was not being applied to the forwarded frame (fwd_skb instead of skb). Fixed that as well. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: add flag to indicate HW only Tx-agg setup supportArik Nemtsov2011-09-131-1/+2
| | | | | | | | | When this flag is set, Tx A-MPDU sessions will not be started by mac80211. This flag is required for devices that support Tx A-MPDU setup in hardware. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Remove unnecessary OOM logging messagesJoe Perches2011-09-131-12/+5
| | | | | | | | | | | Removing unnecessary messages saves code and text. Site specific OOM messages are duplications of a generic MM out of memory message and aren't really useful, so just delete them. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix mesh beacon formatThomas Pedersen2011-08-221-2/+12
| | | | | | | | | | Correct ordering of IEs in the mesh beacon while removing unneeded IEs from mesh peering frames. Set privacy bit in capability info if security is enabled. Add utility functions to aid in construction of IEs and reduce code duplication. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Fill in skb->protocol information for injected framesHelmut Schaa2011-08-091-0/+20
| | | | | | | | | | | | | Some drivers (ath9k for example) are using skb->protocol to treat EAPOL frames somehow special (disallow aggregation for example). When running in AP mode hostapd injects the EAPOL frames through a monitor interface and thus skb->protocol isn't set at all. Hence, if the injected frame is a data frame and carries a rfc1042 headaer update the skb->protocol field accordingly. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: allow driver to disconnect after resumeJohannes Berg2011-07-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | In WoWLAN, devices may use crypto keys for TX/RX and could also implement GTK rekeying. If the driver isn't able to retrieve replay counters and similar information from the device upon resume, or if the device isn't responsive due to platform issues, it isn't safe to keep the connection up as GTK rekey messages from during the sleep time could be replayed against it. The only protection against that is disconnecting from the AP. Modifying mac80211 to do that while it is resuming would be very complex and invasive in the case that the driver requires a reconfig, so do it after it has resumed completely. In that case, however, packets might be replayed since it can then only happen after TX/RX are up again, so mark keys for interfaces that need to disconnect as "tainted" and drop all packets that are sent or received with those keys. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Skip tailroom reservation for full HW-crypto devices with race fixYogesh Ashok Powar2011-07-051-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on inputs from Johannes Berg <johannes@sipsolutions.net> from http://article.gmane.org/gmane.linux.kernel.wireless.general/68193 and http://article.gmane.org/gmane.linux.kernel.wireless.general/71702 In xmit path, devices that do full hardware crypto (including MMIC and ICV) need no tailroom. For such devices, tailroom reservation can be skipped if all the keys are programmed into the hardware (i.e software crypto is not used for any of the keys) and none of the keys wants software to generate Michael MIC and IV. v2: Added check for IV along with MMIC. Reported-by: Fabio Rossi <rossi.f@inwind.it> Tested-by: Fabio Rossi <rossi.f@inwind.it> Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Cc: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> v3: Fixing races to avoid WARNING: at net/mac80211/wpa.c:397 ccmp_encrypt_skb+0xc4/0x1f0 Reported-by: Andreas Hartmann <andihartmann@01019freenet.de> Tested-by: Andreas Hartmann <andihartmann@01019freenet.de> v4: Added links with message ID Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Revert "mac80211: Skip tailroom reservation for full HW-crypto devices"John W. Linville2011-06-061-1/+6
| | | | | | | | | | | | | | | This reverts commit aac6af5534fade2b18682a0b9efad1a6c04c34c6. Conflicts: net/mac80211/key.c That commit has a race that causes a warning, as documented in the thread here: http://marc.info/?l=linux-wireless&m=130717684914101&w=2 Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'master' of ↵David S. Miller2011-05-171-0/+4
|\ | | | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/vmxnet3/vmxnet3_ethtool.c net/core/dev.c
| * mac80211: don't start the dynamic ps timer if not associatedLuciano Coelho2011-05-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are disconnecting, we set PS off, but this happens before we send the deauth/disassoc request. When the deauth/disassoc frames are sent, we trigger the dynamic ps timer, which then times out and turns PS back on. Thus, PS remains on after disconnecting, causing problems when associating again. This can be fixed by preventing the timer to start when we're not associated anymore. Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: sparse RCU annotationsJohannes Berg2011-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds sparse RCU annotations to most of mac80211, only the mesh code remains to be done. Due the the previous patches, the annotations are pretty simple. The only thing that this actually changes is removing the RCU usage of key->sta in debugfs since this pointer isn't actually an RCU-managed pointer (it only has a single assignment done before the key even goes live). As that is otherwise harmless, I decided to make it part of this patch. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Move call to mpp_path_lookup inside RCU-read sectionJavier Cardona2011-05-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | PROVE_RCU caught that one: [ 431.214070] =================================================== [ 431.215341] [ INFO: suspicious rcu_dereference_check() usage. ] [ 431.215674] --------------------------------------------------- [ 431.216043] net/mac80211/mesh_pathtbl.c:184 invoked rcu_dereference_check() without protection! Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: set TID of internal mgmt packets to 7Arik Nemtsov2011-05-051-2/+3
| | | | | | | | | | | | | | | | | | The queue mapping of internal mgmt packets is set to VO. Set the TID value to match the queue mapping. Otherwise drivers that only look at the TID might get confused. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Skip tailroom reservation for full HW-crypto devicesYogesh Ashok Powar2011-04-281-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | In xmit path, devices that do full hardware crypto (including TKIP MMIC) need no tailroom. For such devices, tailroom reservation can be skipped if all the keys are programmed into the hardware (i.e software crypto is not used for any of the keys) and none of the keys wants software to generate Michael MIC. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Fix warnings due to -Wunused-but-set-variableRajkumar Manoharan2011-04-261-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These warnings are exposed by gcc 4.6. net/mac80211/sta_info.c: In function 'sta_info_cleanup_expire_buffered': net/mac80211/sta_info.c:590:32: warning: variable 'sdata' set but not used net/mac80211/ibss.c: In function 'ieee80211_rx_mgmt_auth_ibss': net/mac80211/ibss.c:43:34: warning: variable 'status_code' set but not used net/mac80211/work.c: In function 'ieee80211_send_assoc': net/mac80211/work.c:203:9: warning: variable 'len' set but not used net/mac80211/tx.c: In function '__ieee80211_parse_tx_radiotap': net/mac80211/tx.c:1039:35: warning: variable 'sband' set but not used net/mac80211/mesh.c: In function 'ieee80211_mesh_rx_queued_mgmt': net/mac80211/mesh.c:616:28: warning: variable 'ifmsh' set but not used ... Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | nl80211: rename NL80211_MESH_SETUP_VENDOR_PATH_SEL_IEJavier Cardona2011-04-121-1/+1
|/ | | | | | | | To NL80211_MESH_SETUP_IE. This reflects our ability to insert any ie into a mesh beacon, not simply path selection ies. Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'for-linus' of ↵Linus Torvalds2011-03-181-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (47 commits) doc: CONFIG_UNEVICTABLE_LRU doesn't exist anymore Update cpuset info & webiste for cgroups dcdbas: force SMI to happen when expected arch/arm/Kconfig: remove one to many l's in the word. asm-generic/user.h: Fix spelling in comment drm: fix printk typo 'sracth' Remove one to many n's in a word Documentation/filesystems/romfs.txt: fixing link to genromfs drivers:scsi Change printk typo initate -> initiate serial, pch uart: Remove duplicate inclusion of linux/pci.h header fs/eventpoll.c: fix spelling mm: Fix out-of-date comments which refers non-existent functions drm: Fix printk typo 'failled' coh901318.c: Change initate to initiate. mbox-db5500.c Change initate to initiate. edac: correct i82975x error-info reported edac: correct i82975x mci initialisation edac: correct commented info fs: update comments to point correct document target: remove duplicate include of target/target_core_device.h from drivers/target/target_core_hba.c ... Trivial conflict in fs/eventpoll.c (spelling vs addition)
| * Merge branch 'master' into for-nextJiri Kosina2011-02-151-1/+4
| |\
| * | Kill off warning: ‘inline’ is not at beginning of declarationJesper Juhl2011-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a bunch of warning: ‘inline’ is not at beginning of declaration messages when building a 'make allyesconfig' kernel with -Wextra. These warnings are trivial to kill, yet rather annoying when building with -Wextra. The more we can cut down on pointless crap like this the better (IMHO). A previous patch to do this for a 'allnoconfig' build has already been merged. This just takes the cleanup a little further. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | | mac80211: make tx() operation return voidJohannes Berg2011-02-251-108/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The return value of the tx operation is commonly misused by drivers, leading to errors. All drivers will drop frames if they fail to TX the frame, and they must also properly manage the queues (if they didn't, mac80211 would already warn). Removing the ability for drivers to return a BUSY value also allows significant cleanups of the TX TX handling code in mac80211. Note that this also fixes a bug in ath9k_htc, the old "return -1" there was wrong. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k] Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00] Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi] Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx] Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | | Merge ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6John W. Linville2011-02-181-1/+1
|\ \ \ | | |/ | |/| | | | | | | | | | Conflicts: drivers/bluetooth/ath3k.c drivers/bluetooth/btusb.c
| * | mac80211: fix the skb cloned check in the tx pathFelix Fietkau2011-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using skb_header_cloned to check if it's safe to write to the skb is not enough - mac80211 also touches the tailroom of the skb. Initially this check was only used to increase a counter, however this commit changed the code to also skip skb data reallocation if no extra head/tailroom was needed: commit 4cd06a344db752f513437138953af191cbe9a691 mac80211: skip unnecessary pskb_expand_head calls It added a regression at least with iwl3945, which is fixed by this patch. Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Tested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | | mac80211: Clear PS related flag on disabling power save.Vivek Natarajan2011-02-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Clear IEEE80211_STA_NULLFUNC_ACKED flag on disabling power save. Without this fix, there is a chance of setting CONF_PS before sending nullfunc frame. Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | | mac80211: remove unneeded checkDan Carpenter2011-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | "ap" is the address of sdata->u.ap so it can never be NULL here. Also we dereferenced it on the previous line. I removed the check. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | | mac80211: Optimize scans on current operating channel.Ben Greear2011-02-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should decrease un-necessary flushes, on/off channel work, and channel changes in cases where the only scanned channel is the current operating channel. * Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL and is-scanning flags instead. * Add helper method to determine if we are currently configured for the operating channel. * Do no blindly go off/on channel in work.c Instead, only call appropriate on/off code when we really need to change channels. Always enable offchannel-ps mode when starting work, and disable it when we are done. * Consolidate ieee80211_offchannel_stop_station and ieee80211_offchannel_stop_beaconing, call it ieee80211_offchannel_stop_vifs instead. * Accept non-beacon frames when scanning on operating channel. * Scan state machine optimized to minimize on/off channel transitions. Also, when going on-channel, go ahead and re-enable beaconing. We're going to be there for 200ms, so seems like some useful beaconing could happen. Always enable offchannel-ps mode when starting software scan, and disable it when we are done. * Grab local->mtx earlier in __ieee80211_scan_completed_finish so that we are protected when calling hw_config(), etc. * Pass probe-responses up the stack if scanning on local channel, so that mlme can take a look. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | | mac80211: fix race between next beacon dtim and ieee80211_get_buffered_bcChristian Lamparter2011-02-041-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On review of 'zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()', Christian Lamparter noted that [1]: Since zd_beacon_done also uploads the next beacon so long in advance, there could be an equally long race between the outdated state of the next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6) which -in your case- was uploaded almost a beacon interval ago and the xmit of ieee80211_get_buffered_bc *now*. The dtim bc/mc bit might be not set, when a mc/bc arrived after the beacon was uploaded, but before the "beacon done event" from the hardware. So, dozing stations don't expect the broadcast traffic and of course, they might miss it completely. It's probably better to fix this in mac80211 (see the attached hack). [1] http://marc.info/?l=linux-wireless&m=129435041117256&w=2 CC: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.1 at 2024-06-01 13:00:53 +0000