Commit Graph

52 Commits

Author SHA1 Message Date
avos
70ff509d20 net80211: fix more compiler warnings.
ieee80211.c:
	add_chanlist(): 'error' variable will be uninitialized if
	                no channels were passed; return '0' instead.
ieee80211_action.c:
	ieee80211_send_action_register(): drop 'break' after 'return'.
ieee80211_crypto_none.c:
	none_encap(): 'keyid' is not used in non-debug builds; hide it
	              behind IEEE80211_DEBUG ifdef.
ieee80211_freebsd.c:
	Staticize global 'ieee80211_debug' variable (used only in this
	file).
ieee80211_hostap.c:
	Fix a comment (associatio -> association).
ieee80211_ht.c:
	ieee80211_setup_htrates(): initialize 'maxunequalmcs' to 0 to mute
	                           compiler warning.
ieee80211_hwmp.c:
	hwmp_recv_preq(): copy 'prep' between conditional blocks to fix
			  -Wshadow warning.
ieee80211_mesh.c:
	mesh_newstate(): remove duplicate 'ni' definition.
	mesh_recv_group_data(): fix -Wempty-body warning in non-debug
				builds.
ieee80211_phy.c:
	ieee80211_compute_duration(): remove 'break' after panic() call.
ieee80211_scan_sta.c:
	Hide some TDMA-specific macros under IEEE80211_SUPPORT_TDMA ifdef
	adhoc_pick_bss(): remove 'ic' pointer redefinition.
ieee80211_sta.c:
	sta_beacon_miss(): remove 'ic' pointer redefinition.
ieee80211_superg.c:
	superg_ioctl_set80211(): drop unreachable return.

Tested with clang 3.8.0, gcc 4.6.4 and gcc 5.3.0.
2016-05-19 21:08:33 +00:00
avos
a5ff8b0e31 net80211: replace internal LE_READ_*/LE_WRITE_* macro with system
le*dec / le*enc functions.

Replace net80211 specific macros with system-wide bytestream
encoding/decoding functions:
- LE_READ_2 ->  le16dec
- LE_READ_4 ->  le32dec
- LE_WRITE_2 -> le16enc
- LE_WRITE_4 -> le32enc

+ drop ieee80211_input.h include, where it was included for these
operations only.

Reviewed by:	adrian
Differential Revision:	https://reviews.freebsd.org/D6030
2016-04-20 18:29:30 +00:00
adrian
8857d6b6f7 [net80211] migrate the time_* macros to ieee80211_* namespace.
It turns out that these will clash very annoyingly with the linux
macros in the linuxkpi layer, so let the wookie^Wlinux win.

The only user that I can find is ath(4), so fix it there too.
2016-03-30 00:44:10 +00:00
avos
d06b46d2e7 net80211: do not enforce promiscuous mode for AP scan
Drivers should set their own filters via ic_scan_start()/ic_scan_end()
callbacks; and we don't need frames other than beacons or probe responses.

(Note: this was a noop since r287197 due to promiscuous mode with bridge
workaround)

Tested with Intel 3945BG, RTL8188EU and WUSB54GC in HOSTAP mode.

Approved by:	adrian (mentor)
Differential Revision:	https://reviews.freebsd.org/D5474
2016-02-29 21:17:39 +00:00
glebius
306a6faf84 These files were getting sys/malloc.h and vm/uma.h with header pollution
via sys/mbuf.h
2016-02-01 17:41:21 +00:00
adrian
238d4c1fe4 Remove duplicate use of RV(), LE_* and other macros.
Submitted by:	Andriy Voskoboinyk <s3erios@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D3705
2015-09-22 02:25:52 +00:00
glebius
619aca846f Replay r286410. 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 pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by:	adrian
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-08-27 08:56:39 +00:00
adrian
bad6d5c89b 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
glebius
eb8a90b859 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
3280920228 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
daa4dc6942 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
a4b25580a8 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
befcdd660f 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
rpaulo
d895e55630 Fix typo in comment. 2013-11-29 07:55:44 +00:00
glebius
ff6e113f1b 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
rpaulo
b66e5efc0f 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
88c7f81825 Initial cut at making IBSS support 802.11n aware.
* Add HTINFO field decoding to ieee80211_ies_expand() - it's likely not
  100% correct as it's not looking at the draft 11n HTINFO location,
  but I don't think anyone will care.

