Commit Graph

1051 Commits

Author SHA1 Message Date
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
Adrian Chadd
92c59ab94f Document where in scan_task the scan state can change, and potentially
deal/log a warning if the scan flags change during one of those race
windows.

It's highly likely that I need to actually sit down and replace this
scan infrastructure at some point.  It has some other side effects too -
the scan task is a blocking task scheduled in the net80211 taskqueue;
so drivers that use this taskqueue have other things not run.  Eek.

If you see this printf happen then please let me know!
2014-12-20 19:41:31 +00:00
Adrian Chadd
de981aecde Make ieee80211_add_ssid() public.
Some drivers use private copies of this.

PR:		kern/196116
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
2014-12-19 01:39:58 +00:00
Adrian Chadd
9c75c3d4ba Fix the scan handling for 11b->11g upgrades in a world where, well,
it's not just 11b/11g.

The following was happening, and it's quite .. annoyingly grr-y.

* create vap, setup wpa_supplicant with no bgscanning, etc - there's
  no call to ieee80211_media_change, so vap->iv_des_mode is
  IEEE80211_MODE_AUTO;
* do ifconfig wlan0 scan - same thing, media_change doesn't get called,
  iv_des_mode stays as auto.
* But then, run wpa_cli and do 'scan' - it'll do a media change.
* if you're on 11ng, vap->iv_des_mode gets changed to IEEE80211_MODE_11NG
* Then makescanlist() is called.  There's a block of code that gets
  called if iv_des_mode != IEEE80211_MODE_AUTO, and it does this:

		if (vap->iv_des_mode != IEEE80211_MODE_11G ||
			    mode != IEEE80211_MODE_11B)
			continue;
		mode = IEEE80211_MODE_11G;	/* upgrade */

* .. now, iv_des_mode is not IEEE80211_MODE_11G, so it always runs
  'continue'
* .. and thus the scan list stays empty and no further channel
  scans occur. Ever.(1)

If you then disassociate and try associating to something, your
scan table has likely been purged / aged out and you'll never
see anything in the scan list.

(1) You need to do 'ifconfig wlan0 mode auto' or just destroy/re-create
    the VAP to get working wireless again.

Tested:

* iwn(4) - intel 5300 wifi; STA mode; using wpa_supplicant; bgscan
  enabled -and- wpa_supplicant scanning.

Thanks to:

* Everyone who kept poking me about this and wondering why the hell
  their wifi would eventually stop seeing scan lists.  Grr.
  I eventually snapped this evening and dug back into this code.
2014-12-18 05:17:18 +00:00
Hans Petter Selasky
f0188618f2 Fix multiple incorrect SYSCTL arguments in the kernel:
- Wrong integer type was specified.

- Wrong or missing "access" specifier. The "access" specifier
sometimes included the SYSCTL type, which it should not, except for
procedural SYSCTL nodes.

- Logical OR where binary OR was expected.

- Properly assert the "access" argument passed to all SYSCTL macros,
using the CTASSERT macro. This applies to both static- and dynamically
created SYSCTLs.

- Properly assert the the data type for both static and dynamic
SYSCTLs. In the case of static SYSCTLs we only assert that the data
pointed to by the SYSCTL data pointer has the correct size, hence
there is no easy way to assert types in the C language outside a
C-function.

- Rewrote some code which doesn't pass a constant "access" specifier
when creating dynamic SYSCTL nodes, which is now a requirement.

- Updated "EXAMPLES" section in SYSCTL manual page.

MFC after:	3 days
Sponsored by:	Mellanox Technologies
2014-10-21 07:31:21 +00:00
Gleb Smirnoff
dea4512157 Mechanically convert to if_inc_counter(). 2014-09-19 09:20:55 +00:00
Adrian Chadd
ebb1240823 After much toying around with this AMRR initial rate stuff,
I've decided that for 11n rates it's best to start (very) low and work
our way up.

