View source for Electronics notes/802.11 (WiFi)

{{#addbodyclass:tag_tech}}
{{Electronics notes}}
{{old}}
{{notes}}


==On speed, range, and interference==

===Speed===

{{info|Expectations tl;dr|

In moderate conditions, you can be fairly happy if you often get speeds in the range of
: 1 to 5MByte/s on 11g 
: 3 to 8MByte/s (24..64Mbit) on 11n 
: 5 to 15MByte/s (40..130Mbit) on 11ac

You may get less, you may get more, and the reasons are nontrivial.}}

<!--
Yes, people report more. 

Which is not the reality of "after I hid a minimal amount of APs in places convenient in my house, this is what I got", which is what most people end up doing.

That's usually nerds like me trying to squeeze out the best case,
e.g. by putting an AP basically on our desks,
just to see what range of speeds is ''possible'' and what hiding place still gets close to that.

(At which point plugging that same cable in directly would give better bandwidth ''and'' latency -- yes, even if you bought so-called gbit wifi)


Hints:

* Depending a little on your house, buying twice the APs means there will always be one close
: but this is more costly

* making a channel plan so that their sending does not overlap is pref
: ...if you live in a house with some space around you
: ...and that's work that people don't necessarily like


* '''Avoid repeaters.'''
: More APs is almost always better than repeaters. 
: Repeaters are great for making that signal strength icon look better ''at the cost of easily reducing speed''
:: in the sense that what they do fundamentally means moving the same thing through the air more times

Repeaters are still useful for niche cases like getting wifi to a garden shed, where 
: you may care more about connectivity than speed.
: putting in the cable is prohibitive amounts of work for that bit of speed, or at all
-->


'''Advertised throughputs are stupid'''

tl;dr:
* for distance-and-wall-and-neighbour reasons, and the will of marketers to use the maximum possible number,
you can '''you can practically expect real throughput to max out at half the advertised speed'''.

* That improved a little with 11ac, though ''how much'' better is arguably even more of an 'it depends' than before.


The figure on the box is for 
lab conditions, 
minimal distance
a complete lack of neighbors, 
a lack of even walls, and 
may be the collective possible speed for ''all'' supported clients, that is not possible to give to a single client.


In reality:
* You have more than a meter of distance.
: this shouldn't matter a lot. Yes, inverse square laws apply, but the first so-many meters are in a very comfortable range, so this ''can'' be overstate. 
: {{comment|(Yes, putting an AP on your desk helps a lot -- but then why not just plug in the wire? I promise you the bandwidth ''and'' latency ''and'' jitter are better)}}


* You have walls. Walls dampen signal. 
: {{comment|(For drywall or lime brick maybe 6dB per wall on 2.4GHz, 12dB on 5GHz {{verify}}. On serious concrete, well, more than you care for)}} After two walls you will probably never see the high end of the speeds.
: walls plus distance add up


* You share that medium, so you share that speed with all clients.
: So divide the speed the air can do, by the amount of people using it constantly.
:: on the upside, most things are intermittent so sharing works well. On the downside, things like video streaming ''are'' a constant load.
: In dense housing, you probably neighbours. If you have one or two, then you ''can'' be on unique bits of the medium (see notes on channels), but even clever APs are only moderately good at setting things up that way.
:: more than two and you ''will'' be sharing the medium, and the speed divides right along.


* Mixed-speed networks have slightly lower overall throughput
: There's mixed-speed networks (e.g. b + g + n, because they're all in the same 2.4GHz band, though b is rare now and g less and less common).
: That implies that when b or g devices appear, the communication goes at different speeds at different times;
:: It ''won't'' force everything to talk to the slowest speed on the network, an apparently common-enough misconception. 
:: But the slower clients take up more timeslots to send the same amount of bytes, so when the slower clients have a lot to say it can ''seem'' that way).
:: (note that anything that moves little data has negligible effect)




11ac is 5GHZ-only so does not have to share with b, g, or n at all.

But at the same time, 5GHz has higher losses through walls. 
The better ability to focus energy in one direction (MIMO) helps a bunch -- but seen another way, at best it helps one wall ''more'', and then acts like 11n did.

Also keep in mind that this directionality only helps if the ''client'' is equally good at directing its response.

{{comment|So there's an argument that if you want good 11ac, get more APs to cover the area -- and bang for buck, ''simpler'' 11ac APs so you can have more of them for the same overall cost, and e.g. spread them around the rooms you're usually in).}}.


If you are a better nerd than me, you can ''in theory'' get 11ac to carry 1Gbps or even 4Gbps or 7Gbps, but actually most devices don't even support that.

''Some'' laptops are designed to try for 400Mbps or so,
most tablets and particularly phones aren't even designed to try for half of that.

