Commit Graph

1025 Commits

Author SHA1 Message Date
Adrian Chadd
ba2c1fbc03 Revert the wifi ifnet changes until things are more baked and tested.
* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.
2015-08-08 01:10:17 +00:00
Gleb Smirnoff
79d2c5e857 Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
  the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
  driver about any changes: number of wlan(4) interfaces, number of them
  in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
  driver experiences errors and can not attribute them to any specific
  interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
  now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision:	D2655, D2740
Sponsored by:	Nginx, Inc.
Sponsored by:	Netflix
2015-08-07 11:43:14 +00:00
Adrian Chadd
f7f155fa58 Break out the current 802.11 software scan methods into an indirect table.
In order for drivers to provide an alternate set of scan methods,
these have to finally use an indirection table and all of the calls
in ieee80211_scan.c need to use said table.

For all existing drivers - this is basically a glorified, KBI-breaking
functional no-op.

This is also not the final form - too much functionality is currently
hiding in ieee80211_scan_sw.c that should be in ieee80211_scan.c.
That'll be the target of some follow-up commits.

Note:

* You have to recompile your kernel/drivers after this - the net80211 KBI has
  changed.
* I'm not yet planning on bumping any versioning - I have a few more things
  to shuffle around.

Tested:

* urtwn(4) - STA mode
* Intel 7260 in local repo - overriding the methods and table at
  attach time has the desired effect (ie, all the methods are called,
  but nothing is ever performed.)
2015-06-08 02:35:43 +00:00
Adrian Chadd
32ed410a41 Remove the start-scan call and re-inline it for now. 2015-06-08 00:30:58 +00:00
Adrian Chadd
2108f2a8e7 For now, just default to presenting "found" channels as 11g, not 11b.
The intel 7260 driver under development requires this - the scans come
in as normal frames but with the frequency provided.  The correct method
is to have the driver provide flags (so we can determine if it's 11b
or 11g); this will have to do in the meantime.

Without this, the channel found is 11b, and no ERP (ie "11g") bits
are negotiated with the AP.

This allows the 7260 in 2ghz mode to operate in 11bg, rather than
just 11b.

Tested:

* intel 7260 driver, 11bg channels
2015-06-05 06:49:08 +00:00
Adrian Chadd
3a1da00bd9 Some hostap setups may result in raw frames being transmitted with
no parameters set.  So, don't unconditionally call things.

Thanks to jkim@ for pointing this out!

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-04 23:07:21 +00:00
Adrian Chadd
ff09e23f53 Tag outbound raw 802.11 frames with both the node and an mbuf tag
with the transmit params.

This allows raw 802.11 frames to be queued in the driver if necessary,
rather than requiring it to be direct-dispatched into the hardware.

Tested:

* ath(4), STA mode
* iwn(4), STA mode

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-04 17:54:41 +00:00
Andrew Turner
5148474e8b Fix the build by hiding ieee80211_add_xmit_params and
ieee80211_get_xmit_params from userspace.
2015-06-04 10:55:36 +00:00
Adrian Chadd
9afc11b224 First pass of adding transmit parameters as an option for outbound
802.11 mbufs.

The raw transmit path currently doesn't make it easy to queue
these frames:

* there's no node reference stored in the mbuf, like for the normal
  path, and
* the bpf supplied raw transmit parameters (rate, rts/cts, etc)
  are passed in as an argument, not as an mbuf tag.

In order to support driver queuing of these frames, we need to
be able to put the above into the mbuf before the driver gets it,
so the driver /can/ put it into a queue if needed.

Use an mbuf tag and for now just verbatim copy the bpf parameters
into it.  Later on it may grow to include more options but this
will do for now.