So, from now on, the initial rate for AMRR 11n is MCS4.
It doesn't try MCS12 or MCS20 - at low signal strengths those don't
work very well at all.

AMRR will step the rate control up over time if things work out better.

Tested:

* Intel 5100
* Intel 5300 (using local diffs to test out 3x3 stream support)
2014-08-20 09:10:03 +00:00
Adrian Chadd
31f92dec23 Undo r195846 for now - allow raw frame transmit in monitor mode.
The original commit was supposed to stop the ability to do raw frame
injection in monitor mode to arbitrary channels (whether supported
by regulatory or not) however it doesn't seem to have been followed
by any useful way of doing it.

Apparently AHDEMO is supposed to be that way, but it seems to require
too much fiddly things (disable scanning, set a garbage SSID, etc)
for it to actually be useful for spoofing things.

So for now let's just disable it and instead look to filter transmit
in the output path if the channel isn't allowed by regulatory.
That way monitor RX works fine but TX will be blocked.

I don't plan on MFC'ing this to -10 until the regulatory enforcement
bits are written.
2014-08-10 08:35:42 +00:00
Ian Lepore
daa963252e Use logical rather than bitwise OR in if() expression. 2014-04-26 23:22:49 +00:00
Adrian Chadd
f3b04ec629 Add a SLEEP->SCAN transition. Without this a disassociate or scan
request during SLEEP results in a hang.

Whilst I'm here, add in some disabled code that will transition to RUN
if there's multicast traffic.  It's not needed for Atheros hardware but
it may be for other hardware.

Tested:

* AR5416, STA mode (powersave)
* AR5212, STA mode (powersave)
2014-04-25 01:20:10 +00:00
Adrian Chadd
1b74d2a4ad Modify the ioctl path to support querying things if the vap state is
SLEEP rather than RUN.

Without this things like 'ifconfig wlan0 list sta' don't work when the
NIC is power save.

Tested:

* AR5212, STA mode (with powersave)
* AR5416, STA mode (with powersave)
2014-04-24 23:12:40 +00:00
Adrian Chadd
902840a5db Begin fleshing out support for net80211 provided (legacy) sleep management.
This transitions the VAP in and out of SLEEP state based on:

* whether there's been an active transmission in the last (hardcoded) 500ms;
* whether the TIM from the AP indicates there is data available.

It uses the beacon reception to trigger the active traffic check.
This way there's no further timer running to wake up the CPU
from its own sleep states.

Right now the VAP isn't woken up for multicast traffic - mostly because
the only NIC I plan on doing this for right will auto wakeup and stay
awake for multicast traffic indicated in the TIM.  So I don't have
to manually keep the hardware awake.

This doesn't do anything if the NIC doesn't advertise it implements
the new SWSLEEP capability AND if the VAP doesn't have powersave
enabled.

It also doesn't do much with ath(4) as it doesn't currently implement
the SLEEP state.

Tested:

* AR5416, STA mode (with local ath(4) changes)
2014-04-24 01:39:53 +00:00
Adrian Chadd
3914f0881e Add a capability to indicate that the net80211 stack should be doing
RUN->SLEEP->RUN transitions for station mode sleep management.
2014-04-24 01:28:39 +00:00
Adrian Chadd
ddd9ebbcec Allow frames to be transmitted in either RUN or SLEEP state
Frames transmitted during SLEEP state should be queued in the
power save queue before waking the unit up.  Otherwise DHCP
requests and such will be dropped if the NIC is asleep - the
NIC will wake up but not transmit the frame.
2014-04-23 22:44:49 +00:00
Adrian Chadd
9f098ac76f Allow the state of the interface to be "up" if the VAP is in SLEEP state.
Without this, the carrier will drop when the NIC transitions to SLEEP
and nothing will ever transmit.
2014-04-23 22:43:39 +00:00
Gleb Smirnoff
2c284d9395 Remove IPX support.
IPX was a network transport protocol in Novell's NetWare network operating
system from late 80s and then 90s. The NetWare itself switched to TCP/IP
as default transport in 1998. Later, in this century the Novell Open
Enterprise Server became successor of Novell NetWare. The last release
that claimed to still support IPX was OES 2 in 2007. Routing equipment
vendors (e.g. Cisco) discontinued support for IPX in 2011.