{{comment|(''Technically'' this relates mostly to the the QAM and MIMO variants. ''Practically'' it relates to expected use cases as well. Phone designers know you're not going to concurrently stream eight 4K streams on a single phone)}}.


There's also some creative advertising going on (always a marketer hobby around wifi, why stop now?),
just arguably got ''more'' creative around 11n and 11ac.
For example, your AP may indeed have 1.3Gbit to spend, but ''never'' gives more than a few hundred mbps to any one client. 
Often by specific design, even.


As 11ac APs tend to be dual radio {{comment|(providing 11n on 2.4GHz)}}, the box label might add the 2.4GHz and 5GHz speeds together. 
Not because any one device gets to ever use that, but because marketing likes higher numbers.



Ultra turbo large antenna APs, aggressively angled plastic, and 1024-QAM and 4x4 (or even 8x8) MIMO are, in a word, stupid.
Because even if the ''AP'' can do this, it ''doesn't matter'' when
: stronger sending and more directional sending only really helps (speed-at-a-)range when ''both'' side do it, and many clients ''can't''
: most clients do at most 64-QAM and 2×2 MIMO

===Latency===

'''Latency''' is roughly the wallclock time in which packets make it through.

tl;dr
* at best ~1ms average while no one uses wifi muche
* assume ~10ms when saving power
* assume over 100ms (and varying a lot) when congested by a lot of people
* no matter the baseline, the occasional packet can take longer





'''When the medium is (not) idle'''

Wifi may well hover around 1ms when everything around you is idle.


When the medium is fully used (heavy downloading) and/or sees interference, then you can expect at least a small percentage of packets to take longer. 
There will be spikes to order of 100ms '''even when '' the average is still a few ms.


If used/shared/interfered intensively all the time, then you can expect something like 150ms to be the ''average''.



'''With power saving'''

Wifi power lowers the background use of having WiFi on, and is great, and done fairly cleverly, and is part of the WiFi protocol itself.
And you should assume that this may easily make the ''minimum'' ~10ms. 

It may also be fairly consistently be that when idle,
which is not noticeable for a lot of uses, 
so actually ''very'' reasonable if it makes your battery last significantly longer.




'''Consider using a cable when you easily can'''

Keep in mind that when people collectively manage to saturate the wifi medium (the channel's effective speed), there is basically ''nothing'' to stop latency from growing high. 

It is a shared medium and you have no control over who uses it.


That LAN cable, not being a shared medium, doesn't have that issue at all. 

Until a lot of people concentrate to saturate a switch (which are gBit these days),
or more likely, the broadband you share. 

<!--(or, theoretically, the upstream bandwidth of that broadband. In theory, that can happen as soon as at your street, but providers tend to be decent at provisioning and limiting bandwidth. 
YMMV depending on how much your country believes in competition, and how much companies have to consider complaints and pricing models. -->


{{comment|(also note that laptops aren't clever enough to immediately switch all they can to the cable you just plugged in. So this is mostly useful for fixed workspaces)}}

===On range and interference===
{{stub}}

Think of a party with a lot of chatty people.
: You're all using the same air.
: More people will always mean it's harder to talk
: politeness, conventions, and agreements can help - but only if everyone cares
: Standing closer and facing someone will help
:: Also means your group is less disruptive of the other groups
: Louder only helps that one guy with the loud voice, but if we all talk louder it's the same mess again. Also it's bad for our vocal cords.


Most of that has direct analogues in wifi terms:
: You're all using the same medium. Things on the same channel will share speed
:: you get approx 3 fully separated channels in the 2.4GHz band {{comment|(not 13 - the channels overlap)}}, or at 11n speeds, just one or two.

: seeing 30 APs from all your neighbours means your wifi won't be as great
:: {{comment|(if you can plan your channel use with your neighbours, that helps - but is rarely worth the trouble. Businesses, universities and such can and often do plan this better)}}

: the fairness of the use of shared channels are actually quite good (and the politeness mostly enforced)

: if both talkers are closeby, nothing getting lost in noise, so often means higher speeds
:: implying that often, the simplest way to get better wifi is to wire in another AP (on a different channel)

: both talkers being directional helps range
:: ...but since in home use, one side is always an AP, it's easier to place that AP in the center of a group of users.
:: those manly large antennas don't really help, for the same reason (but this is a different discussion)
:: There are stories like people having a [[cantenna]] pair between their apartment and laptop on the beach ~100m away. It's very specific but it works :)

: You may have seen "transmit power" on your AP's settings
:: Increasing this will not increase range, unless you can also increase the clients's.
:: there is usually a hard limit on laptops/tablets/phones. If there isn't...
::: it easily leads to signal overdrive, meaning communication may be no better, or worse
::: beyond some limit it's bad for the amp
:: If you change only the , you will often find no difference. Or negative - some devices will switch/roam to you when they can't actually reach you.



'''For range, the client is usually the limiting factor''', and there is usually nothing you can do about it.
There is significant variation in laptop / phone, hard to know/measure, and harder to change.
Even if you can tweak transmit power, that often means shortening battery life. 
This is another arguments towards "wire in another AP closeby" (or even a repeater).


Each wall will decrease signal quality - usually three walls away it's useless, and two walls away you'll already have interesting dead spots.
Clever AP placement helps, but again, having more APs to be clever with is better.




Note that there is no such thing as a 3dBi omnidirectional antenna. That statement violates the laws of physics.
Per definition, the dBi of an omnidirectional can never be above 0, and will always be a little below due to losses.

That doesn't mean these are a scam, and it doesn't mean they are not useful. 
It means they are only ''sort of'' omnidirectional - the shape of their effectiveness in 3D is basically like an apple stuck on it.
The higher the (not-)dBi number, the flatter the apple. Point this antenna directly at the computer and signal drops. But stick the antenna to the sky and the rooms on the same floor get better-than-isotropic reception. Beyond 3dBi the shape gets weird, which is more confusing than it is useful.

The flat apple shape is useful, yes.
But only so much, because for this to mean more range, mobile devices have to do the same thing.
They can a little (e.g. laptop screens usually point up when in use), but not a lot.

<!--
More pragmatically:
* Don't touch the AP's transmit power (...if you can't do so on ''all'' clients, and sensibly. Basically meaning never). Your laptop/tablet/phone/whatever will still assume the AP is a better one, but it can't talk back loudly enough and you will have caused the connection to be ''worse''. For better coverage, think placement or additional APs.

* For similar reasons, higher-dBi antennae are only useful if both sides have them -- can be quite useful for joinging two networks with a WiFi link, sometimes things you use as repeaters (e.g. directional to your shed, and an omnidirectional antenna for your laptop there), but not on typical client-facing APs.

* The largest factor you can change is usually walls - or rather, AP placement. WiFi may get through a wall or two ro three and still be usable, but not much more. Corners also don't help.
: Even with one or two significant attenuators you can get decent speeds up to 10m / 30feet, and a connection at all up to perhaps 30m / 100feet. With a lot of things in the way, less than half that isn't unusual.


Arguably, the optimal transmit power (for clients and AP radios) is the ''lowest'' transmit power that covers the area you want to cover. This way you minimize interference and lower the chances of interference and such.


An AP's radio generally does not differ much from a client radio.
An AP may have 2-3 dBi gain antennae, while a client tends to have near-zero dBi setup.



Higher AP transmit power may also cause some trouble
* clients may switch to the AP based on RSSI, even while it is actually a worse AP choice because the client can't reach it as well as another. If all laptops transmit at, say, ~28mW or less, then an AP transmitting with more is fairly pointless.
* higher likelihood of interference with nearby APs (you basically take a slightly wider band). In fact, when you saturate an area with APs, then lowering the transmit power (on ''most/all'') may give a better result.
* at some point, the signal will become distorted, increasing error (around 80mW for basic hardware?)


Perhaps 20mW to 40mW (13dBm to 16dBm) seems usual for home APs. 

Don't count on laptops and such doing more than ~30mW (~15dBm).

Up to ~80mW (19dBm) can help in a few situations, but usually isn't very sensible {{comment|(also because setting that on hardware meant for a 30mW will probably burn it up faster)}}.

In case the device wants it in dBm:
13dBm = ~20mW
14dBm = ~25mW
15dBm = ~32mW
16dBm = ~40mW
17dBm = ~51mW
18dBm = ~63mW
19dBm = ~80mW
If you want more than on WiFi that you'ld better have a convincing reason.


Given this transmit power and the speed degradation, high speeds are likely only within ~10m / 30feet.
-->

===On interference===

'''802.11 devices work together fairly well''', in terms of sharing speed on the same channel.



'''Adjacent channels actually overlap'''

Channels refer to fixed center frequencies.
At full power, transmission on a 2.4GHz channel covers five channels's centers.
Which means the they share the medium so slow each other down somewhat. 
When this effect isn't made irrelevant by a high noise floor, it is one reason for slowdown in busy areas.

If you can control all your APs, it makes sense to set APs on channels far enough apart - usually channels 1, 6, and 11 - and do so considering their position, so that no two adjacent APs are on the same channel. ''Lowering'' transmit power can also help {{comment|(assuming two things on the same channel will interfere less, and clients will roam freely)}}

If you don't control much, then such a planned economy won't work. 
In busy neighbourhoods the 1,6,11 suggesion is easily sub-optimal, and it can still makes sense


Seeing APs on a channel doesn't mean much without seeing how busy it is.
Channel use varies throughout the day.
Other interference may be even less predictable.

''Informed'' trial and error and speed testing may be the best solution, as a self-organizing system works better than not thinking at all :)




'''Non-WiFi devices interfere with WiFi'''

2.4GHz WiFi uses the 2.4GHz [[Electronics_notes/Wireless_communication#ISM_bands_and_such|ISM band]].
That band was reserved pretty much so that RF communication wouldn't use it, and certain devices could be used without interfering with anything important. 

The band being license-free, however, means that various communication devices use this, including:
* Bluetooth (uses the same band). Bluetooth's rapid channel hopping means fairly graceful degradation of speed on both BT and WiFi. 
* Wireless headsets
* Microwaves (relatively leaky ones, anyway - in general they shouldn't matter much)
* Some cordless phones 
* Some fancy motion detectors (2.4GHz radar)

Note that interference varies with distance. For example, many bluetooth devices by design don't react more than ~10 meters.

''If'' the interference has a low duty cycle, WiFi will still get through.

==Relatively common-and-central concepts==
===Channels===
{{stub}}
Channels are a central frequency, and an effective band around it.

WiFi uses ~72MHz within the 2.4GHZ ISM band. There are 14 channels defined in the standard, though many countries have a narrower range. 
Many have somewhere between ten to thirteen channels (e.g. 1-11 in the US), and in some places you get just one or two.

The channel centers are 5MHz apart. At typical transmission strengths, a channel is easily ~22MHz wide in the air (falls off to negligible power at the edge of that), which means that at full power, each channel overlaps with the next four channels in ''both'' directions. 

It degrades gracefully, meaning you get service even in very busy areas (though not good speed or latency).
It also means that if you're planning fast wifi for your home, you can only run about three full-power channels without interference - assuming you have no neighbours. 

APs regularly choose 1, 6, and 11 (because that fits in the US and is regularly seen elsewhere, and you can plan no adjacent APs to use the same channel by treating an area(/volume) to be covered as a three/four color mapping problem[http://en.wikipedia.org/wiki/Four_color_theorem] so that.

...but back in the real world you can often only consider the channels your neighbours have and try to find a ''relatively'' silent channel.

See also:
* http://en.wikipedia.org/wiki/IEEE_802.11
* http://www.moonblinkwifi.com/2point4freq.cfm
* http://en.wikipedia.org/wiki/List_of_WLAN_channels

===Nodes and groups of them:===
* Nodes - single devices - are identified with BSSIDs, which are unique hardware identifiers, and are used in routing (much like Ethernet MACs in concept).

* Groups of nodes, are identified with SSIDs (service set identifiers), which are usually short, human-readable strings. The ''service type'' you choose pretty much implies what type of SSID it is:
** BSS: Basic Service Set.
** IBBS: Independent Basic Service Set (IBBS) which are identifiers in ad-hoc, a.k.a peer to peer networks.
** ESS: Extended service set (SSID is technically specifically an ESSID) 


SSID often refers to an ESSID; the upshot of the difference between an BSSID and ESSID seems to be {{verify}} that:
* a BSSID is the unique identifier of a specific node (be it an AP or client) - much like a MAC
* an ESSID is the string identification of a WLAN segment/cell. That means it can refer to one or more APs, as it does in roaming setups {{comment|(Multiple APs with the same ESSID (and necessarily different BSSIDs), commonly seen in business and university networks)}}.


'Association' refers to belonging to a cell - and is separate from authentication.

===a, b, g, n, ac; 4, 5, 6, 7===


Wi-Fi is IEEE 802.11-based. Chronologically:
* <span style="color:#888">legacy IEEE 802.11, at 2.4GHz, marketed as 2MBit/s (discontinued)</span>
* IEEE 802.11'''a''' (seemed aimed at corporate use, I've never seen this in use)
** often at 5GHz
** marketed as 54MBit/s
** Decent speed up to 10m / 30feet (more outdoor / line of sight)
** (there is also a US variant in 3.7GHz, works up to 5km / 3 miles)

* IEEE 802.11'''b'''
** 2.4GHz band 
** marketed as 11MBit/s, typical throughput more like ~4.5MBit/s (0.5MByte/s)
** Decent speed up to 10m / 30feet (more outdoor / line of sight)

* IEEE 802.11'''g'''
** 2.4GHz band 
** marketed as 54MBit/s, typical throughput more like ~20MBit/s (~2.5MByte/s)
** ...which you might get at up to 10m / 30feet,  down to maybe a tenth that under significant load
** In a way, g is the best of a and b {{comment|(11a and 11b are alternatives; a is shorter-range, higher-speed, and was targeted at business use)}}

* IEEE 802.11'''n''' ("WiFi 4", because apparently we start numbering now. At 4. But yeah, we retro-numbered g as 3, a as 2, b as 1)
** can be used at 2.4GHz and 5GHz. Originally largely 2.4GHz, with dual-radio later becoming more common as more client devices support it.
** decent indoor speed up to 30m / 90feet {{verify}} and connection up to ~70 meters {{verify}}, but these are optimistic figures.
** Working at the same frequencies they are just as susceptible to walls - focused more on higher speed and a little more range, with fancier [http://en.wikipedia.org/wiki/MIMO MIMO] and some other tricks)
** Varied devices might only support the slower of the speeds belonging to the standard, ~150MBit/s, and in the real world maybe don't count on getting more than ~50-80MBit (7-10MByte/s).  Faster speeds (in theory up to 600MBit/s) not supported by all clients or APs, and would use a lot of the 2.4GHz spectrum to do so, so that is ''unlikely'' to ever happen.
** 5GHz variant a little less range than 2.4GHz, but a dual-radio AP has more frequency to give out, so more devices that don't have to share bandwidth
** will only do &gt;54 Mbps when using WPA2/AES (or no encryption{{verify}}), not when using WEP or using TKIP. Can be relevant.
<!--
** Early devices were called draft-n as they complied to a draft of the 802.11n standard, before the standard was finished in October 2009. Standard and draft-n devices may work together fine, may not work, and may not give you all of the possible speed or range improvements if mixed.
** {{comment|(and depending on how you configure it it may not go faster than 54Mbit. In particular, it will do more only if you use AES)}}
-->

* IEEE 802.11'''ac''' ("WiFi 5")
** 5GHz only, but 11ac APs and clients are likely to support and fall back to 11n in the 2.4GHz band {{verify}} <!--{{comment|(there isn't enough spectrum to do ac sensibly in the 2.4GHz band)}}-->
** 80 MHz channels, supporting ~500MBps 
** ...and higher, ''theoretically'' a few Gbits, with some 'has to be supported' and 'in total' caveats faiurly similar to 11n's higher speeds

* IEEE 802.11'''ax''' ("WiFi 6")
** 2.4 and 5 GHz (and a later 6E at 6GHz)

* IEEE 802.11'''be''' ("WiFi 7")
** 2.4, 5, and 6 GHz 
** Currently in development


<!-- 
Notes:
* There are 11g cards that use some non-standard method to support higher speeds, with mentions of 108, 125 and 140 MBit/s. This only works when access point and clients use exactly the same technology, and may only work under ideal conditions (low interference, devices close together). Again, creative marketing still applies; a 100Mbit wire tends to ''noticably'' outperform any of these.

** Atheros's Super G - 108Mbps, uses two channels (and so increases interference around it)
** Broadcom's 125HSM {{(originally introduced as Afterburner}} - 125Mbps on one channel 
*** licensed to other vendors, who market under other names, such as g+ SuperSpeed, G Plus, HSM, Turbo G, SpeedBooster. However, these are not ''not'' necessarily compatible with each other.
** Conexant's Nitro - 140Mbps

http://en.wikipedia.org/wiki/125_High_Speed_Mode
http://en.wikipedia.org/wiki/Super_G_%28wireless_networking%29
http://en.wikipedia.org/wiki/Nitro_%28wireless_networking%29
-->

<!--
* 802.11n's 300Mbit refers to channel bonding, using two non-overlapping channels that can each do up to ~150MBit/s. 
** In the 2.4GHz range this the access point occupies 40MHz, about half of the space there - which is is a bad idea when there are a lot of other access points around, because interference becomes a given (even 20MHz channels is already a problem with a handful of APs).
** When this means you interfere with more neighbours, you won't see much speed increase
** Some 300Mbit APs will automatically turn off channel bonding when they notice they a lot of interference

* 11n APs are usually 2.4GHz
* ...and various 11n clients are 2.4GHz-only


* On mixing networks:
** 11b+11g APs with a mix of 11b and 11g clients will affect the speed of both 11g and 11b clients. Exactly how much overall throughput is affected depends on what's under the hood, but if speed is important you should avoid it if you can. 
** Running a mix of (draft) 11n and 11g (or 11b) on the same channel (same AP) will affect both 11g and 11n clients {{comment|(apparently 11g more than 11n, but both noticeably)}}
*** so if you have more 11g clients than 11n clients you may want to use your 11n router in 11g mode
*** ...or in 11n mode on a different channel while leaving your old 11g routers in place.
** (There's probably a similar issue in the 5GHz band if you run 5GHz 11n and have 11a {{comment|(at 5GHz; most is)}} around, except that 11a is fairly rare in most places)
** Don't believe any statements (including those here) until you've seen actual test results, and with a bunch of varied hardware as things can vary per specific chipset. There are few decent posts/articles about this.

-->

===Other letters===

There are a ''bunch'' of amendmends over time, standardized in other letters,
some of which are commonly supported but not advertised to customers because even if they help, they're not as known as the speed ones. 

Consider:
: [https://en.wikipedia.org/wiki/IEEE_802.11d-2001 d] - country roaming extensions
: [https://en.wikipedia.org/wiki/IEEE_802.11e-2005 e] - QoS, packet bursting 
: [https://en.wikipedia.org/wiki/IEEE_802.11i-2004 i] - WPA2 (roughly. the WPA names were historically confusing)
: [https://en.wikipedia.org/wiki/IEEE_802.11k-2008 k] - attempts better traffic distribution
: [https://en.wikipedia.org/wiki/IEEE_802.11r-2008 r] - fast roaming

...and some of which specific-purpose, like:
: [https://en.wikipedia.org/wiki/IEEE_802.11p p] - vehicles
: [https://en.wikipedia.org/wiki/IEEE_802.11s s] - (fixed) mesh networking

: [https://en.wikipedia.org/wiki/IEEE_802.11af af], [https://en.wikipedia.org/wiki/IEEE_802.11ah ah] - in TV bands, non-licensed bands (slowish, but useful for specific purposes, like wireless mics, maybe IoT)

: [https://en.wikipedia.org/wiki/IEEE_802.11ad ad], [https://en.wikipedia.org/wiki/IEEE_802.11ay ay] (WiGig) {{comment|(note: at much higher frequencies than the similar-speed ax. Expect wigig to only work within a room)}}


See also:
* https://en.wikipedia.org/wiki/IEEE_802.11

===On signal strength, noise, quality and such===
{{stub}}

'''Signal Strength''' often refers to '''RSSI''' (Received Signal Strength Indication), which is a measure of signal energy (note: not quality).

RSSI is a general RF concept and measured in dBm (so an absolute value). However, in 802.11 standards it is ''not'' tied to a real measure, so any given WiFi hardware may report it in dBm or, probably more commonly, something that only sort of resembles it.
Different vendors (even different drivers) may report different RSSIs in exactly the same situations.

This value is continuously calculated because it is used internally, for example to check whether a channel is currently clear to send on {{comment|(This is also one reason RSSI may be truncated above a certain good-enough value, and another reason that it shouldn't be taken as a physical measure)}}

RSSI can in general only be taken as a relative measure of signal strength, comparable only to other such measures from the same card.  



'''Signal to noise ratio''' is a fairly well known term, but its use in WiFi is somewhat different; Wifi's SNR also regularly refers to the strength of a signal above the noise floor. The '''noise floor''' refers to RF energy that isn't part of the 802.11 transmission, which can often be estimated/assumed to be on the order of -100dBm {{comment|(that value apparently an implication of some of the realities of WiFi, such as the  20Mhz channel width that 11b and 11g have)}}. 
It obviously obviously varying between environments, and in noisy neighbourhoods it may be something like -92dBm{{verify}}


An example of such above-noise-floor calculations: Say you have a noise floor of -94dBm {{comment|(about 4*10<sup>-13</sup> Watt)}} and a RSSI of -65dBm {{comment|(about 3*10<sup>-10</sup> Watt)}}, then you could say you have a SNR / signal quality of 29.

While neither the only or the best way of calculating signal quality, '''Signal quality''' often refers to this.
Arguments against this use include that signal quality should be a measure of how the actual signal is getting through, not how strongly it seems to be received. However, it is a convenient estimation (partly because of the ease of reporting RSSI - the hardware is continuously doing it anyway).


Apparently:
* ~10dB above noise floor (around -90dBm) will get you a weak and slow signal
* ~20dB above noise floor (around -80dBm) starts being decent
* ~40dB above noise floor (around -60dBm) or better tends to be necessary for full speed operation (54Mbit in g, up to 300 in n)


These figures rely on both relatively ideal hardware and an interference-free environment.
Other factors (including receive sensitivity) may mean that in practice, the figure may easily be 10 or 20dB worse.

<!--
There is often some SNR below which a WiFi card won't even try to associate with an AP even though it theoretically get some data through now and again-->.



'''Receive(r) sensitivity''' (...glossing over some details...) indicates the weakest signal that a particular device can discern and actually use (...assuming it's above the noise floor).

Receive sensitivity is a property of the hardware design, varies with technology used (a/b/g/n).
It is also worse for higher speeds because more power is needed. This is part of why a weak signal means you may get a slower connection.


It seems that you can expect fancier hardware has a receive sensitivity of around -96dBm, while particularly cheap hardware may be -70dBm {{verify}}.

Remember that (roughly) 3dB is a factor two power difference and 10dB a factor ten. This means that difference is prety huge; -96dBm may support hundreds of meters and -70dBm may mean a few meters (assuming ~35mW transmissions, which many laptops won't go above).

In theory, sensitivity can be useful for the amount of APs you need to cover an area, and is useful to know in mesh networking -- but for most clients and most consumer devices (specifically the client-to-AP communication) this is not often something you have much of a choice over, so it doesn't pay to be too optimistic.

<!--
Using monitor utilities you may see an unnassociated AP's signal strength alternate between two signal qualities. This is likely because of antenna switching between different-gain antennas (AP strength indication is based on a beacon frame's RSSI, and it is sent on all antennae).

Only once associated will you actually be services via a specific antenna, so the strength flip-flopping should stop and you should get the stronger signal.
-->



See also lists like:
* http://www.dd-wrt.com/wiki/index.php/Glossary

==WiFi frame notes==
<!--

The layer 2 (data link) part of WiFi (802.11) can be viewed as a different type of Ethernet frame (most wired home networks use [http://en.wikipedia.org/wiki/Ethernet_II_framing EthernetII framing]).


The first 24 bytes of a wifi frame are always the same structure:
: 2 bytes: frame control
: 2 bytes: duration ID
: 6 bytes: Address 1
: 6 bytes: Address 2
: 6 bytes: Address 3
: 2 bytes: sequence control

What comes after depends first on the frame type and subtype, which are in the first byte of frame control, and in some cases on further details.

There is also a sort of checksum at the end {{comment|(but whether that's handed to you or stripped of as being PHY layer depends on the interface you read these with)}}.



See also:
* http://grouper.ieee.org/groups/802/11/
:: you probably want just [http://standards.ieee.org/getieee802/download/802.11-1999.pdf

Note to self: read 
: http://www.wi-fiplanet.com/tutorials/print.php/1447501
: http://www.wi-fiplanet.com/tutorials/article.php/1492071
: http://www.wildpackets.com/support/compendium/manual_appendices/nxA1_AP
: http://www.javvin.com/protocolWLAN.html



''''Frame Control'''

Consists of two bytes. The first:
* Bits 0 and 1: Frame version (802.11)
** 00: the current value. Others are reserved, for possible future incompatible revisions

* Bits 2 and 3: Frame type:
** 00 Management
** 01 Control
** 10 Data

* Bits 4 to 7: Frame subtype. The meaning of these bits depends on the frame type.
** For management frames, the value/functions are:
*** 0x80 for beacons (APs advertising, often 10 per second)
*** 0x40 for probe request, 0x50 for probe response (new clients asking for somewhere to go)
*** 0xb0 for authentication, 0xc0 for deauthentication
*** 0x00 for association request, 0x10 for association response, 
*** 0x20 for reassociation request, 0x30 for reassociation response, 
*** 0xa0 for disassociation
*** 0x90 for Announcement Traffic Indication Message (ATIM)
** For Control frames, the functionality includes:
*** ACK (acknowledgment, error detection, indirectly speed adapting)
*** CTS and RTS (reducing collisions)
*** PS (Power save poll)
*** Contention-related
** For data frames, this:
*** is 0 for basic data, so byte is 0x08 in this case 
*** is non-zero mostly with contention functions at work

The second:
* Bit 8: To DS    ('Distribution System', read: Access Point)
* Bit 9: From DS
* Bit 10: More Fragments coming
* Bit 11: Retry ('is retransmission')
* Bit 12: Power Management ('will enter after this packet')
* Bit 13: More Data ('data has been buffering, expect more from me soon' - for optimization{{verify}})
* Bit 14: WEP
* Bit 15: Ordered



Examples of specific frames:

Beacon frames:
 64 bits: timestamp
 16 bits: beacon interval
 16 bits: capability info
 SSID, meaning
   8 bits:   element number
   8 bits:   length
   variable: AP name
 variable: supported rates

Probe request frames:
 SSID, meaning
   8 bits:   element number
   8 bits:   length
   variable: AP name
   ...with the exception case that length 0 means broadcast SSID, i.e. ask for any
  (more)

Data frames:
 48 bits: Address 4
 variable: rest





Exactly what (type of) participating node each of the address positions refers to, and whether the fourth is used at all (present?{{verify}}) depends on the ToDS and FromDS bits in the Frame Control.
-->

<!--
==Basic usage (unices)==
iwconfig can be used to configure most common aspects of an interface, for example
 iwconfig wlan0 mode managed
 iwconfig wlan0 key 
 #You can give any amount at a time:
 iwconfig wlan0 rate auto essid MyNetwork channel 1 

You can also join APs with it:
 iwconfig wlan0 ap 00:11:22:33:44:55
 iwconfig wlan0 auto        #or any, 'associate with current best' 
 iwconfig wlan0 off         #goes to auto without changing current association
When it is protected with WEP, you can set a password, hex key:
 iwconfig wlan0 key ABABABABABABABABABABABABAB

The key is als used when acting as an AP.


When snooping, you may want to do something like:
 iwconfig ath0 mode monitor
 iwconfig ath0 channel 6
...though many tools do it themselves.


Scanning for APs

-->

==Security==

===Encryption (and authentication)===
{{stub}}


<!--

There was always a bit of a scale of requiring strong security but excluding some devices, and allowing weaker security.
: Does it support WEP but not WPA? WPA but not WPA2? WPA2 but not WPA3?


Keep in mind that if you communicate TLS / HTTPS, then the medium over which you matters much less.

And if your communication is plaintext, then there actually are other things to worry about anyway.

Even if wifi is secure over the air, it's serves just the last bit of the whole.
It's like hiring a really good delivery guy for your packages, and not thinking about the rest of the mail system:
That AP will soon be plugged onto a wire, where the on-the-air encryption does not apply. 


So it absolutely thwarts passive snooping, 
and some "put device in corner for that will eventually discover a thing" style attacks,
and for the more serious attacks



For some it's not even about that.
Also, from what I read, some countries' courts make you liable for everything on a network you own ''even if they got there unwholesomely''.




Major OSes support everything {{comment|(though 802.1x isn't always smooth sailing)}}, but some simpler and older WiFi devices, like some WiFi toys, may only do WEP, not WPA, or may only do the more basic/early WPA stuff and not so much WPA2.
-->

In WiFi, encryption is moderately tied to authentication -- the passphrase is 


Broadly, the on-the-air encryption options are:
* None (no access control, unencrypted traffic)
* WEP ('''W'''ired '''E'''quivalent '''P'''rivacy) {{comment|(had viable attacks for ages, has been considered deprecated for ages)}}
* WPA and WPA2 ('''W'''i-Fi '''P'''rotected '''A'''ccess), both referring to parts of 802.11i 
* WPA2 is more secure than WPA is more secure than WEP (is more secure than nothing)
* WPA3 

...but more accurately, the references and acronyms you'll want to learn include:

* 802.11i - 802.11i-2004 was a security amendment at the time, that has since been incorporated into 802.11-2007.
** A security suite, a good chunk of which is used in WPA, and all in and WPA2{{verify}}. 
** Deprecates WEP.
** including CCMP (a.k.a. AES-CCMP),

* 802.11x - doesn't exist. You're thinking 802.1X, which isn't part of [http://en.wikipedia.org/wiki/IEEE_802.11 802.11]

* 802.1X - encapsulates EAP [http://en.wikipedia.org/wiki/IEEE_802.1X]

* AES - a cipher with various modes
:: in this context usually refers to AES-CCMP, a.k.a. CCMP
:: some of those acronym variants were used as near-synonyms in the context of WiFi, [http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol], though this is less sensible now with WPA3

* CCMP - cipher based on AES (mandatory part of WPA2, though a few WPA had it too).

* EAP - Extensible Authentication Protocol - an authentication framework.
** authentication: relates only to how the network accepts you, not directly to the encryption used
** framework: has various options, allows some extension
** Terms like "'''Enterprise''' WPA/WPA" often refer to logging in with personal credentials <br/>{{comment|('''Personal''' (arguably not a great name) usually to pre-shared keys (see PSK below) where everyone uses the same)}}
** When EAP is configured, an AP probably only allows EAP traffic from a client until the client has used EAP to authenticate (usually via some login server)
** There are quite a few specific EAP implementation/methods, including 
*** PEAP (Protected EAP)
*** TLS
*** TTLS (Tunneled TLS)
*** LEAP - seems a hardware feature in some pricier wifi cards, though it seems flawed in that it allows for offline dictionary attacks. See e.g. [http://www.lanarchitect.net/Articles/Wireless/LEAP/index.htm]. It seems it ''will'' protect against wardrivers with cheap (non-LEAP) cards.
<!--
Phase 2 auth:
* None
* PAP
* MSCHAP
* MSCHAPV2
* GTC
-->

* PSK - Pre-Shared Key 
** Mostly the concept of using a secret that is shared by everyone on the network, and basing the encryption on that
** ...as opposed to personal authentication, and/or private keys, is possible (but not common) within EAP
** PSK are not secure/insecure ''per se'', but some designs/uses are
** PSKs can be expected to ''not'' change, so if the cryptosystem that uses them is weak, that's a weak spot in security
*** WEP's PSK is breakable based on just listening to traffic. 
*** TKIP (common in pre-WPA2 WPA) uses (and cycles) keys based on the PSK, making it less interesting to find the on-air key, and harder to find the PSK. TKIP does have some milder weaknesses, though.
** In some situations you'll see PSK referring to TKIP+PSK (WPA) and PSK2 referring to AES+PSK (WPA2), though this seems to be non-standard shorthand terms {{verify}}

* TKIP - a cipher algorithm (used in WPA and WPA2, no longer in WPA3) [http://en.wikipedia.org/wiki/Temporal_Key_Integrity_Protocol]

* RSNA - a method/setup (handshake, key exchange, cipher choice). Mostly synonymous with what was first 802.11i, now part of 802.11. Pragmatically perhaps most comparable to WPA2.

* WEP - is mostly a cipher algorithm (while WPA and WPA2 allow a choice)

* WPA
** sort of an interim semi-standard while 802.11i was written. Effectively a subset of the full 802.11i standard.
** cipher: TKIP or sometimes AES/CCMP

* WPA2
** mostly in line with RSNA/802.11i. The term RSNA is sometimes used where it is more accurate and/or less confusing.
** cipher: TKIP or AES/CCMP

* WPA3
** required on new certified devices, and in Wifi 6 and 7{{verify}}
** cipher: (a larger variant of) AES (no TKIP) [https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#WPA3] {{verify}}


<!--
* Enterprise variants (WPA-Enterprise, WPA2-Enterprise) refer to adding a 802.1x auth protocol. If you don't use that, you're probably using the PSK variant of the same thing.
-->


Further notes:
* "TKIP+AES" seems to just be a "allow both AES and TKIP, to avoid denying clients that can't do AES". {{verify}}

* "WPA2+WPA" is much the same story {{verify}}

* You could say the basic ciphers used are WEP, TKIP, and AES/CCMP 


See also:
* http://en.wikipedia.org/wiki/Wireless_security
* http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
* http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access
* http://en.wikipedia.org/wiki/IEEE_802.11i
* http://en.wikipedia.org/wiki/IEEE_802.1X


TODO: read:
* http://en.wikipedia.org/wiki/IEEE_802.11i-2004

* http://www.networkworld.com/research/2002/0506whatisit.html
* http://www.wi-fiplanet.com/tutorials/article.php/1041171
* http://hostap.epitest.fi/wpa_supplicant/

* http://en.wikipedia.org/wiki/Wpa_supplicant


* http://asleap.sourceforge.net/

===WPS, WCN, and such===
{{stub}}

WPS (Wi-Fi Protected Setup, originally Wi-Fi Simple Config) should make it easier (avoid config screens) to set up wireless security. 
: Often makes it easier to point a specific device and AP at each other.
<!--
: options:
:: PIN: number on the sticker on the device
:: button: makes it pairable until a device connected, or up to 2 minutes later or so
:: NFC (optional) -
:: USB (optional, deprecated) -  
-->

WCN (Windows Connect Now) is similar to WPS, but specific to Windows (and defines fewer options for binding{{verify}}).


There are other systems building on these, with other names{{verify}}.


See also:
* http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup
* http://en.wikipedia.org/wiki/Windows_Rally#Windows_Connect_Now
* http://www.microsoft.com/windowsxp/using/networking/getstarted/windowsconnectnow.mspx

<!--
===Cracking, anti-cracking measures; checking your security===

Consider what you want to protect against - accidental connection, casual snooping, or targeted attacks. A lot of suggestion are for the last case and a little over the top for the first two.


WEP used to be the most common, but is flawed enough that you could crack it from only captured packets. You can do an offline statistical analysis on them, so the only thing that delays WEP being cracked is time: amount of packets captured, and CPU. Since it can sometimes be cracked in a few minutes, WEP is not good against targeted hacking.


TKIP is more secure. You can still try an offline dictionary attack, but to do this you need to capture packets that only happen when a client newly connects.
Some other systems have some harder-to-exploit weaknesses.



The general steps of cracking are:
* decide what AP (and thereby SSID and channel) to capture packets from. There has to be traffic, so an AP has to have at least one active client.
* capture interesting packets. Some tools capture everything, some capture data specific for an attack, such as encrypted WEP data packets or a WPA handshake
* Optionally do things to cause more interesting packets (often disruptive)
* decypher key based on packets


A stealthy scan would only listen for packets (monitoring nodes no not transmit, so are undetectable). 

Active but still subtle and applicable particularly to WEP would be to cause more interesting packets - but this can be hard, depending on the type of encryption and the protection it has against packet injection.

The harsher alternative to getting IVs is to trigger deauthentication, since the reauthentication step will also have a few IVs. However, this disturbs the network and generates fewer packets than ARP injection does, if that works. It is still interesting to do for WPA, because WPA attacks are dictionary/brute force attacks on the authentication handshake{{verify}}.


 http://www.tomsnetworking.com/2005/05/18/how_to_crack_wep_/page4.html


'''WEP Attacks'''

Cracking WEP is a probability thing. WEP has shared keys, which are obviously not directly communicated themselves, but WEP's transformation of the key {{comment|(adding the key to an initialization vector (IV) and use that as a basis for encryption)}} means that each encrypted package may reveal information about the key - in a statistical way when you have a load of other packets.
There are some variations on WEP that are stronger, but they are/were not widespread, nor easily added to existing networks, and mostly just decrease the magnitude of the problem a bit rather than solve it.

Most attacks analyze packets with unique IVs, and since that happens in normal WiFi operation, you mostly just want to capturing as much encrypted traffic as possible {{comment|(more may mean the analysis on the packets may finish faster)}}. In practice, you often work on ARP packets because most any network uses it, and its packet contents are relatively easy to guess.

Some Wifi hardware/drivers won't allow capturing of the encrypted packets, and will only serve you packets that are successfully decrypted by the key you set for the interface. You need 'monitor mode', which is possible on a good set of cards under linux, fewer on windows.


The attacks:
* An early attack relied on observing weak IVs, originating in bad driver decisions, which have mostly been patched. (FMS? {{verify}})
* An early cryptanalyric, probablistic attack needed millions of packets [http://www.theregister.co.uk/2001/08/07/wireless_security_is_even_flakier/]
* Korek's attack (2004) has the the requirement that they have different IVs, but works on hundreds of thousands of packets. (you have decent chances with ~100k-300k for 64-bit WEP (40-bit key, 24-bit IV) and ~500k-1.5m for 128-bit WEP (104-bit key, 24-bit IV)
* There is a 2007 attack that will probably get the key with under 100k packets. ([http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/ aircrack-ptw], included in the current [http://www.aircrack-ng.org/doku.php?id=&DokuWiki=f7015bfb4b9e649ef625523b9457c1c8#development development version of aircrack-ng]) [http://www.theregister.co.uk/2007/05/15/wep_crack_interview/]



'''Packet injection'''

There are various things you can do to get more IVs. Packet injection ''does'' require a driver to support writing out raw packets. You also want to listen to the results of these actions at the same time; if your driver does not support doing both at the same time, you will need a separate adapter or separate computer.


''ARP replay'' is common, because it is automatic and non-disruptive. The utility listens for ARP requests, and retransmits any it receives.

This works because when a client associates with an AP, there is a round of ARP requests, responses, and apparently ARP rebroadcasts. The idea is that you can listen to and replay what you know are encrypted ARP requests, causing new ARP responses which, being new traffic generated by nodes inside the network, are data packets with new and unique IVs - yet you can do this without knowing anything much about the encrypted packet contents, or being on the network. Since ARP itself is a stateless protocol and necessary for IP to work, it will generally be honoured. It is possible to be smart about detecting this injection, but there is not too much you can structurally do about it.


''Deauthenticating clients of an AP'' will cause clients to reauthenticate, which will involve IV packets on WEP, and four handshake packets in the case of WPA-PSK. (To avoid missing one, listen to just the one channel) 

The reassociation will also reveal the SSID of cloaked APs (cloaked meaning 'not beaconing', not 'actually hidden') This of course applies only when there is a connected client around to be deauthenticated.

However, this only barely help generate IVs, and disturbs the network itself.

-->

<!--
APs will give you some leeway of association before you have to authenticate on that network. ''Fake authentication'' works on some APs to keep you associated, which means it will keep responding to other things you send{{verify}}.

If the AP uses MAC filtering, you will need a valid client's MAC, one that isn't currently connected{{verify}}.


See also [http://documentation.netgear.com/reference/fra/wireless/WirelessNetworkingBasics-3-06.html] for a summary of WEP security, or the IEEE standard for details.
-->


<!--
=====Step by step=====
On unices, you want to know about:
* iwconfig, to set the card in various modes, join APs and such
* airodump or kismet for monitoring and dumping
* aircrack for cracking (primarily WEP), 
* aireplay (and possibly things like void11) for active interference. 
* You can use airdecap to double-check check a key against the data it should apply to.


'''Getting started'''

When a utility doesn't set monitor mode, channel, or bssid for you, you have to do it yourself, e.g. with:
 iwconfig ath0 mode Monitor channel 6
Read man iwconfig for details. Run iwconfig, or airmon(-ng), to choose an interface.

Note: The madwifi drivers allow the creation of several VAPs - multiple virtual interfaces as children of wifi0 (first card), often called ath0, ath2, etc. When you get strange errors, you probably aren't using the right interface. Kismet and injection utilities generally want the parent.


'''Basic capture'''

Capturing programs channel-hop by default, meaning they spend e.g. 100ms on each channel and therefore miss most of all channels' data. This while in relatively quiet neighbourhoods, you often only see three or four channels in use. You can roughly judge channel usage by the amount of AP beacons received; APs (that aren't trying to hide) tend to send out ten per second. (Note: cloaked ones can be inferred to exist when there is data traffic, by a smart enough monitor/capture program)

To focus on only a few or just one channel, you specify it to the dumper. Setting this in kismet is a little harder (see its config file, <tt>sourcechannels</tt>), so I use airodump, specifically airodump-ng:
 airodump-ng ath1 -w filebasename -c 6,7,1,11
This is a lazy, leave-it-around-to-capture-packets-from-the-channels-I-noticed-were-majorly-used method. When focusing on a single AP, set the single channel it serves on. 

You can use --ivs to only save packets with IVs, which saves space. However, this apparently also throws away packets interesting for WPA cracking, so if you want to to that, don't. Kismet, on the other hand, seems to save beacons as well, which is a little wasteful unless ispecting what's on the air.


'''Crack'''

Once you have enough data you can run aircack on this data. In fact, since airodump regularly writes its data, you can run aircrack while airodump is running. There is little for you to do here; you select what SSID you want to figure the key for either on the command line or from the menu if you run it without options:
 aircrack-ng *.cap
For WEP you'll see the amount of IV packets, for WPA the amount of handshakes. WPA (TKIP/PSK) can be attacked if you specified a dictionary file using -w (you can use this on WEP too, but there's usually no point as it only works when a readable passphrase was used).


'''Packet injection'''


''ARP replay'': 
 aireplay -3 -b AP_MAC -h associated_client_MAC ath1
This also stores the captured packets.

''Deauth'':
 aireplay -0 2 AP_MAC ath0
 #-0 is the death attack, 2 is the amount of deauthentications to send.



The following example:
 aireplay -0 20 -a AP_MAC -h SOUCE_MAC ath1
will 
 # 2 is the delay



Cloaked
 aireplay -0 2 -a <a/p MAC> ath0


Notes:
* Read a suggestion that WPA handshake usually happens in G, while aireplay -0 happens in B.


http://www.aircrack-ng.org/doku.php?id=faq


See also [http://www.aircrack-ng.org/doku.php?id=aireplay-ng] 

[http://www.grape-info.com/doc/linux/config/aircrack-2.3.html]
[http://www.tomsnetworking.com/2005/05/18/how_to_crack_wep_/page3.html]
[http://www.tomsnetworking.com/2005/05/18/how_to_crack_wep_/page6.html]
[http://www.netstumbler.org/showthread.php?t=15497]
[http://www.wirelessdefence.org/Contents/Aircrack_aireplay.htm]
http://www.governmentsecurity.org/archive/t15149.html
http://www.grape-info.com/doc/linux/config/aircrack-ng-0.6.html
http://hackathology.blogspot.com/2007/03/cracking-wireless-network.html
-->

<!--
'''Other'''
When you notice an AP filters clients by MAC, you can imitate a MAC with:
 ifconfig ath0 hw ether MAC_address
Note this will likely cause some problems if the actual client with that MAC is also online.




'''WPA'''

WPA is much stronger than WEP, see e.g. [http://www.informit.com/articles/article.asp?p=369221&rl=1]. 

WPA is only bruteforceable, but since consumer-grade WPA (apparently that based on WPA-PSK{{verify}}) is based on passphrases, this introduces weaknesses where humans are allowed to define the passphrases - we are quite bad at unpredictability.

You also need the SSID for this attack, which is mentioned as harder to get at under WPA. It will only appear in probes (new client) or reassociation, so will often take more than a few minutes.

See [http://www.informit.com/articles/article.asp?p=370636&rl=1 this] for more.

The program to use seems to be coWPAtty (See [http://sourceforge.net/projects/cowpatty sourceforge page] and [http://www.securiteam.com/tools/6L00F0ABPC.html one description].



'''Crack prevention'''

WEP, now, is basically dead. Instruction pages like this only prevent entirely everyone from being able to do it by having requirements of linux, hardware, and being able to read happy-geek.

Use some form of WPA. There is currently only a dictionary attack against WPA-PSK, for example, so a long and automatically generated password (less predictable than human ones) is quite strong.


Of course, secure tunneling also the very goal of securing an insecure channel, so if you are served by encrypted VPN or even just SSH tunnels, this may at least be cheaper than replacing a network that doesn't fully support WPA.

-->

<!--
====Simple measures====

'''MAC filtering'''

You can tell your AP or computer to not route anything that is not from known clients, by MAC address. 

Only effective against accidental connections, not work against hackers of any competence (unless they don't have the time to notice this filtering).

This because MAC addresses identify a client so ''have'' to be transmitted. This means that they are trivial to discover when there's traffic around. It is usually not very hard to spoof.

If you won't or can't use WEP or WPA, then MAC filtering becomes somewhat interesting. Still, going by the above it comes down to blacklisting the bad connections you notice, which will probably mean a lot of attention and a good bit of missed cases.



You can generally whitelist and blacklist MACs.
-->
<!--
MAC whitelisting, means that you disallow all clients except the one you have.

though usually a useful thing, can be quite bothersome - you have to dive into your configuration every time someone with a laptop or wifi toy comes by. 

If you want to be wifi-ly social but don't want accidental connections, you generally want to '''use WPA or even just WEP instead.''' Even if you have an trivial to remember password that everyone in the house knows, say, 'fish', it'll block connections from non-hacker strangers just as hard.


'''MAC filtering in iptables'''

There exists a <tt>mac</tt> match type, and it has exactly one option, matching source address. If you want to match destination you will have to use u32, but for basic filtering you don't need it since you just filter everything coming into INPUT.


Note the effect is that clients will still be associated with the AP but won't be able to get traffic through. This is rather annoying for people that have a device that just chooses a random unsecured AP, because it won't work without an apparently good reason. It's nicer to reject MACS from associating (rejection at the WiFi level), see below.


Assuming you want to blacklist this way anyway, rules would look something like:
 iptables -I INPUT -m mac --mac-source 00:50:BA:11:22:33 -j REJECT
-->


<!--
====iwpriv (prism / madwifi)====
{{comment|'''Note:''' did not work in my tests, so may involve more details}}

To avoid association by wireless clients claiming to have particular MACs:
(See also [http://madwifi.org/wiki/UserDocs/MacFiltering])

Whitelist:
 iwpriv ath0 maccmd 1   # set policy to whitelist     (that is, 'reject all others')
 iwpriv ath0 maccmd 3   # flush MAC list
 iwpriv ath0 addmac 00:01:02:03:04:05
 iwpriv ath0 maccmd 4   # deassociate all

Blacklist:
 iwpriv ath0 maccmd 2   #set policy to blacklist     (that is, 'accept all others')
 iwpriv ath0 maccmd 3   # flush MAC list
 iwpriv ath0 addmac 00:01:02:03:04:05
 iwpriv ath0 maccmd 4   # deassociate all

Notes:
* delmac also exists.
* 'deassociate all' practically means reassociation
-->


<!--
'''Disabling beacons on the AP (and 'SSID cloaking')'''

Only works against accidental connections, not hackers of any competence.

Access Points usually send out about ten beacons per second, which are small packets announcing the presence of said access point.

Beacons make scanning for APs possible and easy, and also lets you roam. They aren't strictly necessary - if you know an AP's there, it doesn't need to be sending out beacons.

Some people seem to think that would add security, perhaps because of the fancy name, 'SSID cloaking'. 

Yes, it will mean your AP will not show up in "look for nearby access point" lists. But it will ''not'' hide your SSID from prying eyes.
Various other packet types besides beacon ''necessarily'' contain the SSID, and if it's in the air, it's sniffable - even if it takes a little more cleverness.

-->

====Software====

App lists:
* http://wiki.personaltelco.net/index.cgi/WirelessSniffer
* http://www.sheerboredom.net/modules.php?name=News&file=article&sid=79 (utility list)


'''Discovery'''

Linux:
* Kismet
* [http://nixgeneration.com/~jaime/netdiscover/ netdiscover]

Windows:
* inSSIDer [http://www.metageek.net/products/inssider]
* Xirrus Wi-Fi inspector [http://www.xirrus.com/library/wifitools.php]
* Netstumbler [http://www.netstumbler.com/] (apparently not as smart at discovery as * kismet, but is easier to get running] (Not under Win7/Vista)
* Kiswin (limited in terms of drivers, though {{verify}})
* Javvin?


'''Dump'''

* Kismet
* aircrack
* airsnort

Windows:
* winairsnort

weplay?
The brute forcer way probably doesn't dump the lower-level wireless packets{{verify}}.


'''Attack/Decypher'''

Linux:
* Aircrack, the name of a package that has a dumper (airodump) and cracker(aircrack)
* Aircrack-ng [http://www.aircrack-ng.org/doku.php] (WEP cryptanalyitically, TKIP-PSK WPA dictionary)

* Airsnort [http://airsnort.shmoo.com/] (brute force?)
* weplab (brute force but also analytic?{{verify}})
* coWPAtty (TKIP-PSK WPA, brute force, see e.g. [http://www.wirelessdefence.org/Contents/coWPAttyMain.htm])



Windows:
* Aircrack-ng [http://www.aircrack-ng.org/doku.php]
* Aircrack [http://www.grape-info.com/doc/win2000srv/security/aircrack-2.3.html]
* Airsnort [http://airsnort.shmoo.com/windows.html] (brute force?)
* weplab (brute force, so slow)


'''De-authentication'''

Linux:
* Void11
* wlan_jack
* essid_jack

To read:
http://www.wirelessdefence.org/Contents/Aircrack_aireplay.htm


'''Anti-hacking'''

* [http://www.blackalchemy.to/project/fakeap/ FakeAP] throws around a lot of AP beacons, which should confuse sniffing a little - but also freely roaming clients.


<!--
'''Unsorted'''
* http://searchsecurity.techtarget.com/generic/0,295582,sid14_gci1167611,00.html (attack list)

* http://www.burngreave.net/node/285 (crack instructions)

* http://sourceforge.net/projects/weplab

* http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.802.11ag.html


If there is more than one AP around, you want to add the MAC of the one you want to the airodump parameters; it will filter out packets not related to that AP.

Note you can run aircrack on these dumps even while airodump is still dumping them.



Auditor liveCD: [http://www.remote-exploit.org/index.php/Auditor_mirrors Auditor], which also supports a fair set of wireless cards.

-->

===On tracking and revealing information===

Because WiFi was conceived more as a residential thing, before mobile phones, there are some details that are less than ideal. 

Some are overstated, some are a indeed a little privacy-leaky.



====For context==== 
<!--

'''Unique devices'''

At hardware level, each device needs a unique identity, but because can't talk to any specific device without it
: (...efficiently. The alternative is akin to a room full of shouting people and about as efficient to communicate in)

For WiFi, this is the MAC address (e.g. Ethernet, and blutooth are similar)


'''Monitor mode'''

A bunch of wireless hardware will only expose packets that are for you, from an associated AP.

Some have a monitor mode, which means you can capture without having to associate with an AP{{verify}} (and, usually, cannot send in this mode). 

This usually will still only let through management and control packets, not data that is for you.{{verify}}



'''Beacons and probes'''

Beacons: Most access points send out an "I am an AP with this name" ten times per second.


Probes:
: A probe request is actively sent by clients, and either
:: "Which APs are out there?" or 
:: "AP by this name, are you there?"

The latter is necessary to be able to connect to APs that hide themselves by not sending broadcasts.

Because a probe is a basic request of "''could'' we communicate" (e.g. advertises the station's data rate, for the AP to check), it serves two functions - poking the APs in your immediate vicinity, but also a necessary step of actually connecting to an AP - which involves a probe, authentication, and association, in that order.


In theory, probes might only happen when not associated, but in practice there is also value to probing while connected, e.g. to figure out whether we should switch to another AP ''before'' we lose connectivity.

So in practice, probes are ''part'' of ongoing scans the best AP it can currently connect to.




-->

===Probes and privacy===

<!--

As probes are active sending, which needs a MAC to be able to get back to you, probing while not connected reveals your presence. 

One issue is that (because a MAC is fixed) you can e.g. see how a phone moves around (by detecting it at different APs), even if you don't know whose it is, or in fact anything more about it.

The alleviation there is MAC randomisation, which makes a client use an unique MAC for every probe scan.
This only applies to probes, though. Auth and assoc is done with your real MAC.



The other thing is that probes for known APs may reveal access point names.

While AP probes are mostly for ''any'' (via a special value) or the AP it's on (which is public and known anyway), probing for hidden networks by name, whether they are currently connected to or not even around, reveals their names to anyone monitoring. 

Which is a bit backwards, and while you wouldn't care in regular use, useful information for the Karma and Evil twin attacks. 


-->

===Levels of revealing information===




===While not connected===

<!--
In theory, a client can stay perfectly silent until it sees an AP it recognizes (APs typically broadcast their presence 10 times per second).

In practice, clients may 
* probe for specific AP by name
: only really necessary for APs a client knows is not broadcasting beacons (hidden networks)
: some sources suggest some implementations may ask for the entire list of known networks?{{verify}}
:: (I don't see this when monitoring traffic, though)
: yes, this basically means you constantly tell everyone around you what your hidden network is called.

* probe for ''any'' AP.
: 

The former is necessary when you have hidden networks.
-->


====Clients on the same AP====
<!--
When people connect to an AP, you use your own MAC, so reveal who you are.


Because WiFi is layer 1 (physical) and 2 (data link),
it does not have immediate say what happens at network layer (3) (e.g. IP)


While each station talks to the AP, home networks will often allow clients to talk to each other at IP level, because certain kinds of devices and apps (e.g. home audio streaming, things like wifi controlled lights) require this.

Business and public wifi may consider the AP "Client isolation" setting, which means clients cannot talk to each other.


Client isolation at layer 3 amounts to firewalling -- but often still seeing broadcast.

So the more thorough implementation happens at layer 2, by putting each client on its own VLAN (necessary to guarantee that DHCP and ARP goes only to one client).
-->



====Can someone detect the presence of your phone even when they're connected to their AP?====
<!--

Yes. Though not hugely reliably.


Context: WiFi needs stations to have a relatively consistent identity (classically fixed addresses, much like Ethernet MAC addresses), for basic packet routing reasons. As-is, that lets anyone listening tell that a specific device has returned, throughout that phone's lifetime. So any packet for or from a specific station reveals the presence of that station.


The most basic form of network discovery is APs sending out '''beacons packets''', and devices listening passively to that, which would not allow devices to be discovered.

In practice, devices may (or may not) also be asking for specific known APs and/or for any APs, in '''probe request packets'''.
If they do, they reveal their own presence, their MAC address, and when asking for known APs, the name of those APs {{comment|(which will often be hidden APs - which are defined by not sending beacons, so you ''have'' to probe for them)}}.



You won't know what identity belongs to that device, though if you return they will know it's the same phone.

...unless the phone does MAC randomisation, in which case returning tomorrow looks like a different phone. 
People enable this randomisation for a sense of general privacy, to not give such techniques too easy a job.

MAC randomisation isn't perfect, in that specific hardware quirks still allow a good statistical guess,
see e.g. M Vanhoef et al. (2016) "Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network Discovery Mechanisms",
but ''because'' it becomes a statistical game for them, it's still pretty good idea.

-->


====Can you see where phones are?====
<!--

You hear statements like "supermarkets can detect roughly where you are in the store by your phone".


As an aside, Stores may have friendly uses for this.

Say, they could see which parts of their store have people linger,
and could decide to focus restocking there, or change the layout for less congestion. 

But it's a sliding scale.

They could also put more impulse buys there. 

They could create "people who consider buying X also consider buying Y" profiles,
because even if they don't know who it is that carries the phone, 
they know it's the same phone and therefore the same person each time.

And if they ''can'' tell who you are, there are more invasive uses, 
like "hey, you spent a while in the shoes section, let's send you an ad for shoes". 


The last requires knowing ''who'' you are, which is very hard to do reliably for anything purely passive.



For context: WiFi needs the received signal strength for various parts of good functionality (e.g. roaming, MIMO, more),
so radios measure the strength of received packets (though not necessarily expose that, but for this discussion let's assume it does).
If multiple APs in the same areas receive your packets, this allows techniques like triangulation, so with enough receivers sprinkled around you can, in theory, locate clients with an accuracy of maybe 1m or so[citation needed].

Is this simple? No.
That is, WiFi location works best with assistance of the phone itself,
because phones not currently connected to WiFi do not necessarily send out anything on WiFi.
(Looking for a wifi AP is usually a passive process - it is the APs send out beacons regularly,
not the clients).
What you can still do even then is have the phone get the received strength of all APs beacons nearby,
and send that in to a service that already has those APs mapped.



But. 

If they want to get one of the uses that relates it to people, this is actually less of a technical question.

They would probably just offer an app that gives you coupons, and/or free WiFi, 
they can get you basically give up your identity willingly.

This is easier to implement (the app may be doing the triangulation, so you don't need the infrastructure to do it), 
you probably gave legal consent via a terms of service agreement button,
and you will probably ''expect'' to be exploited a little more.

-->

====Can they know who you are?====
<!--
Generally, no. 

As mentioned, they can identify the phone, but detecting who is on it is a statistical guess at best,
and requires some other source of data to guess ''with''.

Unless you use in-store WiFi, and voluntarily gave them your identity to use it, you're fine.


In theory, enough collusion between enough big name tech corporations would expose more,  but this is unlikely to happen because they'd get into legal trouble for it, and cost/benefit-wise, it would not give them enough to risk that.
-->

====Trading privacy for features====
<!--
'''In-store WiFi'''

There's a much more practical solution for stores: Offer free WiFi. 

It means no potential legal bother for them, and more information.
 
''Particularly'' if they also get you to install an app - often via an "Oh this could only work with an app", then you can also give them personalized recommendations.


'''Telling them more for more'''

Say, offer gift cards if you answer these questions, often things like where you were,
and what you considered buying.  And things like gender and age, why not.

Requires less tech for them, isn't it fun if coupons just pop up on your phone?
Extra bonuses if you consent to being tracked!

People will rationalize that it's a lot less creepy if they gave it up themselves.
-->

===Relief===

====MAC randomisation====
<!--
MAC randomisation means a device uses a random MAC for probing (while non-connected?), so that the stations do not reveal their identity to APs they do not connect with 


This helps against e.g. shops tracking people's rough location by their phone (well, until they convince you to use their free WiFi).

Limitations:
* stations will still use their real MAC when ''actually'' connecting

* There still are some other parts of the packet that allow some amount of fingerprinting of the station 

See also:
* M Vanhoef et al. (2016) "{{search|Why MAC Address Randomization is not Enough: AnAnalysis of Wi-Fi Network Discovery Mechanisms}}
-->

===Attacks===

====For context: connection behaviour====
<!--

Since clients cannot easily know all of a named network's constituent APs (unique BSSIDs, which are basically MACs), they only really store the the readable name (SSID).

As such, they will try to connect to ''any'' AP which advertizes that name. 

{{comment|(...implementations may vary a little, e.g. doing that only when it has the same security type, but since that leads to things like "I changed my home wifi settings and now it doesn't work for reasons I don't get, your product is stupid", often not.)}}


So consider, for example, what you might get when you call your AP things like 
linksys, FritzBox, eduroam, AndroidAP, walmartwifi, holidayinn, BTWIFI, Ziggo, orange, Google Starbucks, Starbucks WiFi, McDonalds Free WiFi, Mom Use This One, any local business/university names you can find, e.g. in your phone's saved networks list, names from wigle.net}

-->

====Karma attack====
<!--

How: set up a network with a name a client will probably connect to (particularly names of public wifi, or things you ''just'' heard beaconed).
: clients will probably try to connect to them
: They'll fail and move on


What it reveals:
: their MAC -- but will have exposed their real MAC even if they have MAC randomisation
: which phones (by MAC) have which common AP names in their phones


Usually the worst this can lead to is getting phones to reveal their presence and MAC,
which if you e.g. do this at many APs may help track the rough path a client has taken.

-->

====Beacon spamming / beacon swarm====
<!--

How: Like a karma attack, but with ''lots'' of common AP names. This is a lot more visible.


What it reveals:
: a decent set of the (most common public) named APs each phone has.
: the real MAC address of a decent set of devices (the ones with at least one of these names)


-->

====Evil twin attack====
<!--

How: This is basically one step beyond just sending beacons: actually act like an AP with that name at least to the point of having them authenticate with you. 

-->


====Listening to authentication====
<!--

Just passively ''listening'' to the WPA authentication (WPA-PSK or WPA-EAP four-way handhake) does not reveal the passphrase because it is not communicated. It doesn't need to be, both sides know it already.

However - oversimplifying a little - it contains a hash ''based on'' that PMK (based on the passphrase). 

Which still lets the AP confirm that you ''know'' the passphrase, without communicating it directly.

But also means that a dictionary attack is feasible way to discover weak passwords.


As you only need to hear the authentication, this can be done entirely passively, or sped up by forcing deassociation.

(WEP was more flawed, but is rarely used anymore)
-->

====Deassociation attack====
<!--

For context: Deassociation is a client saying "I'm leaving, bye" to the AP.

If you can generate arbitrary packets, though, you can deassociate someone else. 

If you do that just once thay may not notice it as anything more than a slight hiccup.
If continuous might be bad enough effectively jam a specific client.


More than that, though, a reconnect means authentication and association - see the previous section.  

-->

==More concepts and notes==


===Roaming, range extenders, repeaters===
{{stub}}
<!--
'''Roaming''' usually refers to client ability to automatically moving between different APs.
This is common in businesses, campus networks and such.


Classically you could already give APs the same ESSID and security settings, 
and clients would figure out they could pick another.

The change may take half a second (sometimes one or two).

The handoff from one to another is handled by the client:
* look for new APs, and if a better choice comes along:
* authenticate with it (while still connected to the old one)
* reassociate with the new one, and if successful disassociate with the old one (for routing reasons)

Those APs should probably also be bridged to the same subnet and reach the same DHCP server; without those, you are actually joining another subnet with another IP, which works but means time without connectivity is longer, and that existing connections will break.


Since handoff usually means a short period of higher delays, and sometimes droppped packets, clients will generally not reassociate until they see a need - and seeing something with a stronger signal isn't enough when the old one still works (though this is sometimes configurable). AP placement so that there is one AP per space avoids some unnecessary switching.


Improvements that lower the cost of switching to another AP in the same network (grouped as something like  'fast roaming') include:
* 802.11k - lets the AP inform a client that it getting too far away, and provides some known alternative APs
* 802.11v - informing clients of the network topology
* 802.11r - Fast BSS Transition, e.g. letting some things happen in parallel and from caches (so that a full, slower 802.1X negotiation isn't necessary){{verify}}
{{comment|(Technically this is still handled by the client, so isn't handoff/roaming in the sense e.g. mobile cellular network does it)}}


Technically separately, but practically often considered at the same time, at larger scales you probably want
* a way to manage APs centrally and push the configuration to all your APs.
* multiple wifi networks from the same set of APs
* network virtualisation like VLANs



Part of such improvements were vendor-specific, meaning this is usually only interesting when you have a larger building and a sysadmin.

Even without them you could ''assist'' roaming somewhat, e.g.

APs ''can'' assist roaming, usually with relatively brute force. Examples:
* disassociates all clients with a low RSSI
: can make sense e.g. when you have an AP on the ground and second floor, and they ''just'' reach each other, but people will generally stay on the floor they are
: note that lowering transmit strength may also help

* cooperatively decide there's a better choice and disassociates a client because of that.
: This mostly forces the client find an AP with better bandwidth, though does not avoid the handoff delay.

'''Zero-handoff''' means APs all have the same BSSID (and channel, which isn't always ideal), meaning the client ''cannot'' tell them apart, and the management controls which actual AP communicates with a client at any time.



-->




<!--
XXX


Ideally they should act like a bridge, though that's largely a point of smooth-sailing convenience. If each AP does its own DHCP, then you'll change IP address, which breaks existing connections. You want to avoid that for smooth VOIP or if you tend to have SSH connections open -- but if you e.g. decide to do this with your neighbours out of convenience of not having to ask about passwords, and accept that skype will take a few seconds to adjust somewhere.


All of those are short enough not to break existing TCP connections, 
though for time-critical things (like VOIP calls) it will be notieable.



If you want to roam authenticated access you'll need IAPP {{verify}}
https://en.wikipedia.org/wiki/Inter-Access_Point_Protocol
-->



A '''range extender''', a.k.a. '''wireless repeater''', is a device which can act as a relay between the real AP and the eventual client.

Upside: 
* more coverage with no extra wiring

Downside:
* uses same channel to receive and send, effectively reducing the speed
: so you wouldn't want support many clients this way
: and is pretty horrible when done on multiple APs


<!--
'''WDS'''

WDS (Wireless Distribution System) refers to poiting one AP to another to act as a sort of slave to it, and communicate with it. 

WDS can often be used as a wireless bridge (without clients) or as a functional equivalent of a wireless repeater.

It allows wireless extending of a network - which is not good for speed, so this is generally only interesting when using wires is too bothersome or too hard.

It is not standard and so not guaranteed to be interoperable.


http://en.wikipedia.org/wiki/Wireless_Distribution_System
-->

===Wireless access point versus wireless router===

tl;dr: people abuse terms, most devices are most things now.


A '''wireless AP''' is ''in principle'' just a bridge, a device which translates between media, specifically a layer-2 device that translates between Ethernet (802.3) and WiFi (802.11). 
A wireless AP need not have an IP or web interface, though many do.


A '''wireless router''' additionally does layer-3 things,
such as filtering, separating networks, providing IPs via DHCP, doing NAT, being a gateway, and such.



'''In practice, 'Access Point' is used to refer to any device that gives you WiFi''',
whether it is a basic bridge or complex router. 

Blurring of the lines is helped by the fact that many Wifi-ey devices can do routery things, and (at least in theory) be configured to be just a bridge.



Access Points's default behaviour is simply the most conventional wish: to connect wireless clients such as laptops to whatever is on the wire stuck into the back of the AP -- typically a LAN with internet access. 

APs regularly also:
* have a distinction between a WAN port ('internet side') and a LAN port ('inside')
** This is useful when it runs a DHCP server for wired clients. Exposing that to the larger network (WAN port) means there are probably now multiple DHCP servers, which ''can'' be a big headache of "sometimes it works" reports.

* add their own DHCP
** This isn't always necessary, since your modem will also run a DHCP server, and usually the only problem you can run into is running out of addresses on the subnet. (which an AP can solve by itself using one address on the modem's subnet, creating a new subnet for its clients, and doing the necessary routing).
** This can be annoying when it is configured to make a new subnet to do so, in that devices on the modem's subnet and the AP's subnet probably won't be able to discover each other. It also means roaming ''may'' not work well.

===Wireless bridge===

The term wireless bridge can refer to '''a few different things'''.


'Bridge' in general networking parlance refers to doing something at layer 2 (link layer), typically to connecting two segments at that layer, which is transparent to layer 3 stuff such as IP (which is the technical meaning of 'wireless AP' mentioned above, but as was implied, that's not a useful term in practice).


This meaning ''can'' also apply to wireless, and it's one way to set up basic roaming in your house: You set up the APs's names and security (to be identical), but disable DHCP and any layer 3 stuff.
Everything thinks it's on the same network because the AP does nothing more than transport packets between wire and air (...for attached clients).

However, it's not typically called bridging in AP configs, because of the following:



Bridge in a wireless context often means connecting two LAN segments together using a wireless link {{comment|(Note: using a wire is typically better for speed and latency, so there is probably a good reason you're ''not'' using a wire)}}.

Instead of the most typical AP behaviour (see previous section), many APs could be made to be ''client'' to ''another'' access point. If they can, then...
* they can choose to act ''only' as a client -- often to allow it to be a "I want a few wired devices to act to an AP further along"
* they can choose to be both client and as an AP -- which makes them a repeater {{comment|(...with the optional added bonus of also serving on the LAN ports)}}


This opens up a few new ways of interconnection.
Some specific cases that are bridges in some way or other:

* The basic case is the description of an AP in the technical sense, that of link-level translation between wire and air.
** This sounds like a trivial case not worth mentioning, but it's useful to consider when when you set up roaming, since you often want only one device to handle all the gateway+DHCP+other such things, and all further APs to act ''purely'' as bridges {{comment|(...with the same name and security details so clients ''know'' how to roam)}}.

* Connecting two otherwise unconnected networks with a wireless connection
** Note that both may be fully functional, and separately internet-connected networks already (if so, it may be useful to filter some things from crossing the bridge)
** can be set up as...
*** one box purely acting as an AP to the other, the other only connecting to that AP, ''or''
** both APs may serve clients at their respective site, and (generally) one AP is a client to the other {{verify}}

* adding a small wired segment, but connecting to internet via WiFi because wires are more bothersome to add than a WiFi connection
** DD-WRT calls this a "'''client bridge'''" [http://www.dd-wrt.com/wiki/index.php/Client_Bridge] (it's ''only'' a client)

* ...a similar setup in which the client box also acts as an AP itself -- effectively extending the range a little.
** DD-WRT calls this a "'''repeater bridge'''" [http://www.dd-wrt.com/wiki/index.php/Repeater_Bridge]
** Note that this is basically a range extender / wireless repeater that happens to also have things connected via cable



<!--
Notes:
* A very configurable AP will mention bridging in more than one context, and you basically have to know what it means (For example, bridging the AP's wifi and Ethernet interface is a distinct thing from the wifi acting in client bridge mode)

* These terms are usually only consistent within a single product. I've seen a lot of easy-to-use AP web interfaces that abuse the terms horribly

-->

===Card modes===
The usual mode is managed, particularly in windows. 

Most cards also ''allow'' ad-hoc, and a various drivers allow monitor (though this is rarer in windows) and some can act as an access point. 
The differences lie almost purely in restrictions in the drivers.

Drivers also do things like require you to set a SSID, then filter out anything not with the SSID, or allow you to look at the packets encapsulated ''by'' wifi and not the wifi packets itself (wifi mostly being a drop-in replacement for Ethernet). {{comment|(This is similar to but not the same as 'promiscuous mode,' a networking term that tends to refer to the IP stack. Your network card usually only hands data it sees to the OS when it is intended for you (by Ethernet address); with promiscuous you get everything passing through.)}}

Cards that have monitor mode will also allow you to look at the wifi packets themselves, and may or may not allow injection of packets.


Anyway, the modes:
* ''Managed'' (client to an AP): knows one or more APs by MAC address (or some nicer name that software/OS superimposes) and uses it / can roam between them
** Note: APs by default send out beacons to let potential clients know about them.

* ''Ad-Hoc'', a.k.a IBBS, peer to peer: Like a set of computers wired only ot each other, an AP-less cell of friends. That's not to say there can't be a gateway on it, mind.

* ''Access point'' (AP): Tends to be a single network gateway for a group of clients, e.g. an internet proxy for your home broadband. 

* ''Monitor'': Does not participate, just receives everything on the a channel/frequency.  This is one way of seeing what APs are around, and it also used for network sniffing.

Repeaters exist, which have:
* ''Repeater'': used to extend the range of a network by retransmission

* ''Secondary'': Backup for repeater{{verify}}







<!--
==WPS=-
Wi-Fi Protected Setup makes for

It's primarily meant for ease - you don't need to type in passphrases that you can make typos in,
and can sometimes help avoid the need for knowledge of networking.

Methods:
* PIN - a number read from a sticker or display needs to be entered. Some form of this is mandatory for WPS compliance.
* Push-button - access point and new device both need to press something, within a certain time window.
* NFC - works by proximity of the device (or sometimes an RFID tag)
* USB - . Deprecated.

-->

<!--
==WDS==
Allows wireless interconnection of APs. 

Implies either 
* wireless repeating (also allows client access, so also acts as a range extender. Seems more typical, probably because it is more useful) 
* wireless bridging (purely a link between APs) 

Preserves client MAC address, which means it can avoid a bunch of local routing 


It's not really recommended to use WDS instead of easy cabling, 
because the on-air repeats decrease the performance.



-->

<!--
==Unsorted and to-read==

'''Linux drivers: '''
* [http://madwifi.org/ madwifi-ng] (atheros devices)
** A, B, and G
<!-- ** Can imitate AP? -->

* [http://prism54.org/ prism54] (prism devices, also those usb-based)
** B and G
** Related: islsm (newmac/softmac)
** Related: hostap

* wlan-ng
** B-only (so max 11MBit)

* Pretty good list of adapters and drivers: http://linux-wless.passys.nl/

* NDISwrapper 
** Allows windows drivers
** ..but only very basic operation (no monitor mode, no promiscuous mode, no WPA out of the box)



'''Antennas'''
* Aliminum foil: [http://www.techtastic.ca/articles/homemade-antenna.html]


'''To read'''

* http://www.wipeer.com/

* http://www.wildpackets.com/support/compendium/manual_appendices/nxA1_AP
* http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html

* http://www.wirelessdefence.org/Contents/Wireless%20Pen%20Test%20Framework.html
-->

<!--
http://forums.remote-exploit.org/showthread.php?t=569

http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Veyssett.pdf

http://docs.lucidinteractive.ca/index.php/Cracking_WEP_and_WPA_Wireless_Networks
-->


<!--
client isolation / AP Isolation: e.g. on wireless routers; blocks routing on the same interface (e.g. wireless-to-wireless) {{verify}}


-->


<!--

"wlanconfig: ioctl: Input/output error": There are various reasons for this, but the top three (for madwifi, at least) seem to be:
* Trying to create a VAP that already exists (check iwconfig, not ifconfig)
* Trying to create two STA-style VAPs (or otherwise incompatible VAPs?)
* Trying to create VAPs in a bad order (ap comes before monitor, it seems)
-->

<!--
Belkin G router:
* Despite all the warnings, the config software is only a simple-and-stupid solution, that does not cover a
* If it stops responding every few minutes, this is often due to the protection mode being enabled (or on auto). In the best case this feature is useful, but there are some environments to which it respons very badly, and in which it should be disabled.
-->


===Traffic indication map===

{{stub}}

(Delivery) Traffic Indication Map/Message is a way of letting specific sleeping WiFi clients know there is data for them,
so that they do not have to use power transmitting until they know that's useful.


Implementation-wise, this is typically added to some or all AP beacons, which APs send regularly anyway.

...and specifically a bitmask of already-associated stations that those stations will know refers to them.
(only part of that bitmap will typically be sent, because there is usually only data for a small set of stations)


Some APs will have a setting like the DTIM period - a setting that lets you send this TIM (Traffic Indicaton Map) only every nth beacon.

This lets an AP delay waking up the station. 
This is client power saving configurable on the AP side, so only really useful in systems where you control all of that, less so in general purpose wifi,
and where the increased latency is acceptable.


https://en.wikipedia.org/wiki/Traffic_indication_map#Delivery_traffic_indication_message

==Captive portals==
{{stub}}

A '''captive portal''' refers to cases where connections to a WiFi AP will only present a specific page, instead of the real webpage you asked for.


...so that before clients are granted internet access, the network can can 
: ask you to authenticate,
: accept a Terms of Service, 
: ask for payment (whether for greedy reasons or just to avoid clogging a very shared network like at the airport - there's only so much aether), 


The way this works is intercepting HTTP, which in these HTTPS-preferring days requires more cooperating from devices.
: (this will likely change to different, more secure methods over time)


Most mobile devices will check for captive portals by, after connecting to an AP, attempting to fetch a known HTTP URL,
and seeing whether they get back what they expect.

Depending on what it gets back, it can e.g. decide
* if it gets back a HTTP response as it expected: you have internet access, fine 
* if it gets back an unexpected HTTP response: assume there is a captive portal
* if it doesn't get a response at all: you have no internet access



Mobile
* android would do a plaintext HTTP request to something like http://connectivitycheck.gstatic.com/generate_204 (apparently a lot of different hosts were used over time[https://enterprisenetworkingatlarge.wordpress.com/2018/04/21/captive-portal-detection-on-android-and-others-client-vendors-vs-ap-vendors/]) 
: Getting a HTTP response, with any status other than a 204 (No Content), is considered a captive portal
: (it seems android also uses captive.apple.com - as a double check or just unified?{{verify}})

* Apple uses
: http://captive.apple.com/hotspot-detect.html 
: http://www.apple.com/library/test/success.html


OSes started doing very similar checks later. 
* e.g. www.msftncsi.com  [https://docs.microsoft.com/en-us/previous-versions/windows/desktop/mpc/network-awareness-on-windows-vista-and-windows-7]

Browsers may as well, particularly those on mobile devices.
* Firefox's seems to be http://detectportal.firefox.com/success.txt


...apparently ''many'' specific URLs were used over time.



...and apparently others[https://success.tanaza.com/s/article/How-Automatic-Detection-of-Captive-Portal-works]




Captive portals are implemented by one (or more) of:
* respond to all DNS requests with their own web server
: 

* intercept all HTTP requests (while leaving DNS alone)

* in newer implementations, be communicated via DHCP (see RFC 7710)
: what is done with the rest of traffic may vary
: this hasn't replaced the previous methods yet


Yes, the first two are basically Man-in-the-Middle attacks, but used for good rather than evil.

<!--
Why do captive portals work at all when you also have mobile data?

-->



In the first two cases, sending a redirect to a logon page
: or that page itself



Notes: 
* It seems that e.g. phones may decide a captive portal is done if it links/redirects to a different domain. {{verify}}
: (would be an extra reason a HTTPS captive portal is hard?)

* The first two methods make HTTP an issue, because whether HTTPS is blocked or intercepted, it's likely to lead to timeouts and/or security warnings

How do devices detect the captive portal part is done?



https://captivebehavior.wballiance.com/

---

I've used captive portals for some DIY, whre you may want a phone to just go to your DIY device ''instead'' of using WiFi for internet access,
this is rather simpler to implement than a portal that ''does'' switch to providing internet access (If it can do a soft AP and a DNS server answering the same IP to every request, that's basically enough).


===Are captive portals risky?===
<!--
tl;dr:

* The captive portal only refers to that initial 'please do something' page

* treat captive portals webpages as untrusted, always. Don't give out any information. 

* once you have internet access, it's down to how much you trust that network in general

* neither portal or network can break the HTTPS accesses that now consitute most webpage accesses



Captive Portals are Man in the Middle used for good.

But what's close to 'not good'. So what's the worst they can do?


'''Privacy and security'''

If all that is being asked for you is "agree to this ToS" (for the owner to reduce their liability of what you do), there is nothing you're giving away.

If you need to log in, you run into the issue that someone ''could'' plant a AP impersonating real APs.


Classic captive portals specifically use HTTP, not HTTPS, so you do ''not'' get verification of identity of who runs that portal.
...mostly because of a catch-22: you typically need internet access to verify certificates. 
You can install certificates on a device, but this is specific to one portal, so this is something you ''might'' consider for work but nothing else (and your work probably uses EAP)practically this is only something you would e.g. do for work.
You can get that via an app, but in this context you are right to distrust such apps.


The captive portal itself may be able to identify returning users (without necessarily knowing who you are) 
with things like browser fingerprinting. If you consider this bad, just never use captive portals.



'''Snooping'''

Anyone can snoop traffic on a network they own, due the fact that it's their network, unrelated to the captive portal part.

Captive portals or their network cannot break HTTPS, 
and since basically all webpage accesses are HTTPS these days, snooping risks are low.


There is traffic beyond web pages, mostly supporting protocols, that can still be snooped on.
VPN helps alleviate ''that'' snooping, but requires internet access so only applies ''after'' you fully interacted with the portal.

And unless you configured your device to do all traffic via VPN, there may be a window (of maybe a minute or two) where your device leaks information (and might even be exploitable, though this risk should be low).



-->

==See also==

<!--
* [[madwifi notes]]
-->