summaryrefslogtreecommitdiffstats
path: root/net
Commit message (Collapse)AuthorAgeFilesLines
* NFC: llcp: Use list_for_each_entry in llcp_accept_pollAxel Lin2014-11-281-3/+3
| | | | | | | | | list_for_each_entry_safe() is necessary if list objects are deleted from the list while traversing it. Not the case here, so we can use the base list_for_each_entry variant. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add NFC-DEP Target-side ATN SupportMark A. Greer2014-11-281-5/+83
| | | | | | | | | | | | | | | | | | | When an NFC-DEP target receives an ATN PDU, its supposed to respond with a similar ATN PDU. When the Target receives an I PDU with the PNI one less than the current PNI and the last PDU sent was an ATN PDU, the Target is to resend the last non-ATN PDU that it has sent. This is described in section 14.12.3.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement this so add that support. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add NFC-DEP Initiator-side ATN SupportMark A. Greer2014-11-281-6/+98
| | | | | | | | | | | | | | | | | | | | | | | | When an NFC-DEP Initiator times out when waiting for a DEP_RES from the Target, its supposed to send an ATN to the Target. The Target should respond to the ATN with a similar ATN PDU and the Initiator can then resend the last non-ATN PDU that it sent. No more than 'N(retry,atn)' are to be send where 2 <= 'N(retry,atn)' <= 5. If the Initiator had just sent a NACK PDU when the timeout occurred, it is to continue sending NACKs until 'N(retry,nack)' NACKs have been send. This is described in section 14.12.5.6 of the NFC-DEP Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement this so add that support. The value chosen for 'N(retry,atn)' is 2. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add NFC-DEP Target-side NACK SupportMark A. Greer2014-11-281-11/+51
| | | | | | | | | | | | | | | | | | | | | | | | | When an NFC-DEP Target receives a NACK PDU with a PNI equal to 1 less than the current PNI, it is supposed to re-send the last PDU. This is implied in section 14.12.5.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement Target-side NACK handing so add it. The last PDU that was sent is saved in the 'nfc_digital_dev' structure's 'saved_skb' member. The skb will have an additional reference taken to ensure that the skb isn't freed when the driver performs a kfree_skb() on the skb. The length of the skb/PDU is also saved so the length can be restored when re-sending the PDU in the skb (the driver will perform an skb_pull() so an skb_push() needs to be done to restore the skb's data pointer/length). Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add NFC-DEP Initiator-side NACK SupportMark A. Greer2014-11-281-5/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an NFC-DEP Initiator receives a frame with an incorrect CRC or with a parity error, and the frame is at least 4 bytes long, its supposed to send a NACK to the Target. The Initiator can send up to 'N(retry,nack)' consecutive NACKs where 2 <= 'N(retry,nack)' <= 5. When the limit is exceeded, a PROTOCOL EXCEPTION is raised. Any other type of transmission error is to be ignored and the Initiator should continue waiting for a new frame. This is described in section 14.12.5.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement any of this so add it. This support diverges from the spec in two significant ways: a) NACKs will be sent for ANY error reported by the driver except a timeout. This is done because there is currently no way for the digital layer to distinguish a CRC or parity error from any other type of error reported by the driver. b) All other errors will cause a PROTOCOL EXCEPTION even frames with CRC errors that are less than 4 bytes. The value chosen for 'N(retry,nack)' is 2. Targets do not send NACK PDUs. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add NFC-DEP Receive Chaining SupportMark A. Greer2014-11-281-6/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the peer in an NFC-DEP exchange has a packet to send that is larger than the local maximum payload, it sets the 'MI' bit in the 'I' PDU. This indicates that NFC-DEP chaining is to occur. When such a PDU is received, the local side responds with an 'ACK' PDU and this continues until the peer sends an 'I' PDU with the 'MI' bit cleared. This indicates that the chaining sequence is complete and the entire packet has been transferred. Receiving chained PDUs is currently not supported by the digital layer so add that support. When a chaining sequence is initiated by the peer, the digital layer will allocate an skb large enough to hold 8 maximum sized frame payloads. The maximum payload can range from 64 to 254 bytes so 8 * 254 = 2032 seems like a reasonable compromise between potentially wasting memory and constantly reallocating new, larger skbs. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add NFC-DEP Send Chaining SupportMark A. Greer2014-11-281-17/+109
| | | | | | | | | | | | | | | | | | | | | | | | | When the NFC-DEP code is given a packet to send that is larger than the peer's maximum payload, its supposed to set the 'MI' bit in the 'I' PDU's Protocol Frame Byte (PFB). Setting this bit indicates that NFC-DEP chaining is to occur. When NFC-DEP chaining is progress, sender 'I' PDUs are acknowledged with 'ACK' PDUs until the last 'I' PDU in the chain (which has the 'MI' bit cleared) is responded to with a normal 'I' PDU. This can occur while in Initiator mode or in Target mode. Sender NFC-DEP chaining is currently not implemented in the digital layer so add that support. Unfortunately, since sending a frame may require writing the CRC to the end of the data, the relevant data part of the original skb must be copied for each intermediate frame. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Implement NFC-DEP max payload lengthsMark A. Greer2014-11-281-10/+98
| | | | | | | | | | | | | | | | | | | | | The maximum payload for NFC-DEP exchanges (i.e., the number of bytes between SoD and EoD) is negotiated using the ATR_REQ, ATR_RES, and PSL_REQ commands. The valid maximum lengths are 64, 128, 192, and 254 bytes. Currently, NFC-DEP code assumes that both sides are always using 254 byte maximums and ignores attempts by the peer to change it. Instead, implement the negotiation code, enforce the local maximum when receiving data from the peer, and don't send payloads that exceed the remote's maximum. The default local maximum is 254 bytes. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Enforce NFC-DEP PNI sequencingMark A. Greer2014-11-281-3/+33
| | | | | | | | | | | | | | | NFC-DEP DEP_REQ and DEP_RES exchanges using 'I' and 'ACK/NACK' PDUs have a sequence number called the Packet Number Information (PNI). The PNI is incremented (modulo 4) after every DEP_REQ/ DEP_RES pair and should be verified by the digital layer code. That verification isn't always done, though, so add code to make sure that it is done. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Ensure no NAD byte in DEP_REQ and DEP_RES framesMark A. Greer2014-11-281-0/+10
| | | | | | | | | | | | According to chapter 14 of the NFC-DEP Digital Protocol Spec., the NAD byte should never be present in DEP_REQ or DEP_RES frames. However, this is not enforced so add that enforcement code. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add Target-mode NFC-DEP DID SupportMark A. Greer2014-11-281-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | When in Target mode, the Initiator specifies whether subsequent DEP_REQ and DEP_RES frames will include a DID byte by the value passed in the ATR_REQ. If the DID value in the ATR_REQ is '0' then no DID byte will be included. If the DID value is between '1' and '14' then a DID byte containing the same value must be included in subsequent DEP_REQ and DEP_RES frames. Any other DID value is invalid. This is specified in sections 14.8.1.2 and 14.8.2.2 of the NFC Digital Protocol Spec. Checking the DID value (if it should be there at all), is not currently supported by the digital layer's NFC-DEP code. Add this support by remembering the DID value in the ATR_REQ, checking the DID value of received DEP_REQ frames (if it should be there at all), and including the remembered DID value in DEP_RES frames when appropriate. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Ensure no DID in NFC-DEP responsesMark A. Greer2014-11-281-2/+5
| | | | | | | | | | | | | | | | | | | When in Initiator mode, the digital layer's NFC-DEP code always sets the Device ID (DID) value in the ATR_REQ to '0'. This means that subsequent DEP_REQ and DEP_RES frames must never include a DID byte. This is specified in sections 14.8.1.1 and 14.8.2.1 of the NFC Digital Protocol Spec. Currently, the digital layer's NFC-DEP code doesn't enforce this rule so add code to ensure that there is no DID byte in DEP_RES frames. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Rearrange NFC-DEP DEP_REQ/DEP_RES CodeMark A. Greer2014-11-281-21/+22
| | | | | | | | | | | | Rearrange some of the code in digital_in_recv_dep_res() and digital_tg_recv_dep_req() so the initial code looks similar. The real reason is prepare the code for some upcoming patches that require these changes. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Fix potential skb leaks in NFC-DEP codeMark A. Greer2014-11-281-8/+17
| | | | | | | | | | | | | When digital_in_send_cmd() or digital_tg_send_cmd() fail, they do not free the skb that was passed to them so the routine that allocated the skb should free it. Currently, there are several routines in the NFC-DEP code that don't do this so make them. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* Merge tag 'mac80211-next-for-john-2014-11-20' of ↵John W. Linville2014-11-2027-303/+2266
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg <johannes@sipsolutions.net> says: "It has been a while since my last pull request, so we accumulated another relatively large set of changes: * TDLS off-channel support set from Arik/Liad, with some support patches I did * custom regulatory fixes from Arik * minstrel VHT fix (and a small optimisation) from Felix * add back radiotap vendor namespace support (myself) * random MAC address scanning for cfg80211/mac80211/hwsim (myself) * CSA improvements (Luca) * WoWLAN Net Detect (wake on network found) support (Luca) * and lots of other smaller changes from many people" Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: minstrel_ht: add a small optimization to minstrel_aggr_checkFelix Fietkau2014-11-191-3/+3
| | | | | | | | | | | | | | | | Check the queue mapping earlier, skb->queue_mapping is more likely than skb->data to still be in d-cache. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: notify drivers on sta rate table changesJohannes Berg2014-11-193-0/+25
| | | | | | | | | | | | | | | | | | This allows drivers with a firmware or chip-based rate lookup table to use the most recent default rate selection without having to get it from per-packet data or explicit ieee80211_get_tx_rate calls Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * nl80211: Broadcast CMD_NEW_INTERFACE and CMD_DEL_INTERFACETomasz Bursztyka2014-11-191-7/+41
| | | | | | | | | | | | | | | | | | Let the other listeners being notified when a new or del interface command has been issued, thus reducing later necessary request to be in sync with current context. Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * nl80211: Replace interface socket owner attribute with more generic oneJukka Rissanen2014-11-191-2/+2
| | | | | | | | | | | | | | | | | | Replace NL80211_ATTR_IFACE_SOCKET_OWNER attribute with more generic NL80211_ATTR_SOCKET_OWNER that can be used with other commands that interface creation. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: protect fools returning NULL in add_virtual_intfRafał Miłecki2014-11-191-1/+4
| | | | | | | | | | | | | | | | | | Callback add_virtual_intf is supposed to return ERR_PTR and trying to return NULL results in some "Unable to handle kernel paging request", etc. As it may be complicated to debug & trace, let's catch it (WARN). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: explicitly initialize some fields in custom reg pathArik Nemtsov2014-11-191-0/+3
| | | | | | | | | | | | | | | | | | Explicitly initialize the DFS state and beacon found state when handling channels in the custom regulatory path. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Acked-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: update missing fields in custom regulatory pathArik Nemtsov2014-11-191-0/+10
| | | | | | | | | | | | | | | | | | | | Some channels fields were not being updated in the custom regulatory path. Update them according to the code in handle_channel(). Signed-off-by: Jonathan Doron <jonathanx.doron@intel.com> Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Acked-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: skip legacy rate mask handling for VHT ratesFelix Fietkau2014-11-191-1/+1
| | | | | | | | | | | | | | | | | | The rate mask code currently assumes that a rate is legacy if IEEE80211_TX_RC_MCS is not set. This might be the cause of bogus VHT rates being reported with minstrel_ht. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: don't allow 40MHz tx rates in case of 20MHz chandefEliad Peller2014-11-191-0/+2
| | | | | | | | | | | | | | | | | | | | When 20MHz chandef is used, 40MHz rates shouldn't be used (by the rate-control algorithm), even if the sta ht capabilities indicate support for it. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Singed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDRJohannes Berg2014-11-197-38/+92
| | | | | | | | | | | | | | | | Allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR with software based scanning and generate a random MAC address for them for every scan request with the flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: rcu-ify scan and scheduled scan request pointersJohannes Berg2014-11-193-34/+56
| | | | | | | | | | | | | | | | In order to use the scan and scheduled scan request pointers during RX to check for randomisation, make them accessible using RCU. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: allow drivers to support random MAC addresses for scanJohannes Berg2014-11-191-3/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the necessary feature flags and a scan flag to support using random MAC addresses for scan while unassociated. The configuration for this supports an arbitrary MAC address value and mask, so that any kind of configuration (e.g. fixed OUI or full 46-bit random) can be requested. Full 46-bit random is the default when no other configuration is passed. Also add a small helper function to use the addr/mask correctly. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: remove redundant checkEliad Peller2014-11-191-1/+1
| | | | | | | | | | | | | | | | local->scan_req was tested in the previous line, so it can't be NULL. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: add wowlan net-detect supportLuciano Coelho2014-11-192-1/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new WoWLAN API to enable net-detect as a wake up trigger. Net-detect allows the device to scan in the background while the host is asleep to wake up the host system when a matching network is found. Reuse the scheduled scan attributes to specify how the scan is performed while suspended and the matches that will trigger a wake event. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: refactor nl80211_start_sched_scan so it can be reusedLuciano Coelho2014-11-191-58/+72
| | | | | | | | | | | | | | | | | | For net detect, we will need to reuse most of the scheduled scan parsing function, but not all, so split out the attributes parsing part out of the main start sched_scan function. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: synchronously reserve TID per stationLiad Kaufman2014-11-196-0/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In TDLS (e.g., TDLS off-channel) there is a requirement for some drivers to supply an unused TID between the AP and the device to the FW, to allow sending PTI requests and to allow the FW to aggregate on a specific TID for better throughput. To ensure that the allocated TID is indeed unused, this patch introduces an API for blocking the driver from TXing on that TID. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add specific-queue flushing supportLiad Kaufman2014-11-192-5/+18
| | | | | | | | | | | | | | | | | | If the HW supports IEEE80211_HW_QUEUE_CONTROL, allow flushing only specific queues rather than all of them. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add TDLS channel-switch Rx flowArik Nemtsov2014-11-197-1/+413
| | | | | | | | | | | | | | | | | | | | When receiving a TDLS channel switch request or response, parse the frame and call a new tdls_recv_channel_switch op in the low level driver with the parsed data. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: introduce TDLS channel switch opsArik Nemtsov2014-11-199-5/+362
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the cfg80211 TDLS channel switch ops and introduce new mac80211 ones for low-level drivers. Verify low-level driver support for the new ops when using the relevant wiphy feature bit. Also verify the peer supports channel switching before passing the command down. Add a new STA flag to track the off-channel state with the TDLS peer and make sure to cancel the channel-switch if the peer STA is unexpectedly removed. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add parsing of TDLS specific IEsArik Nemtsov2014-11-192-0/+18
| | | | | | | | | | | | | | | | These are used in TDLS channel switching code. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: introduce TDLS channel switch commandsArik Nemtsov2014-11-194-0/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | Introduce commands to initiate and cancel TDLS channel-switching. Once TDLS channel-switching is started, the lower level driver is responsible for continually initiating channel-switch operations and returning to the base (AP) channel to listen for beacons from time to time. Upon cancellation of the channel-switch all communication between the relevant TDLS peers will continue on the base channel. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: prepare TDLS mgmt code for channel-switch templatesArik Nemtsov2014-11-191-25/+57
| | | | | | | | | | | | | | | | | | | | | | Split the data-generating from the Tx-sending functionality, as we do not want to send templates to the lower driver. Also add an optional chandef argument to the data-generating portion. It will be used for channel-switch templates. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: track AP and peer STA TDLS chan-switch supportArik Nemtsov2014-11-196-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | The AP or peer can prohibit TDLS channel switch via a bit in the extended capabilities IE. Parse the IE and track this bit. Set an appropriate STA flag if both the AP and peer STA support TDLS channel-switching. Add the new STA flag and the missing TDLS_INITIATOR to debugfs. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg/mac80211: define TDLS channel switch feature bitArik Nemtsov2014-11-191-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | Define some related TDLS protocol constants and advertise channel switch support in the extended-capabilities IE when the feature bit is defined. Actually supporting TDLS channel-switching also requires support for some new nl80211 commands, to be introduced by future patches. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add BSS coex IE to TDLS setup framesArik Nemtsov2014-11-191-0/+15
| | | | | | | | | | | | | | | | | | Add the BSS coex IE in case we support HT40 channels, as mandated by section 8.5.13 in IEEE802.11 2012. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add supported channels IE during TDLS setupArik Nemtsov2014-11-191-0/+71
| | | | | | | | | | | | | | | | | | | | This information element is mandatory in case TDLS channel-switching is to be supported. The channels given are ones supported and allowed to be active in the current regulatory setting. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add function to create data frame template including keyJohannes Berg2014-11-192-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some TDLS channel switch implementations data frames need to be sent by the firmware based on a template. This template should be created by mac80211, and thus needs to properly be built from an 802.3 frame into an 802.11 frame. In addition, the device will need the key information so the select_key handler needs to be run. However, the driver/device will be responsible for all of the crypto encapsulation, as the sequence numbers etc. cannot be built by the host anyway in this case since it's a template to be used multiple times. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: factor out 802.11 header building codeJohannes Berg2014-11-191-52/+92
| | | | | | | | | | | | | | | | | | | | | | Factor out the 802.11 header building code from the xmit function to be able to use it separately in a later commit. While at it, fix up some documentation. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: move skb info band assignment outJohannes Berg2014-11-194-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | Instead of passing the band as a parameter to ieee80211_xmit() and ieee80211_tx(), move it outside of the two functions while making sure info->band is set up before calling them. This removes the parameter and simplifies the follow commit. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: retransmit TDLS teardown packet through AP if not ACKedLiad Kaufman2014-11-194-13/+117
| | | | | | | | | | | | | | | | | | | | | | Since the TDLS peer station might not receive the teardown packet (e.g., when in PS), this makes sure the packet is retransmitted - this time through the AP - if the TDLS peer didn't ACK the packet. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add option for setting skb flags before xmitLiad Kaufman2014-11-192-8/+16
| | | | | | | | | | | | | | | | | | Allows setting of an skb's flags - if needed - when calling ieee80211_subif_start_xmit(). Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * Merge remote-tracking branch 'wireless-next/master' into mac80211-nextJohannes Berg2014-11-18125-2997/+3054
| |\ | | | | | | | | | | | | | | | | | | This brings in some mwifiex changes that further patches will need to work on top to not cause merge conflicts. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: refactor duplicate detectionJohannes Berg2014-11-111-5/+20
| | | | | | | | | | | | | | | | | | | | | Put duplicate detection into its own RX handler, and separate out the conditions a bit to make the code more readable. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211: introduce regulatory flags controlling bwArik Nemtsov2014-11-101-2/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow setting bandwidth related regulatory flags. These flags are mapped to the corresponding channel flags in the specified range. Make sure the new flags are consulted when calculating the maximum bandwidth allowed by a regulatory-rule. Also allow propagating the GO_CONCURRENT modifier from a reg-rule to a channel. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: add back support for radiotap vendor namespace dataJohannes Berg2014-11-101-18/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | Radiotap vendor namespace data might still be useful, but we reverted it because it used too much space in the RX status. Put it back, but address the space problem by using a single bit only and putting everything else into the skb->data. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
OpenPOWER on IntegriCloud