Thus, IPX won't be supported in FreeBSD 11.0-RELEASE.
2014-03-14 02:58:48 +00:00
Gleb Smirnoff
b8c83a1957 Another round of removing historical mbuf(9) allocator flags.
They are breeding! New ones arouse since last round.

Sponsored by:	Nginx, Inc.
2014-01-16 13:44:47 +00:00
Kevin Lo
5945b5f5ab Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.

Reviewed by:	adrian, rpaulo
2014-01-08 08:06:56 +00:00
Adrian Chadd
1db2772f43 Make sure any waiters on the scan results get notified if the scan task
decides to do nothing.

If this isn't done, then a scan request whilst a scan occurs in an active
channel set or a completed channel set will hang.

Tested:

* Intel 5100, STA mode
2013-11-29 22:24:57 +00:00
Rui Paulo
1a707877c1 Fix typo in comment. 2013-11-29 07:55:44 +00:00
Adrian Chadd
5140f9e6ae Fix AMRR to correctly select the initial rate.
There were two bugs:

* If the initial lowest rate didn't go through the loop at least once,
  the AMRR rate index would be the highest rate in the table
  (eg the rix mapping to MCS15) but rate would stay at the default
  value, namely 0.

  This meant that the initial rate selection would be MCS15 _but_ the
  node ni_txrate value would be MCS0.

* If the node is 11n, then break out of the loop correctly.  Beforehand,
  my initial 11n AMRR commit would immediately exit out as it would
  fail the 11n check, then it would always fall through to the non-11n
  rate which would then see if it was < 36mbit (ie, "72"), which would
  always match.  Hence, it'd always return MCS15.

Tested:

* Intel Centrino 2230 STA (local changes), STA mode
* Intel Wifi 5100, STA
2013-11-09 07:30:13 +00:00
Adrian Chadd
c6d5b60008 Don't return ENOBUFS if the transmit path handles the frame but queues it (eg in power save.)
This is definitely an MFC candidate for 10.0-REL.

MFC after:	1 week
2013-11-06 17:20:49 +00:00
Adrian Chadd
7f0660a04b Don't treat the node as an 11n node if 11n rates are disabled.
For now, the AMRR code only knows about _either_ MCS or non-MCS rates.
It doesn't know how to downgrade (ie, doing 11b CCK rates if MCS0 isn't
reliable.)

PR:		kern/183428
2013-10-31 02:04:53 +00:00
Gleb Smirnoff
104dc21415 - Provide necessary includes, that before came via if.h pollution.
- Remove unnecessary ones.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 22:26:03 +00:00
Gleb Smirnoff
c3322cb91c Include necessary headers that now are available due to pollution
via if_var.h.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-28 07:29:16 +00:00
Gleb Smirnoff
eedc7fd9e8 Provide includes that are needed in these files, and before were read
in implicitly via if.h -> if_var.h pollution.

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-26 18:18:50 +00:00
Gleb Smirnoff
76039bc84f The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2013-10-26 17:58:36 +00:00
Adrian Chadd
e94527beaf Fix a use-after-free node reference issue when waiting for a return
from a management frame transmission.

This bug is a bit loopy, so here goes.

The underlying cause is pretty easy to understand - the node isn't
referenced before passing into the callout, so if the node is deleted
before the callout fires, it'll dereference free'd memory.

The code path however is slightly more convoluted.

The functions _say_ mgt_tx - ie management transmit - which is partially
true.  Yes, that callback is attached to the mbuf for some management
frames.  However, it's only for frames relating to scanning and
authentication attempts.  It helpfully drives the VAP state back to
"SCAN" if the transmission fails _OR_ (as I subsequently found out!)
if the transmission succeeds but the state machine doesn't make progress
towards being authenticated and active.