Why would you want to queue raw frames? Well, in the case of
iwn(4), we can't send the firmware frames to transmit before
we hear a beacon - the firmware will consider passive channels
as unavailable until it hears a beacon.  The firmware "passive"
channel state is cleared upon each RXON command, which is sent to
update association status.  So, when we attempt association and
authorisation, the RXON command causes the firmware to clear out
what it's already seen, and so we have to wait for a beacon before
we can transmit.

Before people get overly excited - this alone doesn't "fix" 5GHz
operation - it just makes it (more) possible.

The aim here is to convert all the drivers over to use a raw_xmit()
API that doesn't include the node and params - instead they'd get
those from the mbuf.  Then raw_xmit() becomes just a side-channel
version of the normal transmit path for management traffic.

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-04 06:30:39 +00:00
Gleb Smirnoff
6fe391f44d Move counter.h include into ieee80211_freebsd.h. Should fix build.
Submitted by:	Zilvinas Valinskas <zilvinas.valinskas gmail.com>
2015-05-27 14:05:46 +00:00
Gavin Atkinson
54c8dd3f71 Fix spelling mistake in comment. 2015-05-26 21:50:53 +00:00
Gleb Smirnoff
28da1b56ea Provide ieee80211_get_counter() that sums up ieee802com
errors to the errors of this vap interface.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-26 13:19:05 +00:00
Gleb Smirnoff
81c04d1109 Add two counters to ieee80211com, that will be used to count transmission
or receive errors that can't be associated with any vap.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-26 12:51:14 +00:00
Gleb Smirnoff
92002144c0 Make ieee80211broadcastaddr global, so that drivers or other
code may use it and not paste.
2015-05-26 12:40:27 +00:00
Gleb Smirnoff
7fc10b6b41 Reduce diff before functional changes:
- Use ic_name instead of if_xname.
- Formatting cleanup.
2015-05-26 12:06:36 +00:00
Adrian Chadd
b6b2fb599b Migrate the scan iterator lock typedefs out into ieee80211_freebsd.h.
This removes the final piece of freebsd-specific locking that snuck
into the tree - it's now all inside ieee80211_freebsd.h.
2015-05-26 04:37:59 +00:00
Adrian Chadd
71f9dd120b Migrate the 802.11s locks out into ieee80211_freebsd.h, so they can be
defined as platform specific bits.

This is to help make OS portability easier.
2015-05-26 04:25:11 +00:00
Gleb Smirnoff
e14a2a4cf4 Cleanup compat shims for FreeBSD versions that predate 10.0-RELEASE.
There are no plans to merge anything save a trivial bugfix to stable/9.

Discussed with:	adrian
2015-05-25 20:06:49 +00:00
Gleb Smirnoff
272f6ade9b Change three methods in struct ieee80211com, namely ic_updateslot,
ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com,
not to the ifnet.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 19:53:29 +00:00
Gleb Smirnoff
a41c90e644 When sending RTM_IEEE80211_CSA, RTM_IEEE80211_RADAR, RTM_IEEE80211_CAC and
RTM_IEEE80211_RADIO routing messages, broadcast them on all vap interfaces
instead of sending them on parent.

Reviewed by:	adrian
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 19:48:48 +00:00
Adrian Chadd
b9b533891f Convert malloc/free back to #define's, as part of OS portability work.
DragonflyBSD uses the FreeBSD wireless stack and drivers.  Their malloc()
API is named differently, so they don't have userland/kernel symbol
clashes like we do (think libuinet.)

So, to make it easier for them and to port to other BSDs/other operating
systems, start hiding the malloc specific bits behind defines in
ieee80211_freebsd.h.

DragonflyBSD can now put these portability defines in their local
ieee80211_dragonflybsd.h.

This should be a great big no-op for everyone running wifi.

TODO:

* kill M_WAITOK - some platforms just don't want you to use it
* .. and/or handle it returning NULL rather than waiting forever.
* MALLOC_DEFINE() ?
* Migrate the well-known malloc names (eg M_TEMP) to net80211
  namespace defines.
