association request – knock knock, can i join?

so when you slap wlan.fc.type_subtype == 0 into wireshark, you’re zooming in on one very polite moment in wi-fi life: the association request. it’s basically a device goin’ “hey ap, mind if i join the network?” – real humble, not pushy.

how it fits in

this frame shows up after the device found the right access point, maybe sniffed a beacon or two, and now it wants to make it official. it sends over supported data rates, capabilities, and other nerdy stuff like that.

why it matters?

no association request? no network party. no IP. no ping. no memes. it’s the handshake before the handshake. filter with wlan.fc.type_subtype == 0 and you catch devices just before they get the golden ticket.

 

association response – yeah ok, you're in

when you roll with wlan.fc.type_subtype == 1 in wireshark, you're catching the ap saying “cool, you can join” – or sometimes “nope, not today.” it's the follow-up to that association request where a device asked to join the network.

what's inside?

this frame’s got all the juicy stuff: status code (so you know if it’s a yes or a nope), assigned aid (association ID), and the ap’s view of what the device can handle – like data rates, HT/VHT/HE things, etc.

why bother?

no association response = no deal. the device stays outside, dreaming of packets. this frame is key to the handshake that gets you fully into the 802.11 party. use the filter and watch your devices get accepted or ghosted.

 

reassociation request – i moved, lemme back in

so yeah, wlan.fc.type_subtype == 2 is your filter for reassociation request frames. it’s like when a device was chillin’ on one ap, then wanders off and finds a new ap – and it’s like “hey, can i reconnect real quick? here’s my old ap btw.”

why use it?