Now, the code itself isn't terribly clear about this.

It _looks_ like it's just handling the transmit failure case.

However, when you look at what goes on in the transmit success case, it's
moving the VAP state back to SCAN if it hasn't changed state since
the time the callback was scheduled.  Ie, if it's in ASSOC or AUTH still,
it'll go back to SCAN.  But if it has transitioned to the RUN state,
the comparison will fail and it'll not transition things back to the
SCAN state.

So, to fix this, I decided to leave everything the way it is and merely
fix the locking and remove the node reference.

The _better_ fix would be to turn this callout into a "assoc/auth request"
timeout callback and make the callout locked, thus eliminating all races.
However, until all the drivers have been fixed so that transmit completions
occur outside of any locking that's going on, it's going to be impossible
to do this without introducing LORs.  So, I leave some of the evilness
in there.

Tested:

* AR5212, ath(4), STA mode
* 5100 and 4965 wifi, iwn(4), STA mode
2013-10-24 17:04:16 +00:00
Adrian Chadd
fce9c39777 Fix the "am I a net80211 vap" check for bpf listeners.
I changed it to use if_transmit a while ago but apparently with monitor
mode the if_transmit method is overridden.

This is (mostly) a workaround until a more permanent solution can be
found.

Submitted by:	Patrick Kelsey <kelsey@ieee.org>
Approved by:	re@ (gjb)
2013-10-10 19:56:31 +00:00
Adrian Chadd
36ee7775f4 Create a new function to complete 802.11 mbuf transmission.
The aim of this function is to eventually be the completion entry point
for all 802.11 encapsulated mbufs.  All the wifi drivers end up doing
what is in this function so it's an easy win to turn it into a net80211
method and abstract out this code.

Ideally the drivers will all eventually be modified to queue up completed
mbufs and call this function with all the driver locks not held.
This will allow for some much more interesting software queue handling
in the future (like net80211 based A-MSDU, fast-frames, A-MPDU aggregation
and retransmission.)

Tested:

* ath(4), iwn(4)
2013-08-27 14:37:13 +00:00
Adrian Chadd
74b4c76e4e Migrate the ff_encap1() routine out into the normal output code.
This will eventually be used by the A-MSDU encapsulation code that
I'm writing - the sub-frame encapsulation requirement is the same.
2013-08-26 09:52:05 +00:00
Adrian Chadd
b105165323 Add in some backwards compatability hacks to make -HEAD net80211 compile
on -9.
2013-08-22 05:53:47 +00:00
Andre Oppermann
5fc98a7895 Reorder the mbuf defines to make more sense and group related flags
together.

Add M_FLAG_PRINTF for use with printf(9) %b indentifier.

Use the generic mbuf flags print names in the net80211 code and adjust
the protocol specific bits for their new positions.

Change SCTP M_PROTO mapping from 5 to 1 to fit within the 16bit field
they use internally to store some additional information.

Discussed with:	trociny, glebius
2013-08-19 14:25:11 +00:00
Andre Oppermann
7100b4d04a Migrate the net80211 protocol specific use of M_FRAG, M_FIRSTFRAG and
M_LASTFRAG flags to protocol specific flags.

Remove the now unused M_FRAG, M_FIRSTFRAG and M_LASTFRAG mbuf flags.

Discussed with:	trociny, glebius, adrian
2013-08-19 14:07:31 +00:00
Andre Oppermann
86bd049144 Add m_clrprotoflags() to clear protocol specific mbuf flags at up and
downwards layer crossings.

Consistently use it within IP, IPv6 and ethernet protocols.

Discussed with:	trociny, glebius
2013-08-19 13:27:32 +00:00
Adrian Chadd
bfd3bbdb11 Don't return ENOTSUPP here - the net80211 pluggable ioctl API will treat
this as the final item in the linker set and not try others.

