The function here already has a variable hdr that even
contains the right thing, so the inner scope's hdr variable
that's shadowing the outer one can just be removed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently mac80211 does not inform the driver of the session
block ack timeout when starting a rx aggregation session.
Drivers that manage the reorder buffer need to know this
parameter.
Seeing that there are now too many arguments for the
drv_ampdu_action() function, wrap them inside a structure.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This reverts commit cd37a90b.

Different userspace programs interpreted HWSIM_ATTR_ADDR_TRANSMITTER
and HWSIM_ATTR_ADDR_RECEIVER differently: some expected it to
be an unchanging hardware address that is tied to the radio despite
which address is configured on the interface, while others expected
to be a copy of the address in the frame (the configured address).
The intent of the original authors is unclear.

The latter interpretation doesn't really work properly with multiple
vifs and broadcast frames.  Also, as the TA is already in the
frame, userspace programs can actually support configured addresses
in the former interpretation by mapping between them and the supplied
HWSIM_ATTR_ADDR_TRANSMITTER.

So, in the interest of API stability, revert to the previous mode
of operation and going forward use the former interpretation.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If a packet is received from netlink with the frequency value set it is
checked against the current radio's frequency and discarded if different.
The frequency is also checked against data2->tmp_chan to support the "hw"
off-channel/scan case.
Signed-off-by: NAdam Welle <arwelle@cert.org>
[allow both simultaneously, add locking]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the rate control algorithm messed up then the txrate pointer
here could be NULL - WARN and drop the packet from monitoring.
Signed-off-by: NAmit Khatri <amit.khatri@samsung.com>
Signed-off-by: NRahul Jain <rahul.jain@samsung.com>
[rewrite commit message, add warning]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of using pointers, use sequentially assigned cookies.
This is easier to understand while debugging and also avoids
problems when the pointer is reused for the next allocation.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

VHT can be used with IBSS without needing any additional changes in
mac80211_hwsim, so start claiming support for this to increase test
coverage.
Signed-off-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously, this was done only for Beacon frames, but similar timestamp
update is needed for Probe Response frames to make these more accurately
match the real IEEE 802.11 behavior. Previously, all zeros timestamp was
sent in Probe Response frames.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Typically drivers that implement hardware remain-on-channel will
have to wait for scheduling constraints, so make hwsim also wait
a little bit (only 20ms) before actually starting the operation.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

We had another change to fix this in mac80211, but the hwsim
"hardware" scan should also be fixed. Obviously this one isn't
important since it's not real hardware, but we'd better be
consistent.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Switch everything to the new and more capable implementation of abs().
Mainly to give the new abs() a bit of a workout.

Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The genl_notify function has too many arguments for no real reason - all
callers use genl_info to get them anyway. Just pass the genl_info down to
genl_notify.
Signed-off-by: NJiri Benc <jbenc@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Advertise the capability to send A-MSDU within A-MPDU
in the AddBA request sent by mac80211. Let the driver
know about the peer's capabilities.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NPhil Sutter <phil@nwl.cc>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

During hwsim_init_netlink(), we should call genl_unregister_family()
if failed on netlink_register_notifier() since the genetlink is
already registered.
Signed-off-by: NSu Kang Yin <cantona@cantona.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no reason not to support this, allow it to test
those code paths.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.

This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.

The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Declare that MCS 0-9 are supported for all Rx chains.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously, VHT capabilities and supported MCSs where set for all
bands, although VHT is only allowed on 5.2 GHz band. Fix it.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This support is essentially useless as typically networks are encrypted,
frames will be filtered by hardware, and rate scaling will be done with
the intended recipient in mind. For real monitoring of the network, the
monitor mode support should be used instead.

Removing it removes a lot of corner cases.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For hwsim, the duration field in frames is already not valid for
the common case of HT/VHT MCSes, so there's little point in trying
to keep it accurate for the legacy rates. Enable the fast-xmit code
to allow testing that, although given the dependency on hardware
crypto it will only be enabled in open network configurations.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Jouni reported that certain combinations of hwsim test cases failed,
and we found that beaconing was erroneously enabled too early on any
channel switch, which lead to the BI of 2000 TU from the first test
case to leak into the second one, which then didn't beacon properly.

To fix this, set data->beacon_int to zero when all stop beaconing so
that beaconing cannot be started (which was intended as 'restarted')
elsewhere.

Additionally, Jouni found that due to this 'restart' and the beacon
interval handling station interfaces would also have a needlessly
running beacon timer all the time, of course not doing anything.

