How do I find that D@*n Rogue?! (Part 3 of 3 on Containment)

So now that we know what containment looks like (see 2nd post here), how do you find the offending device if it is actually containing your APs?  The issue here is that you don’t know what the device is that is doing the containment because you only see the spoofed frames in a packet capture.  It could be an AP that is servicing other clients, but you don’t know which SSID it is broadcasting.  If you did, you could just track the signal strength of the SSID and walk around until you find the strongest signal.  So how do you track down something that isn’t known to be broadcasting anything?

Here is how I have done it.  There may be other (better) ways.  If you know one, please share!

If we look back at the same packet capture in my previous blog post, you can see there is a column called “Signal.”  The signal strength is what is seen from the perspective of the adapter taking the packet capture.  I am using a Netgear A6210 here. 

The big item to note is the difference in signal strength between the authorized AP frames (beacons, probe responses, and encrypted data), and the rogue AP frames (deauths and disassociations).  All frames appear to be from the same BSSID/source address but the signal strength is very different between the beacons (44%) and the deauths/disassociations (100%).  The beacons would be from the authorized AP while the deauths/disassociations are from the rogue AP.  My client adapter is very close to the rogue AP in this example.

Another indicator you have 2 APs in play could be the data rates used.  Notice the deauths/disassociations are using 6 Mbps as the data rate while the beacons are sent at 12 Mbps.  This is because I configured my authorized SSID to use 12 Mbps as my lowest data rate, but the rogue AP doing containment doesn’t mimic that.  This could be more obvious in a 2.4 GHz scenario where you (hopefully) have disabled 802.11b rates.

Now if the rogue AP is also broadcasting the same SSID in an attempt to get clients to join it for a Man-in-the-Middle attack, we would see beacon frames with different source addresses and BSSIDs.   You could then hone in on the MAC that is not your vendor of AP by looking up the vendor OUI here.  Then track it down with an Aircheck or utility on your phone.

I am using Savvius OmniPeek for my packet captures above, but you can also use Wireshark, though it shows up slightly different.

This is from a packet capture using a Cisco AP in sniffer mode and sending it to my laptop running Wireshark.

In the OmniPeek capture (top) you can see it uses Signal as a percentage, though you can also add the Signal dBm column if you prefer.  In the Wireshark image above I added both Signal [dBm] and Signal strength in %.  The deauths/disassociations are at -43 dBm/55% and the beacons are -69 dBm/27%.  So again, my AP doing the capture is closer to the rogue device than the authorized AP.

Obviously walking around with an AP doing the packet captures and sending them to a laptop running Wireshark is not ideal, so I will focus on the Omnipeek method using the Netgear adapter for my example.  I don’t own a Mac that can natively capture wireless packets.

How you find the rogue AP, if you didn’t pick up on it already, is by playing a game of Hot and Cold.  Start walking around with the packet capture running and watch the signal strengths change.  It can be easier to watch by filtering the capture to only show the BSSID you are looking at as I did below.  Or you can filter by the deauths and disassociations specifically to watch only those frames.

In a real environment you will likely not be close to the rogue AP initially, but closer to your AP that is being contained.  Often starting underneath your AP and walking around looking for the rogue AP.  See image below.  Notice the signal strengths are stronger for the beacons than the deauths/disassociations.

Here is a capture of when I was about equal distance between the rogue AP and the authorized AP.  Signal strengths of the beacons and deauths/disassociations are fairly close at 73-76%.  This can be tricky if you happen to start somewhere like this.  If you move toward or away from your AP you will start to see a larger signal disparity.

Here is a capture showing when I was closer to the rogue AP and further away from the authorized AP.

This works if the rogue AP is constantly sending deauths/disassociations.  Usually this will occur anytime a client is connected to the SSID that the rogue AP is containing.  So you may have to have a phone or something handy to constantly be trying to associate to the SSID in order to ensure you see the deauths/disassociation frames.

There you have it.  You find the rogue AP with a slightly more complex game of Hot and Cold.  The hardest part is figuring out which frames are coming from the rogue device.  Once you know, just track it down and have your way with it when you find it.  🙂











What Does Containment Look Like? (Part 2 of 3 on Containment)