This stopped the fast frames IOCTLs from being called.
2013-08-18 23:40:30 +00:00
Adrian Chadd
11e0ddb146 Return the correct status if ieee80211_ff_check() consumes the mbuf.
I broke this when converting the net80211 TX path to use if_transmit.
2013-08-18 20:40:13 +00:00
Rui Paulo
a3e08d6f4c Replace the homegrown implementation of nitems() with calls to nitems()
(param.h).

Operating systems that don't have nitems() can easily define it on their own
net80211 OS-specific header file.

Discussed with:		adrian
2013-08-14 04:24:25 +00:00
Adrian Chadd
57b5fc5f3d Blank m_nextpkt before passing it up. 2013-08-12 22:27:53 +00:00
Adrian Chadd
4bd57e1078 When flushing packets from the powersave queue, make sure that
m_nextpkt is NULL before passing it up to the parent transmit
method.
2013-08-12 02:21:44 +00:00
Adrian Chadd
1df885c863 Add in missing m_free()'s during error conditions. 2013-08-10 21:46:58 +00:00
Adrian Chadd
e7495198d5 Convert net80211 over to using if_transmit for the dispatch from the
upper layer(s).

This eliminates the if_snd queue from net80211. Yay!

This unfortunately has a few side effects:

* It breaks ALTQ to net80211 for now - sorry everyone, but fixing
  parallelism and eliminating the if_snd queue is more important
  than supporting this broken traffic scheduling model. :-)

* There's no VAP and IC flush methods just yet - I think I'll add
  some NULL methods for now just as placeholders.

* It reduces throughput a little because now net80211 will drop packets
  rather than buffer them if the driver doesn't do its own buffering.
  This will be addressed in the future as I implement per-node software
  queues.

Tested:

* ath(4) and iwn(4) in STA operation
2013-08-08 05:09:35 +00:00
Adrian Chadd
cc80eae5cf Allow net80211 to compile on stable/9 and stable/8. 2013-08-07 22:01:43 +00:00
Adrian Chadd
1cc7c4c370 Fix compilation when debugging is disabled. 2013-07-28 17:35:19 +00:00
Adrian Chadd
0e20ac3863 Commit the missing header change. 2013-07-28 16:50:45 +00:00
Adrian Chadd
363a2c3c13 Refactor the VAP transmit path code into a utility function that both
the normal and the mesh transmit paths can use.

The API is a bit horrible because it both consumes the mbuf and frees
the node reference regardless of whether it succeeds or not.
It's a hold-over from how the code behaves; it'd be nice to have it
not free the node reference / mbuf if TX fails and let the caller
decide what to do.
2013-07-28 04:53:00 +00:00
Rui Paulo
d8df5f3d71 Add ieee80211_add_{qos,wpa,rsn}() functions since they are needed by an
OpenBSD driver that is being ported to FreeBSD.

Reviewed by:	adrian
2013-07-25 06:23:26 +00:00
Alfred Perlstein
d7b5c50b92 Make kassert_printf use __printflike.
Fix associated errors/warnings while I'm here.

Requested by: avg
2013-07-07 21:39:37 +00:00
Adrian Chadd
0933e74b10 Add a missing unlock. 2013-07-05 22:10:50 +00:00
Adrian Chadd
f8d390be65 Document the current 11n rate selection shortcoming in the AMRR code. 2013-07-05 00:03:53 +00:00
Adrian Chadd
f8bf74f232 Implement basic 802.11n awareness in the PHY and AMRR rate control code.
* Add 802.11n 2ghz and 5ghz tables, including legacy rates and up to
  MCS23 rates (3x3.)

* Populate the rate code -> rate index lookup table with MCS _and_
  normal rates, but _not_ the basic rate flag.  Since the basic rate flag
  is the same as the MCS flag, we can only use one.

* Introduce some accessor inlines that do PLCP and rate table lookup/access
  and enforce that it doesn't set the basic rate bit.  They're not
  designed for MCS rates, so it will panic.

