- 26 Nov, 2012 19 commits
-
-
Johannes Berg authored
In some cases, e.g. probe_status, there were spaces missing so the trace output was confusing. Also make it more like mac80211 when printing netdevs/wiphys to make reading a combined log easier. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The frequencies will be printed when actually doing the scan, and the IEs can be captured on the hwsim0 monitor. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the number of channels is > 1, which means that hwsim will use mac80211 channel contexts, it can also advertise VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add definitions for the VHT MCS support values that are used to indicate, for each number of streams (1 through 8) which MCSes are supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
To achieve this, limit the number of retries to 31 (instead of 255) and use the three bits that are then free for VHT flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add support to mac80211 for having drivers report received VHT MCS information. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add support for reporting and calculating VHT MCSes. Note that I'm not completely sure that the bitrate calculations are correct, nor that they can't be simplified. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Change nl80211 to support specifying a VHT (or HT) using the control channel frequency (as before) and new attributes for the channel width and first and second center frequency. The old channel type is of course still supported for HT. Also change the cfg80211 channel definition struct to support these by adding the relevant fields to it (and removing the _type field.) This also adds new helper functions: - cfg80211_chandef_create to create a channel def struct given the control channel and channel type, - cfg80211_chandef_identical to check if two channel definitions are identical - cfg80211_chandef_compatible to check if the given channel definitions are compatible, and return the wider of the two This isn't entirely complete, but that doesn't matter until we have a driver using it. In particular, it's missing - regulatory checks on the usable bandwidth (if that even makes sense) - regulatory TX power (database can't deal with it) - a proper channel compatibility calculation for the new channel types Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Instead of passing a channel pointer and channel type to all functions and driver methods, pass a new channel definition struct. Right now, this struct contains just the control channel and channel type, but for VHT this will change. Also, add a small inline cfg80211_get_chandef_type() so that drivers don't need to use the _type field of the new structure all the time, which will change. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
As mwifiex (and mac80211 in the software case) are the only drivers actually implementing remain-on-channel with channel type, userspace can't be relying on it. This is the case, as it's used only for P2P operations right now. Rather than adding a flag to tell userspace whether or not it can actually rely on it, simplify all the code by removing the ability to use different channel types. Leave only the validation of the attribute, so that if we extend it again later (with the needed capability flag), it can't break userspace sending invalid data. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If ieee80211_prep_channel() decides that HT should be disabled (because the HT IEs from the AP were invalid) it will set the IEEE80211_STA_DISABLE_HT to not send HT capabilities to the AP when associating. If this happens during authentication, the flag will be lost and we send HT frames, even if the channel config was set up for non-HT. This can lead to issues. Fix this by always resetting the ifmgd flags to zero when the channel context is released so that the flag resetting in ieee80211_mgd_assoc() isn't necessary. To make the code a bit easier move the call to release the channel in ieee80211_set_disassoc() to the end of the function together with the flag resetting (which needs to be at the end to avoid timers setting flags.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Marco Porsch authored
Use shortcut pointer instead where it is appropriate. Signed-off-by: Marco Porsch <marco.porsch@etit.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Marco Porsch authored
Return early if not a QoS Data frame. Give proper documentation. Signed-off-by: Marco Porsch <marco.porsch@etit.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Marco Porsch authored
Signed-off-by: Marco Porsch <marco.porsch@etit.tu-chemnitz.de> [prefix with IEEE80211_] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Antonio Quartulli authored
The debug message has to be printed also for an Auth message with auth_sequence != 1. This helps understanding whether the two Auth messages are exchanged correctly or not. Signed-off-by: Antonio Quartulli <antonio@open-mesh.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Antonio Quartulli authored
It does not make sense to keep a station alive if it is not authorised at all. If IBSS/RSN is used it could also be the case that something went wrong during the keys exchange and the stations ended up in a not recoverable state. By not updating last_rx we are giving the station a chance to be deleted and to start the key exchange once again from scratch. Signed-off-by: Antonio Quartulli <antonio@open-mesh.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arend van Spriel authored
The function cfg80211_get_p2p_attr() can fail and returns a negative error code. However, the return type is unsigned int. The largest positive number is determined by desired_len variable in the function, which is u16. So changing the return type to int to allow easy error checking. Also change the type for the attribute to enum for improved type checking. Signed-off-by: Arend van Spriel <arend@broadcom.com> [fix indentation, don't use u8 attr variable] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 23 Nov, 2012 5 commits
-
-
Johannes Berg authored
Currently, mac80211 checks the DS params IE if present and uses it for the (primary) BSS channel, instead of the one that the frame was received on. This is particularly useful in the 2.4 GHz band since a frame is often received on one of the adjacent channels due to overlap. Move this code to cfg80211 so other drivers also do this. Additionally, on 5 GHz, in particular with some (possibly) upcoming changes in 802.11ai and duplicate transmissions when wider channels are used, something similar happens. So if present, also use the (primary) channel information contained in the HT operation IE. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the AP doesn't support HT, or more importantly if it does but we have to disable it because its IEs are broken, don't advertise HT support in our association request. Otherwise, we configure our channel to be a 20 MHz non-HT channel but the AP might still think we support HT, or even 40 MHz. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Since the 11n spec amendment was rolled into the 2012 version, "11n" no longer makes sense. Use "HT" instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the driver doesn't support 40 MHz channels, then mac80211 erroneously sets number of RX chains to one although the number of chains is independent of the support for 40 MHz channels. Fix this by checking the 40 MHz support only for the code that sets the 40 MHz channel not the complete HT code block. This also means the HT20 channel type will always be set in the changed code block so there's no need to set it in case we override the AP due to invalid IEs in the probe response/beacon. The indentation is a bit quirky, but I'm rewriting this code for VHT support so this will change again very soon. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The radiotap vendor area in the skb head must be skipped and accounted for in a few functions until it is removed. I missed this in my patch, so a few places use this data as though it was the 802.11 header, fix these places. Reported-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Tested-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 21 Nov, 2012 1 commit
-
-
Sujith Manoharan authored
Provide drivers with hooks to create debugfs files when a new station is added. This would help drivers to take advantage of mac80211's station list infrastructure and not maintain tedious station management code internally. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> [ifdef inline wrapper functions] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 20 Nov, 2012 1 commit
-
-
Johannes Berg authored
Sujith reported warnings with suspend/resume due to channel contexts. When I looked into it, I realised that the code was completely broken as it unassigned the channel contexts when suspending, which actually means they are destroyed. Eliad Peller then pointed out that we also need to remove the channel contexts from the driver. When I looked into this, I also noticed that the code isn't handling the virtual monitor interface correctly (if it exists.) Fix this by calling just the driver methods (if they are implemented) instead of using the channel context management code. Also add reconfiguration for the virtual monitor interface. Reported-by: Sujith Manoharan <sujith@msujith.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 19 Nov, 2012 6 commits
-
-
Eliad Peller authored
Drivers (e.g. wl12xx) might need to know the vif to roc on (mainly in order to configure the rx filters correctly). Add the vif to the op params, and update the current users (iwlwifi) to use the new api. Signed-off-by: Eliad Peller <eliad@wizery.com> [fix hwsim] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jouni Malinen authored
The NL80211_CMD_TDLS_OPER command was previously used only for userspace request for the kernel code to perform TDLS operations. However, there are also cases where the driver may need to request operations from userspace, e.g., when using security on the AP path. Add a new cfg80211 function for generating a TDLS operation event for drivers to request a new link to be set up (NL80211_TDLS_SETUP) or an existing link to be torn down (NL80211_TDLS_TEARDOWN). Drivers can optionally use these events, e.g., based on noticing data traffic being sent to a peer station that is seen with good signal strength. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
In some cases, in particular for experimentation, it can be useful to be able to add vendor namespace data to received frames in addition to the normal radiotap data. Allow doing this through mac80211 by adding fields to the RX status descriptor that describe the data while the data itself is prepended to the frame. Also add some example code to hwsim, but don't enable it because it doesn't use a proper OUI identifier. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Introduce IEEE80211_NUM_TIDS in the generic 802.11 header file and use it in place of STA_TID_NUM and NUM_RX_DATA_QUEUES which are both really the number of TIDs. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Instead of hardcoding its value (6), use the constant. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arend van Spriel authored
During testing our mac80211 driver a fatal error occurred which was signalled to mac80211. Upon performing the reconfiguration of the device a WARN_ON was triggered. This warning checked the return value of drv_add_chanctx(). However, this returns -EOPNOTSUPP when the driver does not provide the callback. As the callback is optional better check it is defined before calling drv_add_chanctx(). Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 13 Nov, 2012 1 commit
-
-
Thomas Pedersen authored
Allow drivers to indicate their mactime is at RX completion and adjust for this in mac80211. Also rename the existing RX_FLAG_MACTIME_MPDU to RX_FLAG_MACTIME_START to clarify its intent. Based on similar code by Johannes Berg. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> [fix docs, atheros drivers] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 12 Nov, 2012 1 commit
-
-
Amitkumar Karwar authored
wpa_supplicant will do OBSS scan for drivers that implement auth/assoc API. Drivers that implement nl80211 connect API (rather than auth/assoc) may need wpa_supplicant to do this as well. Add a new feature flag to inform it (wpa_s) that a driver needs wpa_supplicant to do OBSS scans. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 09 Nov, 2012 5 commits
-
-
Johannes Berg authored
Since channel contexts are usually present before stations can be added to an interface, reassign before stations them in reconfiguration as well. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
During hardware restart, all interfaces are iterated even though they haven't been re-added to the driver, document this behaviour. The same also happens during resume, which is even more confusing since all of the interfaces were previously removed from the driver. Make this optional so drivers relying on the current behaviour can still use it, but to let drivers that don't want this behaviour disable it. Also convert all API users, keeping the old semantics except in hwsim, where the new normal ones are desired. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When the driver requests a restart (reconfiguration) it gets all the normal method calls, but can't really tell why they're happening. Call a new restart_complete op in the driver when the restart completes, so it could keep its own state about the restart and clear it there. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Clearly the tracepoint drv_offchannel_tx was forgotten when that functionality was removed, remove it now. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Add a debugfs file showing which HW queues were allocated to a virtual interface, including the CAB queue for AP interfaces. Change-Id: I486924e961b6ad6785a79db09620919ee644e703 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 07 Nov, 2012 1 commit
-
-
Johannes Berg authored
One error path in ieee80211_subif_start_xmit() will double-free the SKB. Set it to NULL to prevent that. This issue was introduced by my channel context changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-