* When doing an IBSS join make sure the 11n channel configuration
  is used - otherwise the 11a/11bg channel will be used
  and there won't be any chance for an upgrade to 11n.

* When creating an IBSS network, ensure the channel is updated to an
  11n channel so other 11n nodes can see it and speak to it with MCS
  rates.

* Add a bit of code that's disabled for now which handles the HT
  field updating.  This won't work out very well with lots of adhoc
  nodes as we'd end up ping-ponging between the HT configuration for
  each node.  Instead, we should likely only pay attention to the
  "master" node we initially associated against and then ensure we
  propagate that information forward in our subsequent beacons.  However,
  due to the nature of IBSS (ie, there's no specific "master" node in
  the specification) it's unclear which node we should lift the HT
  parameters from.

  So for now this assumes the HT parameters are squirreled away in the
  initial beacon/probe response.

So there's some trickiness here.

With ap/sta pairing, the probe response just populates a legacy node
and the association request/response is what is used for negotiation
11n-ness (and upgrading things as needed.)

With ibss networks, the pairing is done with probe request/response,
with discovery being done by creating nodes when new beacons in the
IBSS / BSSID are heard.  There's no assoc request/response frames going on.

So the trick here has been to figure out where to upgrade things.
I don't like how I just taught ieee80211_sta_join() to "speak" HT -
I'd rather there be an upgrade path when an IBSS node joins and there
are HT parameters present.  Once I've done that, I'll kill this
HT special casing that's going on in ieee80211_sta_join().

Tested:

* AR9280, AR5416, AR5212 - basic iperf and ping interoperability tests
  whilst in a non-encrypted adhoc network.

TODO:

* Fix up the HT upgrade path for IBSS nodes rather than adding code
  in ieee80211_sta_join(), then remove my code from there.

* When associating, there's a concept of a "master" node in the IBSS
  which is the node you first joined the network through.  It's possible
  the correct thing to do is to listen to HT updates and configure WME
  parameters from that node.  However, once that node goes away, which
  node(s) should be listened to for configuration changes?

  For things like HT channel width, it's likely going to be ok to
  just associate as HT40 and then use the per-neighbor rate control
  and HTINFO/HTCAP fields to figure out which rates and configuration
  to speak.  Ie, for a 20MHz 11n node, just speak 20MHz rates to
  it.  It shouldn't "change", like what goes on in AP/STA configurations.
2013-01-26 00:37:54 +00:00
bschmidt
085afcf6e3 When setting a fixed channel on adapters with 11n support the scan
channel list ends up with 2 entries, the HT and the legacy channel.
The scan itself is currently always done at legacy rates so we end
up receiving scan results for legacy networks on the HT channel and
erroneously assigning the BSS to the 11n channel. As the channel's
capabilities are used to setup the adapter we might end up with
non-working settings and/or firmware crashes.

Fix this by ensuring that scan results received on a HT channel
are only assigned to that channel if the htcap IE is available,
else use the legacy channel equivalent.

Tested by:	Pawel Worach, Raoul Megelas, Maciej Milewski,
		Andrei <az at azsupport dot com>
Approved by:	re (kib)
2011-08-08 16:29:07 +00:00
bschmidt
0e5f5b1d23 Fix rmax calculation during BSS selection.
If multiple networks are available the max bandwidth is one
condition used for selecting the "best" BSS. To achieve that
we should consider all parameters which affect the max RX rate.
This includes 20/40MHz, SGI and the of course the MCS set.

If the TX MCS parameters are available we should use those,
because an AP announcing support for receiving frames at 450Mbps
might only be able to transmit at 150Mbps (1T3R). I haven't seen
devices with support for transmitting at higher rates then
receiving, so prefering TX over RX information should be safe.

