- 18 Dec, 2018 15 commits
-
-
Shaul Triebitz authored
HE Operation element has changed in 11ax D3.0. Update the fields accordingly. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
TWT is a feature that was added in 11ah and enhanced in 11ax. There are two bits that need to be set if we want to use the feature in 11ax: one in the HE Capability IE and one in the Extended Capability IE. This is because of backward compatibility between 11ah and 11ax. In order to simplify the flow for the low level driver in managed mode, aggregate the two bits and add a boolean that tells whether TWT is supported or not, but only if 11ax is supported. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
These bits are defined in ieee802.11ax to advertise support for TWT in addition to the bits in the HE IE. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Sriram R authored
Currently radar detection and corresponding channel switch is handled at the AP device. STA ignores these detected radar events since the radar signal can be seen mostly by the AP as well. But in scenarios where a radar signal is seen only at STA, notifying this event to the AP which can trigger a channel switch can be useful. Stations can report such radar events autonomously through Spectrum management (Measurement Report) action frame to its AP. The userspace on processing the report can notify the kernel with the use of the added NL80211_CMD_NOTIFY_RADAR to indicate the detected event and inturn adding the reported channel to NOL. Signed-off-by: Sriram R <srirrama@codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Sara Sharon authored
If we build AMSDU from GSO packets, it can lead to bad results if anyone tries to call skb_gso_segment on the packets. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
In the iwlwifi conversion, we sometimes call this from outside of the wake_tx_queue() method, and in those cases must be in an RCU critical section. Document this requirement. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
At the place where this code lives now, the skb can never be NULL, so we can remove the pointless NULL check. It seems to exist because this code was moved around a few times and originally came from a place where it could in fact be NULL. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This isn't really a problem now, but it means that the function has a few NULL checks that are only relevant when coming from the initial interface added in mac80211, and that's confusing. Just pass non-NULL (but equivalently empty) in that case and remove all the NULL checks. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Ilan Peer authored
The monitor interface Rx handling of SKBs that contain only radiotap information was buggy as it tried to access the SKB assuming it contains a frame. To fix this, check the RX_FLAG_NO_PSDU flag in the Rx status (indicting that the SKB contains only radiotap information), and do not perform data path specific processing when the flag is set. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luca Coelho authored
There are talks about enabling -Wimplicit-fallthrough warnings in the mainline and it is already enabled in linux-next. Add all the missing annotations to prevent warnings when this happens. And in one case, remove the extra text from the annotation so that the compiler recognizes it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The older code and current userspace assumed that this data is the content of the Measurement Report element, starting with the Measurement Token. Clarify this in the documentation. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The pointer and corresponding length is always set in pairs in cfg80211, so no need to have this strange defensive check that also confuses static checkers. Clean it up. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Randy Dunlap authored
Fix kernel-doc warnings in FTM due to missing "struct" keyword. Fixes 109 warnings from <net/cfg80211.h>: ../include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' and fixes 88 warnings from <net/mac80211.h>: ../include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' Fixes: 81e54d08 ("cfg80211: support FTM responder configuration/statistics") Fixes: bc847970 ("mac80211: support FTM responder configuration/statistics") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Cc: Johannes Berg <johannes.berg@intel.com> Cc: David Spinadel <david.spinadel@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Linus Walleij authored
The legacy <linux/gpio.h> header is no longer in use by the rfkill driver, so drop this include. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
James Prestwood authored
Moved setting if_combination.num_different_channels/radar_detect_widths into an else after use_chanctx. In the case of use_chanctx, these two settings were getting overwritten. Signed-off-by: James Prestwood <james.prestwood@linux.intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 05 Dec, 2018 5 commits
-
-
Emmanuel Grumbach authored
The iTXQs stop/wake queue mechanism involves a whole bunch of locks and this is probably why the call to ieee80211_wake_txqs is deferred to a tasklet when called from __ieee80211_wake_queue. Another advantage of that is that ieee80211_wake_txqs might call the wake_tx_queue() callback and then the driver may call mac80211 which will call it back in the same context. The bug I saw is that when we send a deauth frame as a station we do: flush(drop=1) tx deauth flush(drop=0) While we flush we stop the queues and wake them up immediately after we finished flushing. The problem here is that the tasklet that de-facto enables the queue may not have run until we send the deauth. Then the deauth frame is sent to the driver (which is surprising by itself), but the driver won't get anything useful from ieee80211_tx_dequeue because the queue is stopped (or more precisely because vif->txqs_stopped[0] is true). Then the deauth is not sent. Later on, the tasklet will run, but that'll be too late. We'll already have removed all the vif etc... Fix this by calling ieee80211_wake_txqs synchronously if we are not waking up the queues from the driver (we check the reason to determine that). This makes the code really convoluted because we may call ieee80211_wake_txqs from __ieee80211_wake_queue. The latter assumes that queue_stop_reason_lock has been taken by the caller and ieee80211_wake_txqs may release the lock to send the frames. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
Lubomir Rintel recently pointed out a dead link for o11s.org, and repointed it to a still live, but also stale website. As far as I know, no one is updating the content at open80211s.org. Since this Kconfig text was originally written, though, the 802.11s mesh drafts were approved and ultimately rolled into 802.11 proper. Meanwhile, the implementation has converged on the final standard, so we can lose all of the text here and provide something that's a little more helpful and accurate. Signed-off-by: Bob Copeland <bobcopeland@fb.com> Reviewed-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Steve deRosier <derosier@cal-sierra.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Cody Schuffelen authored
This device takes over an existing network device and produces a new one that appears like a wireless connection, returning enough canned responses to nl80211 to satisfy a standard connection manager. If necessary, it can also be set up one step removed from an existing network device, such as through a vlan/80211Q or macvlan connection to not disrupt the existing network interface. To use it to wrap a bare ethernet connection: ip link add link eth0 name wlan0 type virt_wifi You may have to rename or otherwise hide the eth0 from your connection manager, as the original network link will become unusuable and only the wireless wrapper will be functional. This can also be combined with vlan or macvlan links on top of eth0 to share the network between distinct links, but that requires support outside the machine for accepting vlan-tagged packets or packets from multiple MAC addresses. This is being used for Google's Remote Android Virtual Device project, which runs Android devices in virtual machines. The standard network interfaces provided inside the virtual machines are all ethernet. However, Android is not interested in ethernet devices and would rather connect to a wireless interface. This patch allows the virtual machine guest to treat one of its network connections as wireless rather than ethernet, satisfying Android's network connection requirements. We believe this is a generally useful driver for simulating wireless network connections in other environments where a wireless connection is desired by some userspace process but is not available. This is distinct from other testing efforts such as mac80211_hwsim by being a cfg80211 device instead of mac80211 device, allowing straight pass-through on the data plane instead of forcing packaging of ethernet data into mac80211 frames. Signed-off-by: A. Cody Schuffelen <schuffelen@google.com> Acked-by: Alistair Strachan <astrachan@google.com> Acked-by: Greg Hartman <ghartman@google.com> Acked-by: Tristan Muntsinger <muntsinger@google.com> [make it a tristate] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Stephen Hemminger authored
Spelling errors found by codespell Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
James Prestwood authored
Creating radios during startup follows a different code path than HWSIM_CMD_NEW_RADIO. The problem was that param.iftypes was not being set to the deafult before calling mac80211_hwsim_new_radio Signed-off-by: James Prestwood <james.prestwood@linux.intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 09 Nov, 2018 20 commits
-
-
Bob Copeland authored
When peering is in userspace, some implementations may want to control which peers are accepted based on RSSI in addition to the information elements being sent today. Add signal level so that info is available to clients. Signed-off-by: Bob Copeland <bobcopeland@fb.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
When userspace is controlling mesh routing, it may have better knowledge about whether a mesh STA is connected to a mesh gate than the kernel mpath table. Add dot11MeshConnectedToMeshGate to the mesh config so that such applications can explicitly signal that a mesh STA is connected to a gate, which will then be advertised in the beacon. Signed-off-by: Bob Copeland <bobcopeland@fb.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
Capture the current state of gate connectivity from the mesh formation field in mesh config whenever we receive a beacon, and report that via GET_STATION. This allows applications doing mesh peering in userspace to make peering decisions based on peers' current upstream connectivity. Signed-off-by: Bob Copeland <bobcopeland@fb.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
The Connected to Mesh Gate subfield (802.11-2016 9.4.2.98.7) in the Mesh Formation Info field is currently unset. This field may be useful in determining which MBSSes to join or which mesh STAs to peer with. If this mesh STA is a gate, by having turned on mesh gate announcements, or if we have a path to one (e.g. by having received RANNs) then set this bit to 1. Signed-off-by: Bob Copeland <bobcopeland@fb.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
In some cases, like in the rsi driver hardware scan offload, there may be scenarios in which hardware scan might not be available or desirable. Allow drivers to cope with this by letting them fall back to software scan by returning the special value 1 from the hardware scan method. Requested-by: Sushant Kumar Mishra <sushant2k1513@gmail.com> Requested-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
James Prestwood authored
The mac80211_hwsim driver does not specify supported cipher types, which in turn enables all ciphers to be supported in software. (see net/mac80211/main.c:ieee80211_init_cipher_suites). Allowing ciphers to be configurable is valuable for simulating older drivers that may not support all ciphers. This patch adds a new attribute: - HWSIM_ATTR_CIPHER_SUPPORT A u32 array/list of supported cipher types This only allows enabling/disabling cipher types listed in the (new) "hwsim_ciphers" array in mac80211_hwsim.c. Any unknown cipher type will result in -EINVAL. Signed-off-by: James Prestwood <james.prestwood@linux.intel.com> [fix some indentation, change to hwsim_known_ciphers(), add error messages, validate length better] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
James Prestwood authored
The mac80211_hwsim driver hard codes its supported interface types. For testing purposes it would be valuable to allow changing these supported types in order to simulate actual drivers than support a limited set of iftypes. A new attribute was added to allow this: - HWSIM_ATTR_IFTYPE_SUPPORT A u32 bit field of supported NL80211_IFTYPE_* bits This will only enable/disable iftypes that mac80211_hwsim already supports. In order to accomplish this, the ieee80211_iface_limit structure needed to be built dynamically to only include limit rules for iftypes that the user requested to enable. Signed-off-by: James Prestwood <james.prestwood@linux.intel.com> [fix some indentation, add netlink error string] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Avoid the need to kfree() the name in many places by moving the name parsing last. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Andrew Zaborowski authored
Let userspace learn about iftype changes by sending a notification when handling the NL80211_CMD_SET_INTERFACE command. There seems to be no other place where the iftype can change: nl80211_set_interface is the only caller of cfg80211_change_iface which is the only caller of ops->change_virtual_intf. Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Martin Willi authored
When a wiphy changes its namespace, all interfaces are moved to the new namespace as well. The network interfaces are properly announced as leaving on the old and as appearing on the new namespace through RTM_NEWLINK/RTM_DELLINK. On nl80211, however, these events are missing for radios and their interfaces. Add netlink announcements through nl80211 when switching namespaces, so userspace can rely on these events to discover radios properly. Signed-off-by: Martin Willi <martin@strongswan.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's nothing much for mac80211 to do, so only pass through the requests with minimal checks and tracing. The driver must call cfg80211's results APIs. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add a new "peer measurement" API, that can be used to measure certain things related to a peer. Right now, only implement FTM (flight time measurement) over it, but the idea is that it'll be extensible to also support measuring the necessary things to calculate e.g. angle-of-arrival for WiGig. The API is structured to have a generic list of peers and channels to measure with/on, and then for each of those a set of measurements (again, only FTM right now) to perform. Results are sent to the requesting socket, including a final complete message. Closing the controlling netlink socket will abort a running measurement. v3: - add a bit to report "final" for partial results - remove list keeping etc. and just unicast out the results to the requester (big code reduction ...) - also send complete message unicast, and as a result remove the multicast group - separate out struct cfg80211_pmsr_ftm_request_peer from struct cfg80211_pmsr_request_peer - document timeout == 0 if no timeout - disallow setting timeout nl80211 attribute to 0, must not include attribute for no timeout - make MAC address randomization optional - change num bursts exponent default to 0 (1 burst, rather rather than the old default of 15==don't care) v4: - clarify NL80211_ATTR_TIMEOUT documentation v5: - remove unnecessary nl80211 multicast/family changes - remove partial results bit/flag, final is sufficient - add max_bursts_exponent, max_ftms_per_burst to capability - rename "frames per burst" -> "FTMs per burst" v6: - rename cfg80211_pmsr_free_wdev() to cfg80211_pmsr_wdev_down() and call it in leave, so the device can't go down with any pending measurements v7: - wording fixes (Lior) - fix ftm.max_bursts_exponent to allow having the limit of 0 (Lior) v8: - copyright statements - minor coding style fixes - fix error path leak Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add a helper function nl_set_extack_cookie_u64() to use a u64 as the netlink extended ACK cookie, to avoid having to open-code it in any users of the cookie. A u64 should be sufficient for most subsystems though we allow for up to 20 bytes right now. This also matches the cookies in nl80211 where I intend to use this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We have a bool and an __le16 called qos, rename the inner __le16 to 'qoshdr' to make it more obvious and to avoid sparse warnings. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We have a macro here that uses an inner variable 'i' that also exists in the outer scope - use '_i' in the macro. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We have a pointer called 'tidstats' that shadows a bool function argument with the same name, but we actually only use it once so just remove the pointer. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This variable shadows something that gets generated inside the tracing macros, which causes sparse to warn. Avoid it so sparse output is more readable, even if it doesn't seem to cause any trouble. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This variable shadows something that gets generated inside the tracing macros, which causes sparse to warn. Avoid it so sparse output is more readable, even if it doesn't seem to cause any trouble. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Edward Cree authored
As added in 3e59020a ("net: bql: add __netdev_tx_sent_queue()"), which see for performance rationale. Signed-off-by: Edward Cree <ecree@solarflare.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Michał Mirosław says: ==================== net: Remove VLAN_TAG_PRESENT from drivers This series removes VLAN_TAG_PRESENT use from network drivers in preparation to removing its special meaning. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-