* Start converting drivers that use the rate table stuff to use the
  accessor inlines and strip the basic flag.

* Teach AMRR about basic 11n - it's still as crap for MCS as it is
  being used by iwn, so it's not a step _backwardS_.

* Convert iwn over to accept 11n MCS rates rather than 'translate' legacy
  to MCS rates.  It doesn't use a lookup table any longer; instead it's a
  function which takes the current node (for HT parameters) and the
  rate code, and returns the hardware PLCP code to use.

Tested:

* ath - it's a no-op, and it works that way
* iwn - both 11n and non-11n
2013-07-04 21:16:49 +00:00
Rui Paulo
edd39a8e2d Don't panic the kernel if we run wpa_supplicant on a hostap VAP.
Reviewed by:	adrian
2013-06-29 06:36:42 +00:00
Eitan Adler
eadc444a0f Fix typo (dbM -> dBm)
Submitted by:	Daan@vitsch.nl
Reviewed by:	adrian
2013-06-14 23:04:31 +00:00
Adrian Chadd
9984c9baf3 Don't hold the node lock over the iterator.
The "find node" function call will increase the node reference anyway;
so there's no reason to hold the node table lock during the MLME change.

The only reason I could think of is to stop overlapping mlme ioctls
from causing issues, but this should be fixed a different way.

This fixes a whole class of LORs that creep up when nodes are being
timed out or removed by hostapd.

Tested:

* AR5416, hostap, with nodes coming and going.  No LORs or stability
  issues were observed.
2013-06-07 09:03:56 +00:00
Adrian Chadd
8d46c25d23 Fix net80211 fragment creation.
When creating fragment frames, the header length should honour the
DATAPAD flag.

This fixes the fragments that are queued to the ath(4) driver but it
doesn't yet fix fragment transmission.  That requires further changes
to the ath(4) transmit path.  Well, strictly speaking, it requires
further changes to _all_ wifi driver transmit paths, but this is at least
a start.

Tested:

* AR5416, STA mode, w/ fragthreshold set to 256.
2013-05-25 06:28:30 +00:00
Adrian Chadd
5b58efc6cc Fix a VAP BSS node reference in the HT code to actually take a reference
before using said node.

The "blessed" way here is to take a node reference before referencing
anything inside the node, otherwise the node can be freed between
the time the pointer is copied/dereferenced and the time the node contents
are used.

This mirrors fixes that I've done elsewhere in the net80211/driver
stack.

PR:		kern/178470
2013-05-10 09:37:58 +00:00
Gleb Smirnoff
47e8d432d5 Add const qualifier to the dst parameter of the ifnet if_output method. 2013-04-26 12:50:32 +00:00
Adrian Chadd
ebe15a7b25 Implement a utility function to return the current TX power cap for
the given node.

This takes into account the per-node cap, the ic cap and the
per-channel regulatory caps.

This is designed to replace references to ni_txpower in various net80211
drivers - ni_txpower doesn't necessarily reflect the actual cap for
the given node (eg if the node has the default value of 50dBm (100) and
the administrator has manually configured a lower TX power.)
2013-04-16 20:36:32 +00:00
Adrian Chadd
bd8cbcc32c Add VNET wrappers around the rest of the ieee80211 rtsock messages.
I triggered the cac/radar messages when doing testing in DFS channels.
2013-03-20 02:42:52 +00:00
Adrian Chadd
b451a99ecc Kill this, it's not needed at this point and (hopefully) the parent
has correctly locked the ic/vap.
2013-03-10 04:38:06 +00:00
Adrian Chadd
6ce4aeb88f Fix another compiler warning issue when invariants are disabled. 2013-03-09 15:35:31 +00:00
Adrian Chadd
3eed804d03 Fix non-invariant compilation. 2013-03-09 05:20:33 +00:00
Adrian Chadd
5cda6006e4 Bring over my initial work from the net80211 TX locking branch.
This patchset implements a new TX lock, covering both the per-VAP (and
thus per-node) TX locking and the serialisation through to the underlying
physical device.