Disclaimer – Containment is a very serious topic and can have legal and financial consequences.  You should never contain any APs that are not your own unless they are a security threat, like spoofing your SSID or a rogue ap attached to your network.  The spectrum allotted for use by the fcc is not licensed and therefore anyone is free to use it as long as they are within the bounds of the fcc regulations.  Marriott was nailed for doing this in their hotel a few years back – see here.   

What Do I Have Here?

How do you know if you are actually being contained?

I had a deployment recently where we were concerned that our APs were being contained.  This was especially important to us because this was a bake-off scenario with multiple vendor APs in the same building.  Not an ideal deployment, but something we had to work with.  Our Cisco WLCs were giving alerts regarding a Deauth attack which is triggered when more than 300 Deaths happen from one MAC in a 10 second period.  Obviously if another vendor was containing us, that would be a big deal and likely sway the results of the bake-off.  Unfortunately the Deauths would happen randomly, often hours apart.  After attempting to catch it with a packet capture to no avail, I had to dive into how containment works to determine if that actually is what was happening.

Here is the alert we received on our WLC:

Detail: Wireless Attack Signature Name: Deauth flood
Severity: 8
Category: MEDIUM
Count: 1
Source: Source MAC: 34:fa:9f:0f:c2:ec
Target: Host Name: AP506
Host: AP506

Time: Thu Mar 01 12:51:00 MST 2018
First Seen: Thu Mar 01 12:51:00 MST 2018
Last Seen: Thu Mar 01 12:51:00 MST 2018

Name: Wireless Deauthentiaction flood Alert
Detects a IDS signature attacked that is deauthenticating clients.

So what did this tell us?  Were we being contained by an AP with MAC address 34:fa:9f:0f:c2:ec?  The answer was no.  I came to that conclusion based on a couple different pieces of information.

How does containment work?

Most vendors perform containment by spoofing the MAC of the AP they want to contain, more specifically they spoof the BSSID.  They will send deauthentication and/or disassociation frames to the clients connected to the contained SSID, spoofed to appear like they are coming from the AP itself.  You can see an example of this below.  I am running a Meraki MR24 as the Authorized AP  broadcasting the SSID “PleaseDontContainMe”.  I have a Cisco 1702 in Monitor mode set to perform the containment.

The red highlighted packets show the beginning of the containment.  Notice that the source appears to come from the Meraki MR24 AP.

While containment mode was enabled I was not able to connect my phone (Scott-GS8) to the SSID.  It would try multiple times, occasionally reverting to asking me for a new PSK assuming it was bad.  The AP doing containment just hammered the client with disassociation and deauthentication frames.  I could show additional screenshots but you would just see a lot more of the same.  Lots of deauths and disassociation.

Now my 1702 AP was in Monitor mode which will devote the entire time attempting to deauth the client when in containment.  If the 1702 AP was also serving clients than it would not devote all that time to containment.  I switched the AP to do just that, but still had extreme difficulties connecting my phone to the SSID.

Once I saw what containment actually looked and felt like, I visited the site to test out my own client connectivity.  I wanted to see if my clients would be deauthenticated.  We hadn’t heard any major complaints from the site, we were just trying to be proactive.  I connected up to 4 devices at once streaming Netflix/Hulu near the AP that most commonly alerted on the deauth attack.  I had zero issues and my clients were never disconnected.

If you notice, the source for the deauths in the alert was 34:fa:9f:0f:c2:ec.  This is a MAC for a Ruckus AP (we were proposing Cisco).  There were other MACs identified in the alerts, but 90% were this Ruckus MAC address.  If the source of the deauth was the Ruckus AP, then it would actually appear that the Ruckus APs were the target of the deauthentication attack and not the source.  Because containment spoofs the MAC of the targeted AP, our APs wouldn’t see the actual AP doing the attack, only the symptom of the attack which would be the spoofed deauth frames.  Unless they were deauthing their own clients for some reason.

Knowing how containment worked, plus the fact that we were not having major client issues in the area, and I had no issues while onsite, led me to believe that there were not any APs attacking/containing us, though it could have been happening to another vendor’s APs.  I advised the customer that there was an issue going on that could negatively impact one of the vendors and let them deal with it from there on.

Unfortunately I wasn’t able to get a capture of the event happening even after sitting there for hours on multiple occasions.  I would have loved to locate the offending device.  I imagine if I had caught the event in a packet capture I would have seen a lot of the above screenshot.  Lots of deauths with a source of the Ruckus AP.  The next step would have been to physically locate it.  That can be challenging when you don’t know where it is coming from and don’t have an SSID to track the RSSI.