To also fix the latter case only use the beacon interval when it's
actually needed, i.e. when beaconing gets enabled.
Reported-by: NJouni Malinen <j@w1.fi>
Tested-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Use the built-in function instead of memset.

Miscellanea:

Add #include <linux/etherdevice.h> where appropriate
Use ETH_ALEN instead of 6
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This allows wpa_supplicant/hostapd to send a vendor command and verify
response to that command and a vendor event.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Due to the checks in get_hwsim_data_ref_from_addr, wmediumd
was only able to use the second mac address (those starting with
0x42).  This is confusing and needlessly limiting, so allow any
configured address.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Correct two problems with the error handling when using the netlink
forwarding API: first, the netlink skb is never freed if nla_put()
fails; and second, genlmsg_unicast() can fail if the netlink socket
is full.  In the latter case, the corresponding data skb is not counted
as a drop and userspace programs like wmediumd will see TCP stalls
due to lost packets.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Contrary to common expectations for an "int" return, these functions
return only a positive value -- if used correctly they cannot even
return 0 because the message header will necessarily be in the skb.

This makes the very common pattern of

  if (genlmsg_end(...) < 0) { ... }

be a whole bunch of dead code. Many places also simply do

  return nlmsg_end(...);

and the caller is expected to deal with it.

This also commonly (at least for me) causes errors, because it is very
common to write

  if (my_function(...))
    /* error condition */

and if my_function() does "return nlmsg_end()" this is of course wrong.

Additionally, there's not a single place in the kernel that actually
needs the message length returned, and if anyone needs it later then
it'll be very easy to just use skb->len there.

Remove this, and make the functions void. This removes a bunch of dead
code as described above. The patch adds lines because I did

-	return nlmsg_end(...);
+	nlmsg_end(...);
+	return 0;

I could have preserved all the function's return values by returning
skb->len, but instead I've audited all the places calling the affected
functions and found that none cared. A few places actually compared
the return value with <= 0 in dump functionality, but that could just
be changed to < 0 with no change in behaviour, so I opted for the more
efficient version.

One instance of the error I've made numerous times now is also present
in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
check for <0 or <=0 and thus broke out of the loop every single time.
I've preserved this since it will (I think) have caused the messages to
userspace to be formatted differently with just a single message for
every SKB returned to userspace. It's possible that this isn't needed
for the tools that actually use this, but I don't even know what they
are so couldn't test that changing this behaviour would be acceptable.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The functions called within the iterators must be called with
tasklets disabled, so use atomic iteration like the rest of
the code and disable tasklets around the whole operation.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

David Binderman reports that the conditions in the first loop
are the wrong way around - checking the array contents before
the size.

Instead of leaving the empty loop there and reordering the two
checks unify it into a single loop that skips over non-matches
and exits after the first match.
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This reverts commit c17aa52c.

It was wrong, IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ
already implies that 160 MHz is supported, as it isn't a bitmap
but rather a value in a 2-bit field.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A properly set alpha2 value consists of two chars that both contain
letters or digits. If no value is set, both chars keep their initial
value zero. Therefore do not send the alpha2 parameter to user space
if either of the characters has been left at its initial zero value.
Signed-off-by: NPatrik Flykt <patrik.flykt@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

HWSIM_CMD_GET_RADIO returns information about a specific radio id or
all of them in response to a dump. Create the netlink skb or use the
one provided by the dump functionality. Use the existing attribute
appending function to fill in the same attributes when creating a
new hwsim radio.

Save alpha2 and struct ieee80211_regdomain in the hwsim data or else
they will be lost in the depths of regulatory infrastructure.
Signed-off-by: NPatrik Flykt <patrik.flykt@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Factor out netlink message attribute appending in order to reuse it
with later code. As a result move netlink skb allocation to the
calling function.
Signed-off-by: NPatrik Flykt <patrik.flykt@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The hwname will always be set if idx is negative (as it's
a u32 read into an s64 it can't overflow either) so we can
remove the unnecessary check for hwname being non-NULL.

This was reported by smatch.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

We can always know the hwname of the radio so use the value
from wiphy.
Signed-off-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This adds support for scanning with random MAC address for
both software and hardware scan.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>

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: NJohannes Berg <johannes.berg@intel.com>

When deleting old radio via HWSIM_CMD_DEL_RADIO then listeners on the
multicast group "config" are informed.
Signed-off-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When adding new radio via HWSIM_CMD_NEW_RADIO then listeners on the
multicast group "config" are informed.

While at it, refactor the configuration parameters to be able to
pass them directly and have fewer function arguments.
Signed-off-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>