This implements the hard requirement that frames to the underlying physical
device are scheduled to the underlying device in the same order that they
are processed at the VAP layer.  This includes adding extra encapsulation
state (such as sequence numbers and CCMP IV numbers.)  Any order mismatch
here will result in dropped packets at the receiver.

There are multiple transmit contexts from the upper protocol layers as well
as the "raw" interface via the management and BPF transmit paths.
All of these need to be correctly serialised or bad behaviour will result
under load.

The specifics:

* add a new TX IC lock - it will eventually just be used for serialisation
  to the underlying physical device but for now it's used for both the
  VAP encapsulation/serialisation and the physical device dispatch.

  This lock is specifically non-recursive.

* Methodize the parent transmit, vap transmit and ic_raw_xmit function
  pointers; use lock assertions in the parent/vap transmit routines.

* Add a lock assertion in ieee80211_encap() - the TX lock must be held
  here to guarantee sensible behaviour.

* Refactor out the packet sending code from ieee80211_start() - now
  ieee80211_start() is just a loop over the ifnet queue and it dispatches
  each VAP packet send through ieee80211_start_pkt().

  Yes, I will likely rename ieee80211_start_pkt() to something that
  better reflects its status as a VAP packet transmit path.  More on
  that later.

* Add locking around the management and BAR TX sending - to ensure that
  encapsulation and TX are done hand-in-hand.

* Add locking in the mesh code - again, to ensure that encapsulation
  and mesh transmit are done hand-in-hand.

* Add locking around the power save queue and ageq handling, when
  dispatching to the parent interface.

* Add locking around the WDS handoff.

* Add a note in the mesh dispatch code that the TX path needs to be
  re-thought-out - right now it's doing a direct parent device transmit
  rather than going via the vap layer.  It may "work", but it's likely
  incorrect (as it bypasses any possible per-node power save and
  aggregation handling.)

Why not a per-VAP or per-node lock?

Because in order to ensure per-VAP ordering, we'd have to hold the
VAP lock across parent->if_transmit().  There are a few problems
with this:

* There's some state being setup during each driver transmit - specifically,
  the encryption encap / CCMP IV setup.  That should eventually be dragged
  back into the encapsulation phase but for now it lives in the driver TX path.
  This should be locked.

* Two drivers (ath, iwn) re-use the node->ni_txseqs array in order to
  allocate sequence numbers when doing transmit aggregation.  This should
  also be locked.

* Drivers may have multiple frames queued already - so when one calls
  if_transmit(), it may end up dispatching multiple frames for different
  VAPs/nodes, each needing a different lock when handling that particular
  end destination.

So to be "correct" locking-wise, we'd end up needing to grab a VAP or
node lock inside the driver TX path when setting up crypto / AMPDU sequence
numbers, and we may already _have_ a TX lock held - mostly for the same
destination vap/node, but sometimes it'll be for others.  That could lead
to LORs and thus deadlocks.

So for now, I'm sticking with an IC TX lock.  It has the advantage of
papering over the above and it also has the added advantage that I can
assert that it's being held when doing a parent device transmit.
I'll look at splitting the locks out a bit more later on.

General outstanding net80211 TX path issues / TODO:

* Look into separating out the VAP serialisation and the IC handoff.
  It's going to be tricky as parent->if_transmit() doesn't give me the
  opportunity to split queuing from driver dispatch.  See above.

* Work with monthadar to fix up the mesh transmit path so it doesn't go via
  the parent interface when retransmitting frames.

* Push the encryption handling back into the driver, if it's at all
  architectually sane to do so.  I know it's possible - it's what mac80211
  in Linux does.

* Make ieee80211_raw_xmit() queue a frame into VAP or parent queue rather
  than doing a short-cut direct into the driver.  There are QoS issues
  here - you do want your management frames to be encapsulated and pushed
  onto the stack sooner than the (large, bursty) amount of data frames
  that are queued.  But there has to be a saner way to do this.