My Experience Being a Voyer!

Welcome to Voyers!

I had the amazing opportunity to attend the first ever Voyers conference in Nashville, TN last week put on by Nyansa.  (Note the spelling, voyers, NOT voyeurs.  Though that may have been an interesting conference also!)  For any who do not know what/who Nyansa is, they make a product called Voyance, hence the Voyers conference for the users of Voyance.  Voyance in a nut shell provides analytics to wireless environments that assist in making intelligent business decisions and prioritizing and troubleshooting issues.

I apparently have been saying it wrong this whole time.  Abe Ankumah (Founder and CEO) explained at the opening of the conference that Nyansa is a word from the Akan language out of Ghana.  It means wisdom from learning and is pronounced Knee-ann sah.

The Voyers conference gave us the chance to see a little behind the curtains view of the product as well as some peeking into what was coming, which admittedly got me pretty excited!  Unfortunately I can’t talk about the up and coming stuff as it is not public yet.  You never peek and tell.  Though they are doing some beta testing with customers, so if you are really curious let me know and we can look at getting you added to the beta testing, and then of course you get to see know the secrets.

This was my first chance to meet many of the Nyansa employees in person, and I was not disappointed.  The founders (Abe, Anand, and Dan) were all very nice and down to earth guys.  I was impressed at how eager and willing they were to sit and chat with anybody to discuss their product, or anything else for that matter.  They loved to hear feedback, whether it was good or bad, and were all very appreciative of their customers and partners.

During the conference we heard from Nyansa employees as well as many different customers from different verticals.  It was neat to see how Voyance was used and benefited the different industries like healthcare, higher ed, software and hardware manufacturers, and even ride-sharing companies.

Here are some of my highlights from the conference.

Anand Srinivas (Founder and CTO) spoke about what the actual benefits of analytics should be, namely, assisting in your workflow.  Whether that be making the workflow more efficient, or even highlighting a better workflow with the additional data you now have to work with.  I loved the focus on the value of the analytics.  He mentioned specifically that it is not just monitoring or more in depth graphs, but there needed to be added value from the data.  Paraphrasing his words, analytics should do 3 things:

  1. Efficiently answer complex questions (correlating data appropriately)
  2. Proactively recommend real action (based on experience/knowledge)
  3. Verify results and provide feedback

A couple of the customers that spoke (which I won’t publicly name) had some excellent input as well.   One presenter from a software company made the statement “Network performance impacts company culture.”  I thought that was very insightful and absolutely true.  The idea being that employees want to be able to get their crap done.  If the network is slow or down, that not only frustrates employees, but can drastically impact the mood of everyone and the credibility of the IT department.  Often employees will live with issues without telling anyone.  Products like Voyance give information needed to be proactive in addressing issues and allows IT to focus more on the actual business needs, and hopefully positively impacting the overall culture.

GT Hill of Nyansa showed an example of where Voyance caught interference in the 5 GHz spectrum.  I thought this was really interesting.  Part because Voyance doesn’t do any kind of spectrum analysis, but also because 5 GHz interference is pretty rare.  This was validated with on-site spectrum analysis. He also brought up the ability to determine when APs are not functioning, even when they are reporting as online (stupid bugs!).  And of course GT was entertaining as well.  You would expect nothing less. Though his slides were much more colorful then the traditional black/white plain slides seen at WLPC.

There was a presentation by a couple people from a healthcare company discussing how they used Voyance to validate the successful roll out of a new VoWLAN phone.  They could watch the baseline change based on adjustments made to the environment and see more than just traditional RSSI/SNR.  Troubleshooting was quicker to validate whether issues were actually wireless related or something else.  They identified packet drop issues from some clinical devices and were able to narrow down the root cause quickly. (Hint, it wasn’t the Wi-Fi)

Another item that was mentioned was the ability for organizations to intelligently decide when to refresh hardware or change designs based on real world data.  An organization could hold off on an AP upgrade for a year or two longer and still guarantee good user experience based on actual data.  Wireless design changes can be validated with before and after metrics that show increased performance.  These are huge benefits to strapped IT departments.