While here, remove the hardcoded assumption that MCS15 is the max
possible MCS rate, use MCS31 instead which really is the highest
rate (according to the 802.11n std). Also, fix a mismatch of an
40MHz/SGI check.
2011-03-13 11:58:40 +00:00
bschmidt
b040c9742c The meshid element is memcpy()'ed into se_meshid if included in either
beacon or probe-response frames. Fix the condition by checking for the
the array's content instead of the always existing array itself.

Reviewed by:	rpaulo, stefanf
MFC after:	3 days
2010-11-22 19:01:47 +00:00
adrian
0b4711038c Fix background roaming to actually work in AUTO roaming mode.
IEEE80211_F_BGSCAN is a vap flag, not a channel flag. So although bgscan
occured, sta_roam_check() would never be called.
2010-10-01 09:18:30 +00:00
rpaulo
3fbf954047 Compare the address of the array, not the array.
Found with:	Coverity Prevent(tm)
CID:		3690
MFC after:	3 days
2010-06-01 14:17:08 +00:00
rpaulo
a3b4a561d7 Make this code a little more portable by wrapping the mtx calls into
macros.

MFC after:	1 week
2010-04-14 18:29:40 +00:00
sam
8d5758f2a0 fix misplaced #endif that caused tdma handling to be merged with ESS handling
(causing tdma scanning to break)

Approved by:	re (kib)
2009-07-31 19:13:16 +00:00
rpaulo
8424d74020 Implementation of the upcoming Wireless Mesh standard, 802.11s, on the
net80211 wireless stack. This work is based on the March 2009 D3.0 draft
standard. This standard is expected to become final next year.
This includes two main net80211 modules, ieee80211_mesh.c
which deals with peer link management, link metric calculation,
routing table control and mesh configuration and ieee80211_hwmp.c
which deals with the actually routing process on the mesh network.
HWMP is the mandatory routing protocol on by the mesh standard, but
others, such as RA-OLSR, can be implemented.

Authentication and encryption are not implemented.

There are several scripts under tools/tools/net80211/scripts that can be
used to test different mesh network topologies and they also teach you
how to setup a mesh vap (for the impatient: ifconfig wlan0 create
wlandev ... wlanmode mesh).

A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled
by default on GENERIC kernels for i386, amd64, sparc64 and pc98.

Drivers that support mesh networks right now are: ath, ral and mwl.

More information at: http://wiki.freebsd.org/WifiMesh

Please note that this work is experimental. Also, please note that
bridging a mesh vap with another network interface is not yet supported.

Many thanks to the FreeBSD Foundation for sponsoring this project and to
Sam Leffler for his support.
Also, I would like to thank Gateworks Corporation for sending me a
Cambria board which was used during the development of this project.

Reviewed by:	sam
Approved by:	re (kensmith)
Obtained from:	projects/mesh11s
2009-07-11 15:02:45 +00:00
sam
33549e3857 iv_flags_ext is full, make room by moving HT-related flags to a new
iv_flags_ht word
2009-06-07 22:00:22 +00:00
sam
68f7a1034a Overhaul monitor mode handling:
o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO
  and remove explicit bpf support from wireless drivers; drivers now
  use ieee80211_radiotap_attach to setup shared data structures that
  hold the radiotap header for each packet tx/rx
o remove rx timestamp from the rx path; it was used only by the tdma support
  for debugging and was mostly useless due to it being 32-bits and mostly
  unavailable
o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and
  per-com state when there are active taps
o track the number of monitor mode vaps
o use bpf tap and monitor mode vap state to decide when to collect radiotap
  state and dispatch frames; drivers no longer explicitly directly check
  bpf state or use bpf calls to tap frames
o handle radiotap state updates on channel change in net80211; drivers
  should not do this (unless they bypass net80211 which is almost always
  a mistake)
o update various drivers to be more consistent/correct in handling radiotap
o update ral to include TSF in radiotap'd frames
o add promisc mode callback to wi