2015-05-25 19:18:16 +00:00
Adrian Chadd
c79f192c09 Begin plumbing ieee80211_rx_stats through the receive path.
Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260
series, etc) support doing a lot of things in firmware.  This includes but
isn't limited to things like scanning, sending probe requests and receiving
probe responses.  However, net80211 doesn't know about any of this - it still
drives the whole scan/probe infrastructure itself.

In order to move towards suppoting smart NICs, the receive path needs to
know about the channel/details for each received packet.  In at least
the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet)
it will do the scanning, power-save and off-channel buffering for you -
all you need to do is handle receiving beacons and probe responses on
channels that aren't what you're currently on.  However the whole receive
path is peppered with ic->ic_curchan and manual scan/powersave handling.
The beacon parsing code also checks ic->ic_curchan to determine if the
received beacon is on the correct channel or not.[1]

So:

* add freq/ieee values to ieee80211_rx_stats;
* change ieee80211_parse_beacon() to accept the 'current' channel
  as an argument;
* modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats;
* add a new method - ieee80211_lookup_channel_rxstats() - that looks up
  a channel based on the contents of ieee80211_rx_stats;
* if it exists, use it in the mgmt path to switch the current channel
  (which still defaults to ic->ic_curchan) over to something determined
  by rx_stats.

This is enough to kick-start scan offload support in the Intel 7260
driver that Rui/I are working on.  It also is a good start for scan
offload support for a handful of existing NICs (wpi, iwn, some USB
parts) and it'll very likely dramatically improve stability/performance
there.  It's not the whole thing - notably, we don't need to do powersave,
we should not scan all channels, and we should leave probe request sending
to the firmware and not do it ourselves.  But, this allows for continued
development on the above features whilst actually having a somewhat
working NIC.

TODO:

* Finish tidying up how the net80211 input path works.
  Right now ieee80211_input / ieee80211_input_all act as the top-level
  that everything feeds into; it should change so the MIMO input routines
  are those and the legacy routines are phased out.

* The band selection should be done by the driver, not by the net80211
  layer.

* ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels
  for now - this is enough for scanning, but not 100% true in all cases.
  If we ever need to handle off-channel scan support for things like
  static-40MHz or static-80MHz, or turbo-G, or half/quarter rates,
  then we should extend this.

[1] This is a side effect of frequency-hopping and CCK modes - you
    can receive beacons when you think you're on a different channel.
    In particular, CCK (which is used by the low 11b rates, eg beacons!)
    is decodable from adjacent channels - just at a low SNR.
    FH is a side effect of having the hardware/firmware do the frequency
    hopping - it may pick up beacons transmitted from other FH networks
    that are in a different phase of hopping frequencies.
2015-05-25 16:37:41 +00:00
Gleb Smirnoff
151cc3ad26 Add void * member to struct ieee80211com, so that drivers can obtain their
softc without going through the struct ifnet.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 15:08:38 +00:00
Gleb Smirnoff
8088fdf578 Remove unused include. 2015-05-25 14:54:10 +00:00
Gleb Smirnoff
c8f5794e0a Use name from ieee80211com instead of parent ifnet, in debugging printfs.
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 14:30:44 +00:00
Gleb Smirnoff
c8550c0278 Make net80211 drivers supply their device name to the net80211 layer, so
that the latter doesn't need to go through struct ifnet to get their name.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-05-25 13:51:13 +00:00
Andrey V. Elsukov
79077edc1a Properly update TX statistics for wlan(4).
ieee80211_pwrsave() can fail due to queue overflow, check its return code
and increment oerrors counter when it fails. Also handle more error cases
and update oerrors counter when we don't send mbuf due to some errors.
Return ENETDOWN when parent interface isn't ready. Update obytes and omcasts
counters in corresponding places.