I really enjoyed the Voyers conference, and not just because the evenings were full of good music, good drinks, and good food.  The people there were great, Nyansa employees and other attendees alike.  I met a lot of new people and was able to catch up with some good friends.  I am excited to be a part of the Nyansa community.


Disclaimer:  Nyansa did pay for my flight to attend the conference in exchange for honest and unbiased (public) feedback. 



Why Can’t I Contain?! (Part 1 of 3 on Containment)

Disclaimer – Containment is a very serious topic and can have legal and financial consequences.  You should never contain any APs that are not your own unless they are a security threat, like spoofing your SSID or a rogue ap attached to your network.  The spectrum allotted for use by the fcc is not licensed and therefore anyone is free to use it as long as they are within the bounds of the fcc regulations.  Marriott was nailed for doing this in their hotel a few years back – see here.   


As I am sure most of you are aware, sometimes crap just doesn’t work when you are trying to set something up.  I had the idea of doing a blog post on containment for a while and so I was setting up the lab at home to test with.  But no matter how hard I tried I couldn’t get my APs to contain each other.   I was limiting the containment to a specific SSID to avoid causing disruption to family and neighbors (and to avoid any legal issues).  I tried getting my Aruba APs to contain my Meraki and Cisco APs, Meraki APs containing my Aruba and Cisco APs, and my Cisco APs containing my Aruba or Meraki APs.  Nothing worked!  None of them would contain the other and it was pissing me off!

I had set up a quick test a few months back and it worked great, so why was this not working?

In my Cisco 2504 controller when I would set the SSID to contain, the response on the WLC said Containment Pending with a message stating “No AP’s available for containment.”  I had up to three APs running on monitor mode and it still wouldn’t do it.  They would see the AP and classified it, just wouldn’t contain it.

My Meraki APs would list the SSID as “uncontained” and never switch to “contained.”  I had one MR32 with a dedicated radio that should have done it, and another MR24 set to Air Marshal mode also.  Still nothing.

The Aruba (Instant) APs would tell me nothing.  Once I set the AP in monitor mode and the SSID to containment, it just sat there.  Now full disclosure, I am not very savvy with Aruba so it may have actually been telling me more but I didn’t know where to look.  But according to the packet captures, it did nothing.

When I set up the test I was using only 5 GHz and statically assigned the channel I was using to 100 as it was clean and I wanted to avoid impacting anything around me.  I set up an SSID called PleaseDontContainMe to broadcast and then connected a few devices to it.  I would set up a packet capture using Omnipeek and then set the APs to contain and watch for the containment symptoms to show up (see my next blog post for details on that!).

I tried different code versions on Cisco and Aruba, and even Meraki (I had an upgrade pending) but didn’t get anywhere.

Some of you more savvy/experienced/smarter engineers than I may have already identified my issue.  Apparently APs will not perform containment on any DFS channel!!!

I tested both channel 100 and channel 60, and no containment.  So it is not limited to U-NII 2 extended, but impacts all U-NII 2 channels (52-144).  As soon as I moved to channel 161, containment away!  I didn’t test all of the U-NII 2 channels, but can assume I would get the same results on the rest of the channels in the U-NII 2 range.

The reason for this obviously has something to do with the DFS requirements for radar energy detection.  Specifically I don’t know why, maybe an AP when doing containment isn’t built with the intelligence to check or listen for radar? If you know why please let me know.  Or send me to the documentation that explains it.

It does bring up an interesting security risk.  If you are attempting to do something malicious, like spoof an SSID to perform a man in the middle attack, or place a rogue AP on the network, choosing a DFS channel to broadcast on would prevent any containment methods from interfering.  The business or entity would have to utilize other methods to mitigate those threats.  Either manually/physically tracking them down to remove them, or in the case of the rogue AP on the network, some kind of port trace to disable the switch port.

Interesting stuff!  Now, on to the blog post I was trying to do to begin with…


Netsh WHAT??!!!


I am a little embarrassed to admit the fact that I have been in the IT world for 14 years and have never realized how much cool stuff is available with the simple netsh command utility in Windows.  Sure I’ve used it over the years to do specific things, usually following some set of instructions I found trying to solve a specific issue, but I never explored the options to see what else was in there.  Not until I was studying for the CWNA exam from CWNP that is.  In the CWNA study guide (found here) it listed some of the different netsh commands and what information they can give you.  I started looking at them and then instantly wondered HOW HAVE I NOT KNOWN ABOUT THIS????