Reviewed by:	cbzimmer, rpaulo, thompsa
2009-05-20 20:00:40 +00:00
thompsa
ed7c3176b9 Create a taskqueue for each wireless interface which provides a serialised
sleepable context for net80211 driver callbacks. This removes the need for USB
and firmware based drivers to roll their own code to defer the chip programming
for state changes, scan requests, channel changes and mcast/promisc updates.
When a driver callback completes the hardware state is now guaranteed to have
been updated and is in sync with net80211 layer.

This nukes around 1300 lines of code from the wireless device drivers making
them more readable and less race prone.

The net80211 layer has been updated as follows
 - all state/channel changes are serialised on the taskqueue.
 - ieee80211_new_state() always queues and can now be called from any context
 - scanning runs from a single taskq function and executes to completion. driver
   callbacks are synchronous so the channel, phy mode and rx filters are
   guaranteed to be set in hardware before probe request frames are
   transmitted.

Help and contributions from Sam Leffler.

Reviewed by:	sam
2009-05-02 15:14:18 +00:00
sam
8bfd160665 Minor cleanups of tdma protocol handling:
o break out version-related code to simplify rev'ing the protocol
o add parameter validation macros so checks that appear multiple places
  are consistent (and easy to change)
o add protocol version check when looking for a scan candidate
o improve scan debug output format
o rewrite beacon update handling to calculate a bitmask of changed values
  and pass that down through the driver callback so drivers can optimize work
o do slot bounds check before use when parsing received beacons
2009-03-18 19:28:17 +00:00
sam
9b33d4c5ea add the desired channel to the scan list if not already present and
compatible with other scan controls
2009-03-04 22:05:25 +00:00
sam
ac3671600d Add modes for 1/2 and 1/4-width channels so we have separate roaming
and xmit parameters.  This makes it possible to use tdma on fractional
channels.
o add IEEE80211_MODE_HALF and IEEE80211_MODE_QUARTER; note these are
  band-agnostic (may need revisiting)
o setup all default rates in ic_sup_rates instead of doing it only
  for active modes; we need these to calculate the default tx parameters
  which are not recalculated after a regulatory update (can't just
  recalculate after installing a new channel list because we might
  clobber user settings)
o remove special case code in ieee80211_get_suprates; this is now
  a candidate for an inline or removal
o add various entries for new modes (roaming+tx params, wme, rate
  mapping, scan set setup, country ie construction, tdma, basic rates)

Note these modes are intentionally not visible through if_media.
2009-02-19 05:21:54 +00:00
sam
fe861a3d8d use c99 initializer 2009-02-19 04:40:47 +00:00
sam
860ee29713 when promoting an 11b channel to 11g do not accept a ``pure G'' (OFDM only)
channel, only accept a real 11g channel; this fixes a problem where we were
wrongly promoting 11b to a Dynamic Turbo G channel which broke scanning on
channel 6
2009-02-01 22:24:08 +00:00
sam
98ad45c3d3 TDMA support for long distance point-to-point links using ath devices:
o add net80211 support for a tdma vap that is built on top of the
  existing adhoc-demo support
o add tdma scheduling of frame transmission to the ath driver; it's
  conceivable other devices might be capable of this too in which case
  they can make use of the 802.11 protocol additions etc.
o add minor bits to user tools that need to know: ifconfig to setup and
  configure, new statistics in athstats, and new debug mask bits

While the architecture can support >2 slots in a TDMA BSS the current
design is intended (and tested) for only 2 slots.

Sponsored by:	Intel
2009-01-08 17:12:47 +00:00
sam
7aaeeb0704 convert MALLOC/FREE to malloc/free 2008-12-18 23:00:09 +00:00
sam
dc256886cd Fix definition of IEEE80211_CHAN_MAX; it was defined as 255 but
really was meant to be 256.  Adjust usage accordingly and replace
bogus usage of this value in checking IEEE channel #'s.

NB: this causes an ABI change; ifconfig must be recompiled
2008-12-15 01:26:33 +00:00
sam
ed90b40066 Fix joining an 11b BSS: scanning is normally done using 11g channels
(unless explicitly locked to mode 11b) so when we join the bss the
channel attached to the scan cache entry may need to be demoted.