you catch these frames when a client’s roaming but doesn’t wanna start fresh. it wants to keep that session vibe going. this is part of fast transition moves (like FT-over-DS or FT-over-air if you're getting fancy).

what's in the frame?

similar to a regular association request but with an extra field for the current ap info. it tells the new ap who the client was hanging with before. then the ap can be like “aight, welcome back” – or not.

 

reassociation response – welcome back, wanderer

when you filter with wlan.fc.type_subtype == 3 in wireshark, you're catching the ap’s answer to a reassociation request. basically, the device was like “yo, i switched aps, let me in again” and this is the ap going “cool, come on in” – or “nope, go away.”

what it’s packin’

just like the regular association response, you get a status code, an aid (association ID), and some info about what the ap supports. it’s the network giving the thumbs up – or down – to a reconnecting device.

why it matters?

without this response, the reassociation request is just screaming into the void. this frame seals the deal on a roam. sniff it with the filter and see who's switching lanes in your wlan.

 

probe request – who's out there?

hit up wlan.fc.type_subtype == 4 in wireshark and you're grabbing probe requests – the wi-fi version of “yo, any networks around?” devices toss these out when they’re hunting for aps to connect to. it’s the client yelling into the ether: “i’m lookin’, anyone home?”

why do clients do this?

probe requests help devices find networks faster than just sitting around waiting. they can be broadcast (like “anyone at all?”) or directed (like “yo netgear_guest, you here?”). it’s part of active scanning.

what’s in the packet?

these frames pack the ssid they’re looking for, supported rates, maybe HT/VHT/HE capabilities – the client’s basically saying “here’s what i can do, gimme a network that fits.” filter it and watch your phone talk to ghosts.

 

probe response – yeah, i’m here

when a device throws out a probe request, the ap can reply with a probe response, which you’ll catch using wlan.fc.type_subtype == 5 in wireshark. it’s the ap going “yo, yeah, i’m online – here’s what i got.”

what’s inside?

this frame tells the client about the ap’s ssid, supported data rates, channels, security settings (like wpa2, wpa3), and a bunch of capabilities. it's basically the ap’s little resume.

when does this happen?

usually right after a probe request. it’s part of the active scan dance. the client asks, the ap replies. no commitment yet – just flirting. you’ll see tons of these when stuff’s waking up or moving around.

 

beacon – the ap never shuts up

use wlan.fc.type_subtype == 8 in wireshark and you're catching beacon frames. these things are like little heartbeat signals that an ap blasts out constantly, saying “hey! i’m a network, come connect to me.”

what’s inside?

ssid, supported rates, timestamp, security info, channel – basically everything a client needs to know before trying to join. it’s the ap’s billboard. the beacon tells everyone what kind of network it is and what it offers.

how often?

usually every 100 milliseconds. they just keep comin’. even if no one’s connected, the ap keeps beaconing – kinda like a lighthouse that doesn’t care who’s watching.

why care?

they’re your go-to for seeing which networks are around and what capabilities they claim to have. also super helpful for tracking roaming behavior, hidden ssids, or just spying on who's chattin' in the air.

 

disassociation – breakin' up is protocol

throw wlan.fc.type_subtype == 10 into wireshark and you’re looking at disassociation frames. this is how a client or ap says “yo, we done here” in wi-fi land. it’s not rage-quitting – it’s more like a formal handshake saying “i'm out.”

who sends it?

either side can send it – ap to kick a client (maybe for timeout, roaming, or just bad vibes), or client to say “peace out” when it’s done. this clears the session and lets resources get freed.

what’s in the frame?

not much – just the reason code and who’s saying bye. think of it like a sticky note left behind after moving out: “it was fun, but i gotta go.”

why does it matter?

watching these can help you debug weird drops, handoffs, or see if a device is getting booted. also useful when you’re testing roaming or client stability – 'cause every goodbye tells a story.

 

authentication – knock knock, lemme in

use wlan.fc.type_subtype == 11 to catch authentication frames in wireshark. these are like the first polite “hello” a client throws at an access point when it wants to join the party. no auth, no entry.

what’s it do?

this frame kicks off the handshake. back in the old days, with open or shared key auth, this was the real deal. nowadays, it’s mostly a formality – part of the dance before association.

who sends it?

the client hits the ap with this frame saying, “hey, i wanna talk.” the ap either says “cool, let’s go” or “nah, not today.” if it’s all good, they move on to association.

why sniff it?

auth frames help you spot connection attempts. if you see a bunch of these but no association, something’s off – maybe bad creds, misconfig, or just an unfriendly ap. definitely worth watching when debugging joins.

 

deauthentication – the not-so-gentle goodbye

filter with wlan.fc.type_subtype == 12 and you’ll catch deauth frames – the wi-fi version of “get lost.” this is when a client or ap shuts it down hard, no handshake, just boom – connection’s dead.

what it means

unlike disassociation (which is more like “we’re done for now”), deauth is the full breakup. it kicks a device outta the bss, usually because something broke – like bad auth, timeout, or just rules being rules.

who throws it?

ap says it when a client’s being weird or not following protocol. client might send it too when it’s jumping networks. oh – and hackers use it to mess things up. yeah, deauth floods are a thing.

why watch it?

if your client keeps dropping, check for deauths. could be config issues, bad keys, or some joker running attacks. these frames are loud, so wireshark catches them easy – and they tell a whole story in just a few bytes.

 

action – the special ops of wi-fi

grab wlan.fc.type_subtype == 13 to peek at action frames. these aren’t your basic “hi” or “bye” type packets – they’re more like “yo, here’s some specific thing i need you to do now.”

what kinda action?

could be anything from triggering measurements, negotiating channel switches, power-saving stuff, or handling spectrum management. think of 'em like little commands flying through the air between wi-fi brains.

who sends these?

both ap and client throw these around when they wanna tweak something. maybe it's 802.11k telling you where better aps are, or 802.11v nudging your client to roam. all kinds of behind-the-scenes magic.

why sniff them?

action frames tell you what the devices are up to beyond basic connect/disconnect. if your gear’s doing clever stuff like roaming advice, channel hopping, or beamforming — this is where the evidence lives.

---

control frames – keepin’ the wifi convo clean

use wlan.fc.type == 1 in wireshark to catch the control frames. these don’t carry user data, they’re like the traffic cops of wifi – makin’ sure everything flows nice 'n smooth.

what do they do?

stuff like “clear to send” (CTS), “request to send” (RTS), “ack” (yo i got your packet), and some powersave dance moves. they’re the behind-the-scenes crew, not flashy, but super important.

when do you see ‘em?

all the time, but especially when things are busy – like crowded networks or when aps tryin’ to play nice. if you're digging deep into timing or interference issues, these are gold.

 

block ack request – askin’ if you got all my junk

with wlan.fc.type_subtype == 24 you're catchin' the block ack request frames. instead of ackin’ every lil packet one-by-one, this guy’s like “yo, did you get the whole bunch?”

why bother?

saves airtime. faster. cleaner. your device just chucks a pile of frames and later asks for one big confirmation. kinda like sendin’ 10 texts and sayin “you get all that?” instead of waitin’ for 10 replies.

who uses it?

mostly when your wifi’s gettin’ real efficient, like with 802.11n/ac/ax gear throwin’ those A-MPDUs around. you'll see this in action when the gear’s tryin’ to be smart.

 

block ack – yeah bro, i got your stuff

use wlan.fc.type_subtype == 25 to sniff out block ack frames. it’s the follow-up to the block ack request – the device replies like “yup, got frame 1, 2, 4... but 3? nah, send that again.”

what’s the deal?

instead of ackin' each frame one by one (like in the old days), it just sends back a bitmap showin’ which ones landed safe. quick n’ tidy.

when’s it show up?

you’ll see it in high-throughput action – 802.11n, ac, ax. if there's A-MPDU goin' down, expect block acks to pop up right after. makes the wifi talk smoother.

 

ps-poll – yo AP, wake up, gimme my stash

when you filter with wlan.fc.type_subtype == 26 you’re lookin’ at ps-poll frames. these come from a sleepy STA sayin’ “yo AP, you got any saved frames for me?”

power save mode things

this frame pops when a client’s been nappin’ in power save mode and needs the AP to hand over the buffered stuff. it’s like knockin’ on the fridge at 2am askin’ for snacks.

oldschool, but still there

not as hot anymore with newer power save tricks like U-APSD or TWT rollin’ in, but you’ll still spot this lil guy on legacy gear tryin’ to save juice.

 

rts – lemme talk first

filter with wlan.fc.type_subtype == 27 and you’re seein' rts (ready to send) frames. it’s like a device shoutin’ “yo, anybody out there? i got stuff to send – gimme the floor!”

clearing the air

rts is all about avoidin’ collisions. it asks permission before blastin’ a big frame. useful when the air’s crowded or when hidden node problems mess things up.

how it flows

rts goes out → if the AP’s cool with it, it replies with a cts (clear to send). then the sender drops the payload. neat lil handshake, like wifi manners.

 

cts – aight, go ahead

when you filter with wlan.fc.type_subtype == 28 you’re catchin’ cts (clear to send) frames. these are sent after an rts – kinda like sayin’ “all clear, let it rip.”

keepin’ the air tidy

cts helps make sure no one else jumps in while the sender’s talkin’. stops the radio chaos – especially when hidden nodes might be lurkin’.

rts + cts = wifi handshake

this is the second part of the classic rts/cts deal. first one asks, this one approves. after that, it’s send-time. no collisions, no drama.

 

ack – got it, buddy

filter with wlan.fc.type_subtype == 29 and you’ll see ack (acknowledgment) frames. simple stuff – it’s like sayin’ “yep, i got your frame loud and clear.”

don’t skip the handshake

wifi’s picky – every unicast frame wants a response. if you don’t hear back with an ack, you resend. this little dude keeps the convo goin’ smooth.

fast, tiny, important

ack frames are short and sweet, but the whole show falls apart without 'em. no ack = no trust = retransmissions = bad wifi day.

---

 

data frames – the meat of wifi

with wlan.fc.type == 2 you’re lookin’ at data frames. this is where the action happens – real stuff gettin' sent from one device to another, like files, streams, memes, all that juicy payload.

 

plain ol’ data – just doin’ its job

filterin’ with wlan.fc.type_subtype == 32 gets you the basic data frame. nothin’ fancy, just regular wifi biz – sendin’ bits from point a to b without all the qos or extra drama.

 

null data – not really bringin’ the goods

when you hit wlan.fc.type_subtype == 36, you’re catchin’ a null data frame. it ain’t carryin’ no payload, just kinda showin’ up like “yo, i’m here but not sayin’ much” – used for stuff like power save signaling.

 

qos data – vip packets on the move

filter wlan.fc.type_subtype == 40 and you're watchin' qos data frames. they’re the high-priority types, zoomin' through the air with that quality of service touch – like vip lanes for voice, video or whatever needs to be fast.

 

qos null – no payload but still flexin’

when you go wlan.fc.type_subtype == 44, you catchin’ a qos null frame. it don’t carry data, but it’s got that qos tag – mostly just lettin’ the ap know “yo, i’m awake” or playin’ power save games.

---

 

filterin’ like a boss – display filter ops

wireshark got its own way of talkin’ when diggin’ thru them 802.11 packets – here’s a chill little cheat table for your filter vibes:

Operator	Also known as	What it do	Example
==	eq	equal	wlan.fc.type == 0
!=	ne	not equal	wlan.fc.type != 1
&&	and	both true	wlan.fc.type == 0 && wlan.fc.subtype == 4
||	or	either true	wlan.fc.type == 0 || wlan.fc.type == 1
^^	xor	one true only	wlan.fc.type == 0 ^^ wlan.fc.type == 1
!	not	negation	!wlan.fc.retry
contains	—	field includes value	wlan.addr contains "aa:bb"

 

---

 

address jungle – who sendin’ what where

so when you pokin' into 802.11 frames in wireshark, there’s a bunch of addresses floatin’ around. not just one MAC – nah, we got roles. here’s the crew:

• wlan.addr – any MAC in the frame, sender or receiver. kinda the catch-all.
• wlan.ta – transmitter address. that’s the one physically sendin' the bits over the air.
• wlan.ra – receiver address. who’s catchin’ the frame on the other side.
• wlan.sa – source address. where the data really comes from (could be different from transmitter).
• wlan.da – destination address. where the data’s supposed to go (not always the receiver).

use == to match one, like wlan.sa == aa:bb:cc:dd:ee:ff if you wanna sniff what that source been sendin’. wild stuff.

 

access points & ssids – who’s hostin’ the party

alright, when you're tryna figure out who’s runnin' the show in wifi land, checkin’ the ap and its ssid is key. here’s what you peek at:

• wlan.bssid – this the bssid, aka the MAC address of the access point’s radio. tells you what ap’s throwin’ the packets out.
• wlan_mgt.ssid – this one’s the ssid, the name of the wifi network. like the sign on the club door.

wanna see frames from a specific ap? use somethin’ like wlan.bssid == 11:22:33:44:55:66. want that one network name? go wlan_mgt.ssid == "MyWiFi". now you know who’s hostin’ and what it’s called.

radio tap vibes – what the air sayin’

before the 802.11 frame even kicks in, we got the radiotap header spillin’ the tea. that’s the extra radio-layer info wireshark loves. here’s the stuff you can poke at:

• radiotap.channel.freq – wanna see frames from a certain channel? this gets you the frequency, like radiotap.channel.freq == 2412 for channel 1.
• radiotap.datarate – shows the data rate used when the packet got sent. you can filter like radiotap.datarate == 24 for 24 Mbps action.
• radiotap.dbm_antsignal – that’s the signal strength, in dBm. more negative = worse. like radiotap.dbm_antsignal >= -60 to get stronger frames only.

so yeah, this header’s just givin’ you the air scoop – what channel, how fast, and how loud it came in.

roamin’ the fast lane – 802.11k, v, r style

yo, when wifi gets real smart, it starts doin’ this 802.11k/v/r business. it’s all about makin’ your device hop between access points like a pro, with no laggy vibes. here’s what wireshark lets you sniff:

• 802.11v DMS request – check for em with wlan.fixed.action_code == 23. that’s a station sayin’ “hey, gimme them managed service vibes”.
• 802.11v DMS response – APs hit back with wlan.fixed.action_code == 24. like “cool, you’re in”.
• 802.11k Neighbor request – wlan.rm.action_code == 4 means the STA wants a list of better APs around.
• 802.11k Neighbor response – wlan.rm.action_code == 5 brings back that juicy neighbor list for faster roaming.
• 802.11r FT auth request – fast transition (FT) kickin’ off with (wlan.fc.type_subtype==0) && (wlan.rsn.akms.type == 3).
• 802.11r FT auth response – (wlan.fc.type_subtype==1) && (wlan.tag.number == 55) means the AP gave the go.
• 802.11r FT reassoc request – (wlan.fc.type_subtype==2) && (wlan.tag.number == 55) is the STA sayin’ “i’m movin’ over”.
• 802.11r FT reassoc response – (wlan.fc.type_subtype==3) && (wlan.tag.number == 55) is the AP like “cool, all set”.

so yeah, these filters show when your gear’s tryin’ to do fast & fancy handshakes to keep that roam game tight.

retries – when wifi gotta try again

sometimes a frame don’t make it, so the sender’s like “yo, lemme try that one more time”. that’s where retries come in.

• wlan.fc.retry == 1 – this means the frame is a repeat. it didn’t get acknowledged the first time, so it’s comin’ back around for another shot.

good for seein’ who’s strugglin’ to get through the noise or bad signal zones. if you see too many retries, somethin’ might be janky.

weak signal & probe hustle

when devices out there whisperin’ in the wifi wind, tryin’ to find an ap or shoutin’ real quiet – that’s weak signal stuff. and it shows up clear in wireshark if you peek right.

• wlan_radio.signal_dbm < -dB – shows any frame with a signal strength weaker than whatever dB you set. like < -80 for ghost-level wifi.
• wlan.fc.type_subtype == 5 && wlan_radio.signal_dbm < -dB – finds probe responses from APs that barely makin’ it through.
• wlan.fc.type_subtype == 4 && wlan_radio.signal_dbm < -dB – catches probe requests from clients yellin’ out soft, barely heard.

handy when you lookin’ for coverage holes or just devices strugglin’ on the fringe.

4-way handshake catchin’ – sneaky mode

aight so when a wifi device tryin’ to connect to a protected network (like WPA2/WPA3), it goes through this secret lil back-and-forth called the 4-way handshake. this dance happens right after authentication, just before full connection. it’s all about swappin’ keys, settin’ up encryption, keepin’ that data safe.

you can filter those handshakes real easy with:

wlan.addr == xx:xx:xx:xx:xx:xx && eapol

that eapol part grabs the handshake frames (they use EAP over LAN protocol). wlan.addr filters it down to the device you care about (use MAC from probe/beacon/assoc).

why’s it hot for black hats?

if you’re walkin’ the dark side (we not judgin’, just sayin’), this is gold. grabbin’ that 4-way handshake lets you:

• capture creds – not the real password, but the handshake can be cracked offline later with dictionary or brute-force attacks.
• audit your own network – yeah, sure… “for testing”.
• watch handshake failures – might help identify rogue APs or jamming tools playin’ dirty.

basically, if you got the handshake and the SSID, and it’s weak passphrase land, you’re already halfway in. use tools like hashcat or aircrack-ng to throw passwords at the hash till it breaks.

but yo – don’t do shady stuff on networks that ain’t yours. this for learnin’ and lab fun, not messin’ with the neighbors.

---

If you got the feeling now like “Yeah, I totally get Wi-Fi!” – then uh... nope. That was just OFDM Stuff, my friend. There’s a whole bookshelf waitin’ for you if you wanna be a real Wi-Fi geek. CWNA, CWAP, CWDP, CWSP, CWISA, Wireshark Network Analysis... yeah, it’s a ride. Buckle up.

Just a quick FYI:
This article’s got no fancy graphics – on purpose. It’s built that way so screen readers and text-to-speech tools don’t freak out. Keepin’ it clean for the accessibility crew.

Heads up, Wi-Fi nerds:
This whole guide was put together using the Book from Laura Chappell - Wireshark Network Analysis. All the deep-dive stuff about Wireshark, 802.11 weirdness, and packet wrangling comes straight outta those.