So I write this post in hopes that I don’t forget about the cool stuff you can see, and in an effort to share the knowledge with others the things I wish I had known for so long…


There so many different commands in this utility.  Network traces, Ethernet and wireless tools and information menus, and firewall configuration, and on and on.  I’ll discuss the few I have played with.

dhcpclient trace

One of the first neat options I used was the dhcpclient trace option.  This allows you to basically enable a debug of the dhcp process and then dump it to a log file.

First you enable the trace (using a command prompt with admin privileges):  netsh dhcpclient trace enable

Then you perform the DHCP function you are troubleshooting.

And then stop the trace:  netsh dhcpclient trace disable

Then dump the file:  netsh dhcpclient trace dump

When you dump the file it is placed here: C:\Windows\System32

\LogFiles\WMI and is called “dhcpv4trace.log”

I opened the trace log in notepad and you could see very detailed information regarding the process.  I performed a DHCP release and renew during my trace and you can see the relevant information here:

 3-14-2018 21:38:56:482 Id:5323 Desc: OBTAIN LEASE: [{4702f80a-1110-46fc-8987-f786383f454f}] [19985273102270464] ==> 
 3-14-2018 21:38:56:482 Id:5201 Desc: Sending Discover on {4702f80a-1110-46fc-8987-f786383f454f}. Error code is 0
 3-14-2018 21:38:56:482 Id:5202 Desc: Waiting for Offer on {4702f80a-1110-46fc-8987-f786383f454f}. Wait time is 3
 3-14-2018 21:38:57:500 Id:5203 Desc: Recieving a DHCP message on {4702f80a-1110-46fc-8987-f786383f454f}. Error code is 0
 3-14-2018 21:38:57:500 Id:5206 Desc: Offer of from is accepted on {4702f80a-1110-46fc-8987-f786383f454f} .
 3-14-2018 21:38:57:500 Id:5209 Desc: Sending Request on {4702f80a-1110-46fc-8987-f786383f454f}. Error code is 0.
 3-14-2018 21:38:57:500 Id:5210 Desc: Waiting for ACK on {4702f80a-1110-46fc-8987-f786383f454f}.
 3-14-2018 21:38:57:506 Id:5203 Desc: Recieving a DHCP message on {4702f80a-1110-46fc-8987-f786383f454f}. Error code is 0
 3-14-2018 21:38:57:506 Id:5212 Desc: ACK of from is accepted on {4702f80a-1110-46fc-8987-f786383f454f}.
 3-14-2018 21:38:59:488 Id:5325 Desc: DhcpSetIpRoute: ADD: Dest=, DestMask=, NextHop=, Metric=0, Address=
 3-14-2018 21:38:59:488 Id:5325 Desc: DhcpSetGatewaysAndStaticRoutes for the adapter: {4702f80a-1110-46fc-8987-f786383f454f}, Error: 0
 3-14-2018 21:38:59:489 Id:5319 Desc: Successfully Deleted the address:
 3-14-2018 21:38:59:509 Id:5318 Desc: Successfully Plumbed the address:
 3-14-2018 21:38:59:509 Id:5309 Desc: Adding the address of on {4702f80a-1110-46fc-8987-f786383f454f}. Error code is 0.
 3-14-2018 21:38:59:556 Id:5312 Desc: Registering AdapterName: {4702f80a-1110-46fc-8987-f786383f454f} Address: 1175720970 Flags : [] Error : 0
 3-14-2018 21:39: 0:675 Id:5301 Desc: Updating Stack abt address on {4702f80a-1110-46fc-8987-f786383f454f}. Error code is 0.

You can see very easily the steps performed and where one may fail (all of mine were successful).

netsh wlan

The netsh wlan commands are very helpful in all things wireless.  I know I will end up using these frequently, and again wonder how I didn’t know about them.  Here are some of my favorite commands:  (Hint, some of these may be tested on in the CWNA exam!)

netsh wlan show drivers

This command will list the specific driver information which can be helpful when checking version numbers.  But it also tells you things like radio types (802.11a/b/g/n/ac), MFP support (802.11w), and authentication/encryption support (WEP, WPA Personal, WPA-Enterprise, TKIP, CCMP, etc..)  This can be huge when trying to determine what the client can do, especially if you don’t know much about that specific device.

netsh wlan show networks mode=bssid