o demote to 11b if the ap is advertising 11b rates
o skip the ap if it's 11b but we're locked to 11g (could consider this
  advisory but for now treat it as mandatory)
o handle an odd edge case, if there is a fixed transmit rate for 11g
  then the rate check against the 11b ap will fail, try to demote to
  11b and retry the rate check

Reviewed by:	sephe, thompsa
2008-10-26 21:56:27 +00:00
sam
5d094d97f7 expand captured ie's before calling match_bss so they can potentially
be used in the process
2008-10-25 23:39:18 +00:00
sam
514df7862a change ieee80211_sta_join to take an explicit channel instead of
using the value in the scan parameters; this will be used to fix
issues with 11b operation
2008-10-25 23:32:24 +00:00
des
2668f9825b Revert the removal of the MALLOC and FREE macros from the net80211 code.
Requested by:	sam
2008-10-23 19:57:13 +00:00
des
66f807ed8b Retire the MALLOC and FREE macros. They are an abomination unto style(9).
MFC after:	3 months
2008-10-23 15:53:51 +00:00
sam
ab8d709f77 guard against adhoc_pick_channel returning a NULL channel; this can
happen after a scan cache flush (e.g. in response to ifconfig wlan bssid -)
2008-09-27 21:18:40 +00:00
sam
3569e353ca Multi-bss (aka vap) support for 802.11 devices.
Note this includes changes to all drivers and moves some device firmware
loading to use firmware(9) and a separate module (e.g. ral).  Also there
no longer are separate wlan_scan* modules; this functionality is now
bundled into the wlan module.

Supported by:	Hobnob and Marvell
Reviewed by:	many
Obtained from:	Atheros (some bits)
2008-04-20 20:35:46 +00:00
sam
c125e780ea Fix adhoc mode to scan all available channels for a bss to join
while still restricting auto-channel select to only those channels
permitted by regulatory constraints (sorta, we're still missing the
checks to honor radar and noadhoc status on channels).  This somehow
got lost in the initial merge of the revised scanning code.

Reviewed by:	jhay
MFC after:	2 weeks
2008-02-29 04:07:07 +00:00
sam
ae8014822b Be more careful handling off-channel frames: if the driver (wrongly)
sends frames up the stack after changing the current channel then
the lookup by ieee channel number may fail leaving a null ptr in
se_chan; if this happens fallback to the channel recorded when the
frame is processed (curchan).  Since the frame doesn't contribute
to scan results for the sta this is acceptable.

Reviewed by:	thompsa
MFC after:	3 days
2007-11-26 21:28:18 +00:00
sam
d7af353cad use the DSPARMS ie to find the home channel for off-channel frames
Reviewed by:	thompsa
MFC after:	1 week
2007-11-23 05:58:37 +00:00
sam
41cdb14400 Correct handling of off-channel frames:
o do not override the home channel recorded for the sta when the frame is
  received off-channel; this fixes a problem where we might think the sta
  was operating on the channel the frame was received on causing association
  requests to be ignored/rejected (likely cause of kern/99036)
o don't include rssi of off-channel frames in the avg rssi used to select
  a bss; this gives us a better estimate of the signal we will see for the
  station when on-channel

PR:		kern/99036
Found by:	Yubin Gong
Reviewed by:	sephe
MFC after:	1 week
2007-11-05 17:24:28 +00:00
sam
e6720edef5 sync 11n support with vap code base; many changes based on interop
testing with all major vendors

MFC after:	1 week
2007-11-02 05:22:25 +00:00
sephe
9adf8173c2 In add_channel(), search 11g channels if mode is AUTO and corresponding
11b channel is not found, e.g. Atheros 5211.

Reported by: matteo
Problem outlined by: thompsa
Reviewed by: sam, thompsa
Approved by: re (kensmith), sam (mentor)
Tested by: matteo (an early version)
2007-07-20 11:38:12 +00:00
sam
77c677502e revert handling of ssid and bssid to be manadatory instead of advisory
Prodded by:	Kevin Gerry
Reviewed by:	thompsa, sephe
Approved by:	re (kensmith)
2007-07-12 17:22:43 +00:00