Electronics notes/802.11 (WiFi)

From Helpful
Jump to navigation Jump to search

⚠ This is for beginners and very much by a beginner / hobbyist

It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book.

Some basics and reference: Volts, amps, energy, power · batteries · resistors · transistors · fuses · diodes · capacitors · inductors and transformers · ground

Slightly less basic: amplifier notes · varistors · changing voltage · baluns · frequency generation · Transmission lines · skin effect

And some more applied stuff:

IO: Input and output pins · wired local IO · wired local-ish IO · ·  Various wireless · 802.11 (WiFi) · cell phone

Sensors: General sensor notes, voltage and current sensing · Knobs and dials · Pressure sensing · Temperature sensing · humidity sensing · Light sensing · Movement sensing · Capacitive sensing · Touch screen notes

Actuators: General actuator notes, circuit protection · Motors and servos · Solenoids

Noise stuff: Stray signals and noise · sound-related noise names · electronic non-coupled noise names · electronic coupled noise · ground loop · strategies to avoid coupled noise · Sampling, reproduction, and transmission distortions

Audio and video notes: See avnotes

Platform specific

Arduino and AVR notes · (Ethernet)
Microcontroller and computer platforms ··· ESP series notes · STM32 series notes

Less sorted: Ground · device voltage and impedance (+ audio-specific) · electricity and humans · Common terms, useful basics, soldering · landline phones · pulse modulation · signal reflection · Project boxes · resource metering · SDR · PLL · vacuum tubes · Multimeter notes Unsorted stuff

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer ·

See also Category:Electronics.

⌛ This hasn't been updated for a while, so could be outdated (particularly if it's about something that evolves constantly, such as software or research).
📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense.

On speed, range, and interference


🛈 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.

Advertised throughputs are stupid

The figure on the box is for lab conditions, and a complete lack of neighbors, or even walls, and sometimes the collective possible speed between clients that is never given to a single client (cannot even be).

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.
(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.

(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 lower overall throughput

There's mixed-speed networks (like b + g + n, because they're all in the same 2.4GHz band, though b is rare now and g also uncommon).
That implies that when b or g devices appear, the communication goes at different speeds at different times.
This is usually barely noticeable, because the few b or g devices that are left / made these days tend to not do data-intense things
(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).

The broader distance-and-wall-and-neighbour reasons, and the will of marketers to use the maximum possible number, means that you can practically expect real throughput to max out at half the advertised speed.

...arguably up to 11n, and 11ac made things became somewhat better.

But at the same time, how much better started became even more of an 'it depends'.

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.

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.

(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 (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 with aggressive looking angles and 1024-QAM and 4x4 (or even 8x8) MIMO are, in a word, stupid.

Even if the AP can technically do this, it doesn't matter when most clients do at most 64-QAM and 2×2 MIMO, so will always go multiples lower.


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


  • 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.

(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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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 (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
(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.

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 (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 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


This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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[1] 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:

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 (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:

  • legacy IEEE 802.11, at 2.4GHz, marketed as 2MBit/s (discontinued)
  • IEEE 802.11a (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.11b
    • 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.11g
    • 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 (11a and 11b are alternatives; a is shorter-range, higher-speed, and was targeted at business use)
  • IEEE 802.11n ("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 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 >54 Mbps when using WPA2/AES (or no encryption(verify)), not when using WEP or using TKIP. Can be relevant.
  • IEEE 802.11ac ("WiFi 5")
    • 5GHz only, but 11ac APs and clients are likely to support and fall back to 11n in the 2.4GHz band (verify)
    • 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.11ax ("WiFi 6")
    • 2.4 and 5 GHz (and a later 6E at 6GHz)
  • IEEE 802.11be ("WiFi 7")
    • 2.4, 5, and 6 GHz
    • Currently in development

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.


d - country roaming extensions
e - QoS, packet bursting
i - WPA2 (roughly. the WPA names were historically confusing)
k - attempts better traffic distribution
r - fast roaming

...and some of which specific-purpose, like:

p - vehicles
s - (fixed) mesh networking
af, ah - in TV bands, non-licensed bands (slowish, but useful for specific purposes, like wireless mics, maybe IoT)
ad, ay (WiGig) (note: at much higher frequencies than the similar-speed ax. Expect wigig to only work within a room)

See also:

On signal strength, noise, quality and such

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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 (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 (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 (about 4*10-13 Watt) and a RSSI of -65dBm (about 3*10-10 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).


  • ~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.


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.

See also lists like:

WiFi frame notes


Encryption (and authentication)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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 (Wired Equivalent Privacy) (had viable attacks for ages, has been considered deprecated for ages)
  • WPA and WPA2 (Wi-Fi Protected Access), 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 802.11
  • 802.1X - encapsulates EAP [2]
  • 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, [3], 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
      (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. [4]. It seems it will protect against wardrivers with cheap (non-LEAP) cards.
  • 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) [5]
  • 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) [6] (verify)

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:

TODO: read:

WPS, WCN, and such

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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.

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:


App lists:




  • inSSIDer [7]
  • Xirrus Wi-Fi inspector [8]
  • Netstumbler [9] (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?


  • Kismet
  • aircrack
  • airsnort


  • winairsnort

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



  • Aircrack, the name of a package that has a dumper (airodump) and cracker(aircrack)
  • Aircrack-ng [10] (WEP cryptanalyitically, TKIP-PSK WPA dictionary)
  • Airsnort [11] (brute force?)
  • weplab (brute force but also analytic?(verify))
  • coWPAtty (TKIP-PSK WPA, brute force, see e.g. [12])


  • Aircrack-ng [13]
  • Aircrack [14]
  • Airsnort [15] (brute force?)
  • weplab (brute force, so slow)



  • Void11
  • wlan_jack
  • essid_jack

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


  • FakeAP throws around a lot of AP beacons, which should confuse sniffing a little - but also freely roaming clients.

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

Probes and privacy

Levels of revealing information

While not connected

Clients on the same AP

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

Can you see where phones are?

Can they know who you are?

Trading privacy for features


MAC randomisation


For context: connection behaviour

Karma attack

Beacon spamming / beacon swarm

Evil twin attack

Listening to authentication

Deassociation attack

More concepts and notes

Roaming, range extenders, repeaters

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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.


  • more coverage with no extra wiring


  • 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

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 (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 (...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 (...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" [16] (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" [17]
    • Note that this is basically a range extender / wireless repeater that happens to also have things connected via cable

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). (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)

  • prism54 (prism devices, also those usb-based)
    • B and G
    • Related: islsm (newmac/softmac)
    • Related: hostap
  • wlan-ng
    • B-only (so max 11MBit)
  • NDISwrapper
    • Allows windows drivers
    • ..but only very basic operation (no monitor mode, no promiscuous mode, no WPA out of the box)


To read


Traffic indication map

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

(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.


Captive portals

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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


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

OSes started doing very similar checks later.

  • e.g. www.msftncsi.com [20]

Browsers may as well, particularly those on mobile devices.

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

...and apparently others[21]

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.

In the first two cases, sending a redirect to a logon page

or that page itself


  • 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?



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?

See also