This option lets you view from the client’s point of view what networks it can see and how well it can see them.  Great info including what radio type, encryption, channel, etc.  It also gives details like data rates enabled, RSSI (in percentage) the client sees the AP, and multiple APs from a single SSID, listed as separate BSSIDs.

netsh wlan show interfaces

This one gives you quick details about the SSID it is currently connected to.  Pretty much everything you see in the previous command, but only for the one SSID, and it also includes the current negotiated data rates in use, which may change every time you run it.

netsh wlan show profile profilename

This command will tell you specific details about the actual setup for the wireless profile used.  Things like if it will auto-reconnect if the SSID is in range, what security settings are in use, what EAP types, etc.   (SSID censored for privacy)

netsh show wirelesscapabilities

This one is awesome!  Mostly because it is an easy way to determine specific features you may want to know if the client supports.  Does the client support 802.11k,v, or r?  Or how many spatial streams does the client have?  Can the client can participate in MU-MIMO?  All can be answered with this one.

(Screen shot was too long to include in one image.  You’ll have to look this one up yourself!)

netsh wlan show all  > netsh_output.txt

Last but not least, here is a quick way to run all of them (the wireless ones anyway) and output it to a text file.  Than you can open the text doc and just search for the specific things you are looking for.

Hope that helps someone troubleshoot something a little easier.  I know it will help me, if I remember to use them…


Cisco AP Death Matrix

So Cisco is killing off APs very quickly in an effort ramp up the SDN stuff with their DNA thing.  I have been having a terrible time remembering exactly which code each AP stops working and I find myself visiting the compatibility matrix almost daily (link here).  I figured I could make a quick and dirty matrix that is a little easier to find the info I want.  Namely which APs die on what code.  I only used main code trains ignoring code that has already been deferred.  Let me know if I missed something or screwed something up.

Code Level

APs that Die (last supported release)

APs Born (1st supported release, that you would actually want to use)


1130, 1240, 1250, AP801, 1520



1810, 1830, 1850, 2800, 3800, IW3702 (-B)


1040, 1140, 1260, 600 OEAP

1815i, 1560


1600, AP802, 2600, 3500, 3600, 1550

1815w, 1815m, 1815t, 1540


Is Wi-Fi Safe?

This is intended for people who are not wireless engineers and may know very little about how Wi-Fi works.

I will provide an overview of the actual levels of RF (radio Frequency) energy used in typical Wi-Fi deployments.  Sorry if the title sounds a little click-baitish.  I wanted to give you some more information so that you can make a better informed decision.

Let’s talk about power.

Wi-Fi is typically measured using either watts (W), milliwatts (mW), or decibel-milliwatt (dBm).  dB is a reference measurement and dBm is the power relative to a milliwatt.  dBm gives us a much easier number to work with as many of the mW measurements used in Wi-Fi are extremely small numbers, as you will see.  Most Wi-Fi measurements in the real world are in negative dBm values.  The closer to 0 the measurement, the stronger the signal.

There are governmental regulations that limit how much output power can be used for specific frequencies.  In the USA the FCC is the entity that manages the RF spectrum.  Now there are many specific details regarding what is allowed, and many exceptions to those rules as you can imagine with any governmental regulation.  I will not be going into the weeds, but rather provide a general overview.

The FCC limits the amount of output power in the frequencies used in Wi-Fi (the 2.4GHz and 5 GHz spectrum) to a maximum of 1 watt.  Again, this is a gross generalization, but for our purposes this is the overall maximum allowed.  1 W can be defined as 1,000 mW or 30 dBm.  They are all equal.  The 1 W maximum limit is the actual power from the radio emitted prior to an antenna.  Antennas provide gain which increases the amplitude of the signal.  The limit of 1 W is referenced with an anticipated 6 dBi gain antenna, which would put the total RF energy to 4 W, 4,000 mW, or 36 dBm.  You can use higher gain antennas by reducing the output power as long as you stay under the 4 W, or 36 dBm limit, called the EIRP (Equivalent Isotropically Radiated Power).

Now to put that in perspective, the absolute maximum power we can use in Wi-Fi is 4 watts.  Microwave ovens typically run in the 700 – 1,000+ watt range, and happen to use the same frequency we use in Wi-Fi – 2.4 GHz.  Can you imagine trying to warm up yesterday’s pizza with a 4 W microwave? So we are talking a very small amount as our maximum.