* Fragments are still broken - drivers need to be upgraded to an if_transmit()
  implementation and then fragmentation handling needs to be properly fixed.

Tested:

* STA - AR5416, AR9280, Intel 5300 abgn wifi
* Hostap - AR5416, AR9160, AR9280
* Mesh - some testing by monthadar@, more to come.
2013-03-08 20:23:55 +00:00
Adrian Chadd
341177e1d8 Disable this variable; the code using it is also disabled. 2013-02-18 01:37:55 +00:00
Adrian Chadd
32d384a45c Disable this code and add a note as to why.
It wasn't currently being called anyway - but being explicit about it
can't hurt.
2013-02-18 01:08:59 +00:00
Adrian Chadd
8c67042b72 Fix an incorrect sizeof()
Spotted by:	clang

Submitted by:	dim
2013-02-16 00:12:21 +00:00
Monthadar Al Jaberi
0cc7a79be6 Mesh: QoS Control field bit flags fix.
* The following bit flags where incroccetly defined:
    o Mesh Control Present
    o Mesh Power Save Level
    o RSPI
  This is now corrected according to Table 8.4 as per IEEE 802.11 2012;

Approved by:	adrian (mentor)
2013-02-14 20:00:38 +00:00
Gleb Smirnoff
23f4fd6da4 Substitute '#ifdef ALIGNED_POINTER' with '#ifndef __NO_STRICT_ALIGNMENT',
since the former is defined everywhere. This cuts off some code not
necessary on non strict aligment arches.

Reviewed by:	adrian
Sponsored by:	Nginx, Inc.
2013-02-12 11:24:37 +00:00
Adrian Chadd
d6aee93f98 Fix ieee80211_mesh.c compilation.
* Add the superg.h header to allow ieee80211_check_ff() to work
* Since the assert stuff creates assertions based on line numbers and there
  was a conflict, just nudge things down a bit.
2013-02-08 09:11:55 +00:00
Monthadar Al Jaberi
6db8a9b0f4 Mesh: recevied GANN frames where not parsed correctly.
* Added mesh_parse_meshgate_action that parse all values to host endian;
* Add more detailed debug output;

Approved by:	adrian (mentor)
2013-02-07 21:32:09 +00:00
Monthadar Al Jaberi
d68e1a3749 Mesh HWMP forwarding information: updating FI for transmitter.
* Added hwmp_update_transmitter function that checks if the metric
  to the transmitter have improved. If old FI is invalid or metric
  is larger the FI to the transmitter is updated occurdingly.
  This is a recommendation from the 802.11 2012 standard, table 13-9;

Approved by:	adrian (mentor)
2013-02-07 21:31:37 +00:00
Monthadar Al Jaberi
80e25642f2 Mesh HWMP PERR bug fixes.
* When calling ieee80211_mesh_rt_flush_peer, the rt->rt_dest argument
  should not be passed because it can get freed before invalidating
  the other routes that depends on it to compare with next_hop.
  Use PERR_DADDR(i) instead;

Approved by:	adrian (mentor)
2013-02-07 21:30:58 +00:00
Monthadar Al Jaberi
4efafd66eb Mesh bug: debug infomartion showing swapped SA and DA address.
* Fix bug for "forward frame from SA(%6D), DA(%6D)" where addresses where
  swapped between SA and DA;

Approved by:	adrian (mentor)
2013-02-07 21:30:29 +00:00
Monthadar Al Jaberi
62f0748505 Update ddb to print mesh routing table.
* Modified _db_show_vap and _db_show_com to print mesh routing table
  if the 'm' modifier is specified;

Approved by:	adrian (mentor)
2013-02-07 21:29:48 +00:00
Monthadar Al Jaberi
026e280fbf Mesh HWMP PREQ: fixed conditions for discarding elements.
Approved by:	adrian (mentor)
2013-02-07 21:29:14 +00:00