PR:		184626
Differential Revision:	https://reviews.freebsd.org/D2621
Reviewed by:	adrian
MFC after:	1 week
2015-05-23 09:49:40 +00:00
Jung-uk Kim
fd90e2ed54 CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten
years for head.  However, it is continuously misused as the mpsafe argument
for callout_init(9).  Deprecate the flag and clean up callout_init() calls
to make them more consistent.

Differential Revision:	https://reviews.freebsd.org/D2613
Reviewed by:	jhb
MFC after:	2 weeks
2015-05-22 17:05:21 +00:00
Gleb Smirnoff
be887eca0b EVENTHANDLER_REGISTER() doesn't fail. 2015-05-20 09:42:33 +00:00
Adrian Chadd
c3ebe01919 Do not check sequence number for QoS Null frames; set it for generated QoS Null
frames to 0

From IEEE Std. 802.11-2012, 8.3.2.1 "Data frame format", p. 415 (513):
"The Sequence Control field for QoS (+)Null frames is ignored by the receiver
upon reception."

At this moment, any <mode>_input() function interprets them as regular QoS data
frames with TID = 0. As a result, stations, that use another TX sequence for
QoS Null frames (e.g. wpi(4), where (QoS) Null frames are generated by the
firmware), may experience significant packet loss with any other NIC in hostap
mode.

Tested:

* wpi(4) (author)
* iwn(4) - Intel 5100, STA mode (me)

PR:		kern/200128
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2015-05-12 16:55:50 +00:00
Adrian Chadd
2808a02bf4 Prepare for supporting driver-overridden curchan when submitting scan
results.

Right now the scan infrastructure assumes the channel is under net80211
control, and that when receiving beacon frames for scanning, the
current channel is indeed what ic_curchan is set to.

But firmware NICs with firmware scan support need more than this -
they can do background scans whilst hiding the off-channel behaviour
from net80211.  Ie, net80211 still thinks everything is associated
and on the main channel, but it's getting scan results from all the
background traffic.

However sta_add() pays attention to ic_curchan and discards scan
results that aren't on the right channel.  CCK beacon frames can be
decoded from adjacent channels so the receive path and sta_add
discard these as appropriate.  This is fine for software scanning
like for ath(4), but not for firmware NICs.  So with those, the
whole concept of background firmware scanning won't work without
major hacks (eg, overriding ic_curchan before calling the beacon
input / scan add.)

As part of my scan overhaul, modify sta_add() and the scan_add()
APIs to take an explicit current channel.  The normal RX path
will set it to ic_curchan so it's a no-op.  However, drivers may
decide to (eventually!) override the scan method to set the
"right" current channel based on what the firmware reports the
scan state is.

So for example, iwn, rsu and other NICs will eventually do this:

* driver issues scan start firmware command;
* firmware sends a "scan start on channel X" notify;
* firmware sends a bunch of beacon RX's as part of
  the scan results;
* .. and the driver will replace scan_add() curchan with channel X,
  so scan results are correct.
* firmware sends a "scan start on channel Y" notify;
* firmware sends more beacons...
* .. the driver replaces scan_add() curchan with channel Y.

Note:

* Eventually, net80211 should eventually grow the idea of a per-packet
  current channel.  It's possible in various modes (eg WAVE, P2P, etc)
  that individual frames can come in from different channels and that
  is under firmware control rather than driver/net80211 control, so
  we should support that.
2015-05-10 22:07:53 +00:00
Adrian Chadd
def4ea7f78 Fix typo introduced in previous commit.
PR:		kern/199632
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2015-05-10 21:05:32 +00:00
Adrian Chadd
bfca9c9400 Turn ieee80211_start_scan_locked() into a swscan module private method.
It turns out that ieee80211_start_scan_locked() is only ever called by
the swscan code and it won't likely be required by firmware scanning
implementations.

So, don't bother keeping it in ieee80211_scan.c and it likely won't
become an API call.

Tested:

* Intel 5100, STA mode
* AR5416, STA mode
2015-05-10 06:59:34 +00:00
Adrian Chadd
3265af355a Attempt to address Bug #176201 - don't advertise what the AP announced
to us. Instead, advertise what we can do based on what the AP says and what
we're capped at by the VAP settings.

For non-STA modes we still advertise what our VAP settings are.

It may be that I've over-complicated this and instead of capping things
we can just always announce what we're capable of.  But this should at least
stop the blatantly wrong handling of A-MPDU parameters.

(I'll happily simplify things if someone can dig up a replacement, better
compliant behaviour.)

PR:		kern/176201
2015-05-10 06:57:53 +00:00
Adrian Chadd
fc4d77c3ce Fix string concatenation - "wlan_##name" -> "wlan_" #name
PR:		kern/197623
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2015-05-04 00:47:22 +00:00
Adrian Chadd
364ee1250b Use bssid validation for data frames only + add RUN -> RUN state transition
However, IBSS merge will be performed only if a driver calls
ieee80211_ibss_merge(); so, this applicable to the ath(4) only.
Also, this should fix bug 167870.

PR:		kern/199632
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2015-05-04 00:32:10 +00:00
Adrian Chadd
eca3b4fc14 Add node_clear_keyixmap() and use it in the ieee80211_free_node() / node_reclaim().
PR:		kern/199672
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2015-05-04 00:29:19 +00:00
Adrian Chadd
8a0558317e Remove old iv_bss entry from the node table
This may happen on RUN -> SCAN -> RUN -> SCAN state transition:

1. RUN -> SCAN: in ieee80211_sta_join1(): iv_bss will be moved to obss,
   refcnt will be reduced by 2 (default minimum).

Now, if old iv_bss have some extra references (for example, from
unacknowledged probe responses), it will not be freed and will stay
in the node table.

2. SCAN -> RUN.

3. If old iv_bss will not be deleted by the time when the next RUN -> SCAN
   state transition occurs, then sta_leave() will reduce it's reference
   counter once more. As a result, two last users will free it -> this will
   lead to kernel panic.

In this patch old iv_bss entry is explicitly removed from the node table in
ieee80211_sta_join1() (as a result, it will not be processed by sta_leave()).

PR:		kern/199676
Differential Revision:	Andriy Voskoboinyk <s3erios@gmail.com>
2015-05-03 22:28:42 +00:00
Eitan Adler
f05e369aa2 iwn, wlan: fix typos
Fxi tow typos

Obtained from:	DragonFlyBSD
MFC after:	3 days
2015-04-10 20:55:17 +00:00
Adrian Chadd
83249cea34 Initialise the pps / packet tracking timestamp so 11n aggregation works again.
There's a bug in the ticks handling where when initialised at '0', once
the ticks counter wrapped the comparison math would never trigger.
The pps calculation would never happen, and thus aggregation was never
enabled.

It manifests itself as "oh you only get 11n transmit aggregation for the
first 10 minutes of uptime."

I'm sure there are other ticks related issues lurking in net80211.

Tested:

* ath / iwn, both with 'wlandebug +11n' and a little bit of iperf to
  kick off the transmit A-MPDU negotiation once the pps gets high enough.
2015-03-22 17:54:00 +00:00
Ian Lepore
6ef6968de5 Use SYSCTL_OUT_STR() to return strings.
PR:		195668
2015-03-14 21:41:00 +00:00
Adrian Chadd
b83391bf44 Fix kern/196290 - don't announce 11n HTINFO rates if the channel is
configured as 11b.

This came up when debugging other issues surrounding scanning and
channel modes.

What's going on:

* The VAP comes up as an 11b VAP, but on an 11n capable NIC;
* .. it announces HTINFO and MCS rates;
* The AP thinks it's an 11n capable device and transmits 11n frames
  to the STA;
* But the STA is in 11b mode, and thus doesn't receive/ACK the frames.