RF dissipates FAST!

In most well-designed environments we are not using the maximum power levels near 1 W, but typically closer to the 100-200 mW range, or less for high dense areas.  For the purpose of this blog post I will be basing the information on a worst case scenario.

RF  energy is emitted from an antenna and radiates outward in the direction the antenna is designed.  Most home devices would emit the signal in the shape of a doughnut.  Usually equal in all directions but with a little less signal directly above or below the antenna (the black stick looking thing).  As the energy travels outward, it dissipates very rapidly.  A common analogy is a ripple in a pond.  At the point where the rock is thrown into the water the ripple is strongest.  As the waves move away from the point of impact they decrease in strength.  This is the same way RF works.  It is strongest near the source, the antenna.  In fact the rate at which it dissipates is so rapid that we end up with measurements of less than 1 mW in just a few feet!

Real World Measurements

I am going to be using an enterprise class access point (Cisco 1702i) for the test scenario below.

I have an access point (AP) configured to run at its maximum power setting which is 22 dBm, or ~160 mW.  It has a 4 dBi gain antenna so the total output could be measured at about 400 mW.

I took a few measurements with a Fluke Aircheck, which is a device used to take spot-check measurements.  

  • The first measurement I took was at a distance of 3′.  This would be about the closest most users would be to an AP in an office environment assuming 9′ ceilings and a 6′ tall person.  I measured the signal at -29 dBm.  This is equivalent to only 0.0012589254118 mW.  As you can see, at just 3 feet away we are already at 1/1,000th of a mW, or 1/1,000,000 of a watt!
  • At a distance of 6′ away I got a measurement of about -35 dBm, or 0.0003162277660 mW.  (You can see why we use dBm measurements instead of mW now.)  So in just 3′ we dropped signal by about 4 times.  That is actually a quick way of calculating signal loss – every time the distance doubles, you lose about 4 X the signal strength.  At 6 feet away from an AP running at max power we are measuring .0003 mW, and yet we started at 400 milliwatts!
  • In fact the absolute hottest signal I could measure by placing my Aircheck physically on the AP was -8 dBm, or 0.15848931925 mW.  You can see why I am not very concerned about the amount of energy I am absorbing from Wi-Fi.

Most Wi-Fi deployments are designed with a goal of -67 dBm of coverage everywhere.  Often this is done with much lower power levels than the maximum.  At -67 dBm we are at 0.0000001995262 mW.   Yes, that is 6 zeroes after the decimal.  And yes, that is a fraction of a milliwatt.  I guess you could call it 0.1 nanowatts.  For perspective, in a middle school environment that is designed for pretty high user capacity and -67 dBm coverage, the hottest signal measured in the school is about -40 dBm, or .0001 mW.

Distance dBm mW
At antenna element 26 398.10717055
0 Feet -8 0.15848932
3 Feet -29 0.00125893
6 Feet -35 0.00031623
Varies -40 0.00010000
Varies -67 0.00000020

What about the clients?

The majority of traffic is usually downstream from the AP to the client, so more often than not, it is the AP that is doing the transmitting.  But clients do transmit too.  Due to hardware limitations of the clients, many of which are battery powered, they cannot transmit at the same maximum power levels that the APs use.  Most personal client devices like cell phones, tablets, etc.  have a maximum output power of less than 20 dBm, or 100 mW.  The cell phone chips in the phones can go up to the 1 watt range, but the Wi-Fi chips are not that powerful.  When setting my phone, a Galaxy S8, to hotspot mode, the hottest measurement I could get was -4 dBm, or 0.39810717055 mW.  Still less than half of a single milliwatt.   Laptops may have higher output power levels than phones or tables, though we are also usually at least a couple feet away from the antennas which are typically around the screen of the laptop.


The simple fact that the actual amount of energy used in most Wi-Fi deployments is extremely small helps me feel way less concerned about the potential damaging effects of any Wi-Fi based radiation.  That being said, I would always offer a word of caution or common sense to give yourself that extra little space from whatever device you are using, it can’t hurt.  Place your home routers/Wi-Fi APs somewhere that is more than a foot or two away from where people typically sit.  That extra foot or two drastically decreases the exposure levels, and again, doesn’t hurt.  Are we cooking our kids in schools with Wi-Fi deployments?  I don’t think so.