Ghost Frame Killah

Recommending the exact opposite of what every enterprise Wi-Fi infrastructure vendor recommends can be awkward.  As awkward as the first meeting between Hank Kingsley (Jeffrey Tambor) and the Wu-Tang Clan?  (WARNING: extremely NSFW)

Maybe not that awkward.  

But while Hank had trouble relating to Wu-Tang member Ghostface Killah, Wi-Fi folks can avoid trouble by being aware of an increasingly common problem, the Ghost Frame Killah.

Ghosts, as we all are well aware, are apparitions that can have a detrimental effect on buildings built on Indian burial grounds, while remaining unseen to our earthly eyes.  If you have Ghosts, you may need to call a Ghost Bouncer to solve the problem.

Ghost Frames, on the other hand, are Wi-Fi frames ("packets") that can have a detrimental effect on Wi-Fi networks, while remaining unseen to our earthly Wi-Fi sniffing tools.  The solution to Ghost Frames is a simple one, but one that requires Wi-Fi folks to do the exact opposite of what enterprise Wi-Fi infrastructure vendors recommend.  For that reason, I want to give an explanation before I give an answer.

To begin, keep in mind what makes a Wi-Fi frame a Ghost Frame.  It must:
  1. Use Wi-Fi channel time (some call it "airtime").
  2. Be un-capturable.
At first glance, those two conditions appear to be a Catch-22.  If a Wi-Fi frame is using airtime, then it must be capturable.  If a Wi-Fi sniffing tool cannot capture the frame, then the frame must not be using Wi-Fi channel time.  Those are the rules.  (At least, if we assume that Wi-Fi capture radios and connected Wi-Fi device radios are identical, which is a separate discussion.)

The caveat to those rules lies in the physical layer convergence protocol (PLCP) header.  The PLCP header is a part of the 802.11 standard that facilitates dynamic rate switching (DRS).  In Wi-Fi, APs and devices need to be able to use high speeds when channel conditions are good and low speeds when channel conditions are not-so-good.  The problem is that the receiver of the frame needs to know which speed is being used.  That problem is solved by having the transmitter of the frame indicate which speed will be used in the PLCP header, which is the first part of a Wi-Fi frame transmission.

All 802.11n and 802.11ac frames (not to mention 802.11a/g frames) use a 6 Mbps PLCP header.  By using the same speed for every header, receivers -- whether they are APs or stations -- know which type of modulation and coding to set their radios to initially.  Once the PLCP header is received, Wi-Fi APs and stations can then switch to the "real" speed of the frame.  It looks something like this:

Since the PLCP header is always sent at the 6 Mbps data rate, that means it can be "heard" from very very far away.  Low rates "travel" farther than high rates, after all.  In fact, the PLCP header will often (usually; almost always) "travel" farther than the rest of the frame because the rest of the frame will often (usually; almost always) be using a higher rate.

Let's use the example of a Beacon frame to illustrate what's happening:

The meat of the 802.11 Beacon (the 802.11 header and frame body) can only be "heard" out to the 12 Mbps boundary, but the PLCP header can be "heard" out as far as the 6 Mbps boundary.

What this means is that there is an area where the PLCP is being "heard", but the rest of the frame is not.  That is very important for surveying/utilization measuring/sniffing because those activities rely on frame capture and frame capture means a capture of the 802.11 header & frame body, but NOT the PLCP header.

Bottom line: that Beacon is not being captured, but it's PLCP header is still there.

Here's why it matters that the PLCP header is being captured beyond the area where the 802.11 header & frame body can be captured: the PLCP header can take up airtime even if the rest of the frame can't be "heard".

It's because of the LENGTH field of the PLCP header:

That LENGTH field indicates how much airtime will be used by the 802.11 header & frame body.  So, Wi-Fi devices and APs that sit in between the 12 Mbps and 6 Mbps boundaries will "hear" the PLCP, see the LENGTH field and stay quiet for the time it takes the 802.11 header & frame body to go through the air.  That's lost airtime.  Moreover, it's un-capturable lost airtime.  The 12 Mbps Beacon cannot be captured beyond the 12 Mbps boundary.

So, that's what I mean by a Ghost Frame: a frame that is eating up your airtime because its 6 Mbps PLCP header can be "heard", but cannot be captured because the 802.11 header & frame body are using a rate that is "too high".

Ghost Frames are always going to exist, and that's fine.  We want devices and APs to use high rates for their 802.11 header & frame bodies when transmitting data.  High rates for data make Wi-Fi channels more efficient.

Where Ghost Frames turn into Ghost Frame Killahs is when 802.11 Beacon frames use high rates.  Beacon frames allow Wi-Fi folks to get an idea of an AP's "range" when designing or troubleshooting a Wi-Fi deployment, which is essential for re-using Wi-Fi channels.  If the 6 Mbps data rate -- or, God forbid, higher rates like 9 Mbps, 12 Mbps or even 18 Mbps -- is/are disabled, channel re-use plans (and, really, the whole dang survey/design) become worthless.  In fact, they become worse than worthless because they become deceptive.  They become counter-productive.

Enterprise Wi-Fi infrastructure vendors may recommend the opposite, but if you want to Protect Ya Neck, enable all OFDM data rates and set 6 Mbps (along with 12 and 24 Mbps) as Mandatory.  Your Wi-Fi network will have Beacons with PLCP rates and 802.11 header & frame body rates that match, with will be a Triumph for Wi-Fi stability.


If you like my blog, you can support it by shopping through my Amazon link.  You can also donate Bitcoin to 176AkT37uV78WUZHsB42faQuyjbWF5pzXU

Twitter: @Ben_SniffWiFi

ben at sniffwifi dot com


  1. In typical office deployments, wouldn't this be far more of an issue in 2.4 GHz than in 5 GHz, which was your example though not stated? It seems to me that, if you're using 20 MHz channels, much of the PLCP header issue can be avoided in 5 GHz implementations, though it is impossible to do so in 2.4 GHz implementations (unless of course you're in the middle of nowhere and need exactly channels 1, 6 and 11 and no more than those three cells for a small network). If I can space channel reuse 4 cells apart (that is two cells on different channels are between the reuse of a channel), physics tells me that the PLCP will be negligible in such an implementation IF I only disable 6 Mbps. Of course, this assumes ultimately being able to use all of the lower and upper channels at a minimum and, as I said, 20 MHz channels.


    1. In theory, perhaps. In reality 5 GHz areas touch too many of each other.

  2. I think this is again one of those "it depend" times. If you can, as Tom says, spread the channels in a way that cells don't overlap, which isn't always the case, but quite often it can be, then you can set basic rates higher, otherwise you won't be able to.

    1. I don't buy that "spreading" the channels is possible unless you use DFS, which unleashes a whole other set of instability problems.

  3. This comment has been removed by a blog administrator.


Post a Comment

Popular posts from this blog

Spectrum Deception

Free Sniffing in Windows! (Kind Of)

What's New (and Missing) in the WiFi for iPhone 6