It didn't happen for the ath(4) devices as the AR5416/AR9300 HALs
unconditionally enable MCS frame reception, even if the channel
mode is not 11n.  But the Intel NICs are configured in 11b/11a/11g
modes when doing those, even if 11n is enabled and available.

So, don't announce 11n capabilities if the VAP isn't on an 11n
channel when sending management assocation request / reassociation
request frames.

TODO:

* Lots more testing - 11n should be "upgraded" after association,
  and I just want to make sure I haven't broken 11n upgrade.
  I shouldn't have - this is only happening for /sending/ association
  requests, which APs aren't doing.

Tested:

* ath(4) APs (AR9331, AR7161+AR9280, AR934x)
* AR5416, STA mode
* Intel 5100, STA mode

PR:		kern/196290
2015-02-27 04:45:47 +00:00
Adrian Chadd
21969c6c24 Switch around the order of static inline to be in line with how it's
used elsewhere, and to keep gcc-4.7 happy.

This is a request from the DragonflyBSD project.
2015-01-11 18:43:45 +00:00
Adrian Chadd
a1cbd04334 Global-ify channel_type() - this fixes non-debug net80211 builds. 2015-01-06 18:25:10 +00:00
Adrian Chadd
cc6dd788c6 Refactor and split out the net80211 software scan engine from the rest
of the scan API.

The eventual aim is to have 'ieee80211_scan.c' have the net80211 and
driver facing scan API to start, finish and continue doing scanning
while 'ieee80211_swscan.c' implements the software scanner that
runs the scan task, handles probe request/reply bits, configures
the VAP off-channel, changes channel and does the scanning bits.

For NICs that do no scanning at all, the existing code is needed.
ath(4) and most of the other NICs (dumb USB ones in particular)
do little to no scan offload - it's all done in software.

Some NICs may do single channel at a time scanning; I haven't really
checked them out in detail.

iwn(4), the upcoming 7260 driver stuff, the new Qualcomm Atheros
11ac chipsets and the Atheros mobile/USB full-offload chips all
have complete scan engines in firmware.  We don't have to drive
any of it at all - the firmware just needs to be told what to scan,
when to scan, how long to scan.  It'll take care of going off
channel, pausing TX/RX appropriately, sending sleep notification
to the AP, sending probe requests and handling probe responses.
It'll do passive/active scan itself.  It's almost completely
transparent to the network stack - all we see are scan notifications
when it finishes scanning each channel and beacons/probe responses
when it does its thing.  Once it's done we get a final notification
that the scan is complete, with some scan results in the message.
The iwn(4) NICs handle doing active scanning too as an option
and will handle waiting appropriately on 5GHz passive channels
before active scanning.

There's some more refactoring, tidying up and lock assertions to
sprinkle around to tidy this whole thing up before I turn swscan.c
into another set of ic methods to override by the driver or
alternate scan module.  So in theory this is all one big no-op
commit.  In theory.

Tested:

* iwn(4) 5200, STA mode
* ath(4) 6205, STA mode
* ath(4) - various NICs, AP mode
2015-01-06 02:08:45 +00:00
Robert Watson
ed6a66ca6c To ease changes to underlying mbuf structure and the mbuf allocator, reduce
the knowledge of mbuf layout, and in particular constants such as M_EXT,
MLEN, MHLEN, and so on, in mbuf consumers by unifying various alignment
utility functions (M_ALIGN(), MH_ALIGN(), MEXT_ALIGN() in a single
M_ALIGN() macro, implemented by a now-inlined m_align() function:

- Move m_align() from uipc_mbuf.c to mbuf.h; mark as __inline.
- Reimplement M_ALIGN(), MH_ALIGN(), and MEXT_ALIGN() using m_align().
- Update consumers around the tree to simply use M_ALIGN().

This change eliminates a number of cases where mbuf consumers must be aware
of whether or not mbufs returned by the allocator use external storage, but
also assumptions about the size of the returned mbuf. This will make it
easier to introduce changes in how we use external storage, as well as
features such as variable-size mbufs.

Differential Revision:	https://reviews.freebsd.org/D1436
Reviewed by:	glebius, trasz, gnn, bz
Sponsored by:	EMC / Isilon Storage Division
2015-01-05 09:58:32 +00:00
Adrian Chadd
1de34f860e Update ieee80211_sta_tim_notify() to do double duty - handle STA sleep
to awake transition as well as handle waking up a VAP in STA powersave
mode if it's in bgscan.

This was a reasonably hairy bug to try and figure out and it became
more obvious because of stuff I've done.

Specifically:

* a NIC would go into bgscan mode - either because of a bgscan timer
  or wpa_supplicant asked it to;
* the AP would indicate there's traffic for the STA by setting the TIM
  bitmap bit for it;
* mindwell would be met during scan, so it'd wake up and break out of
  the scan loop in scan_task(), but
* because the scan wasn't completed, it wouldn't bring the VAP out of
  STA mode powersave (so it wouldn't tell the AP about it and it would
  block VAP TX);
* .. but because we kept seeing the TIM bit set, ic->ic_lastdata was
  being constantly updated, and ..
* bgscancont() would thus never say "yes we can continue a bgscan"
  so the bgscan would hang and never make progress.

Now, I do see this particular state occur on iwn(4) - /however/ -
this NIC has the firmware call ieee80211_scan_next() once the firmware
scan for that channel has completed.  This has the effect of moving
the scan along to the next channel.  I do see the debug that I'm adding
where we see a beacon with a TIM bit set whilst we're in bgscan, so
the condition about waking up to receive traffic is triggering.
It just won't cause a hang.

For other NICs - all of the USB ones and at least ath(4) -
ieee80211_scan_next() / ieee80211_scan_done() isn't called.
So it relies upon the mindwell timer, the beacon receive and the
beacon / probe response -> ieee80211_add_scan() to move along
the scan state.

In the above case, mindwell triggered, there's no beacons triggering
the scan_add code to move things along, and we weren't waking things
up when seeing the TIM set for us.  So it just hung until the interface
was dropped.

So, the short-term fix here is to do what the comment in scan_task()
says - if we are in bgscan mode and we see our TIM bit set, just wake
up the VAP.  If it's already awake then it's a nop.  If we're awake
then we transition to awake and handle the traffic.  Once there's no
TX or RX traffic going on, ic->ic_lastdata won't be updated anymore
and bgscancont() will continue.

This was triggered more often after my initial SLEEP state handling
for software sleep states - because now I update ic->ic_lastdata
upon seeing a TIM bit set, not just the RX of the subsequent traffic.
That's needed so the thing doesn't ping-pong up and down between
seeing the TIM bit set, sending the "I'm awake" NULL data frame, and
starting to receive data from the AP.

I'd like to subsequently split ic_lastdata into two - one for TX and
one for RX - so it becomes easier to use the correct one (or both!)
when making decisions like whether to scan, go to sleep, etc.

I'd appreciate this getting some further testing.

Tested:

* rsu(4), STA mode, bgscan on
* iwn(4), STA mode, bgscan on
2014-12-21 04:58:45 +00:00
Adrian Chadd
3b00b9a60a Break out the unicast/multicast TIM bit setting into "set something
that indicates we have traffic" bit and a "do something if we have
traffic bit."

I'm going to be fleshing out this stuff more over time and it'll make
more sense to have it broken out into two pieces here.
2014-12-21 04:48:54 +00:00
Adrian Chadd
2c6179401b Add more debugging to try and track down this scan hang nonsense. 2014-12-21 01:15:55 +00:00
Adrian Chadd
f13a4d33ef Add some more debugging to the scan cancel methods - I'd like to see
what situations would cause the scan cancel's to not complete.
2014-12-20 23:41:37 +00:00