Blogs

30 Random Technical Thoughts by a WiFi Engineer

By gstefanick posted Feb 04, 2014 03:22 PM

  

1) CRC is cyclic redundancy check. This means a radio received a frame and failed the checksum. A normal communication the intended receiver will not ACK and the sender will retransmit the frame. What’s important to understand when sniffing just because you have a high CRC rate in your sniffer window doesn't mean the actual client communication is experiencing the same. In fact while sniffing, if you experience a high CRC rate moving closer to the transmitting radios often solves the problem. It simply means your radio can't interpret the frame. If you want to see the actual client CRC rate, you would need to visit the actual radios.

 

2) When a client on channel transmits a frame ALL radios on the channel must synchronize to the preamble and demodulate the pending frame. The receiving radios peek at the mac address to see who the intended frame is for. If it doesn't match their mac address they look at the NAV timer to set their clocks and discards the frame. Idle clients are very busy processing frames!

 

3) Noise calculations done by an 802.11 radio knows nothing about layer 1 spectrum. They determine the noise floor by various methods. Including retry rate, channel assessment, and energy detect.

 

4) Placing access points in a hallway, also called a hallway design is so 2007. Hallway designs contribute to excessive CCI (co channel interference). As client density increases and sensitive applications are added these designs fail miserably. Consider room placement during your survey.

 

5) One way speech can be caused by a poor link budget. Imagine your on a call and you can hear them but they can't hear you ? If your access point transmit power is at 100mW and your client is at 20mW this imbalance can cause data retires. Your frames don’t have the punch to travel back to the access point. Always consider the lowest client in your wifi design and match their power on the access points.

 

6) Walls are your friends. Design using walls as attenuation points. Letting RF run amuck and leak into areas cause unnecessary CCI.

7) If you’re a player in WiFi, you better bring the tools and know how to use them. The three S’s. Spectrum, Sniffer and Survey tools. Know them. Know them very well.

8) Channel 165 / UNII2 - 2E  support. While most infrastructure devices support channel 165. Most clients do not. Allowing 165 in your design can cause outages. Same is true for UNII 2 and UNII2E.

9) UNII2 - 2E DFS is real folks. It can disrupt communications. I’ve been the victim of weather radar and my connection dropped.  Pick your channels wisely my friend!

 

10) The WiFi client is the biggest cow boy of them all! There is one thing which is consistent, it’s your wifi network. Your access points should be configured the same. They should be on the same code. You should expect a certainly level of performance from your infrastructure. Your clients on the other hand. What a hand bag of dysfunctional little peeps. Having an understanding of your clients is important. Know that clients aren't created equal. Like humans they all hear, talk and behave differently.

 

11) Clients dictate roaming. Your wifi client has secret sauce typically built into the driver. This sauce instructs the wifi client how to build a neighbor list and when it should roam. Not all clients roam well.

 

12) Apple devices don’t support OKC. They do support 802.11r also called Fast Transition Roaming.  If you use 802.1X and an Apple device. As they roam from access point to access point, they’re doing a full 802.1X authentication. AP—>Controller—>Radius —> AD and back every time!

 

13) Did you know all clients on an access point share the same broadcast encryption key ? Its the 3rd handshake in the 4-way handshake actually.

 

14) When connected at a specific PHY rate most folks relate PHY to an actual throughput. Not the case. If connected at 54 PHY, at best you’re half the actual throughput due to overhead. 54 PHY means you can transmit up to 54 million bits per transmission.

 

15) OKC (Opportunistic Key Caching) — Aruba’s technical brief on the subject is the best documented reference I’ve come across. Go get yourself some.

http://community.arubanetworks.com/aruba/attachments/aruba/115/1097/1/Aruba+OKC+Implementation.pdf

 

16) A wise engineer reads the release notes before upgrading their wireless network!

 

17) Limit the number of SSIDs in your network. Each SSID adds overhead. In other words, each SSID adds additional management frames which use air time and cause contention. A single access point broadcasting16 SSIDS can cause upwards of 50% channel utilization with 1 PHY mandatory enabled.

 

18) If you're running sensitive applications on your wireless network insure your wireless is properly designed. Voice applications require 150 ms or less round trip time. Proper cell overlap and access point density are a requirement to meet such standards.

 

19) Location grade networks require access points at the edge. In some cases access points in monitor mode are deployed to lessen CCI while enhancing location accuracy.
 

20) It takes a lot of wires to run wireless. In fact, consider running 2 cables to all access points to support 802.11ac. 

 

21) Are you looking to fill in your wireless security gaps? Read the CWSP Certified Wireless Security Professional. It's like glue.

 

22) Are you serious about wifi? Build a lab, purchase tools, practice what you learned. Hands on experience is more valuable then any certificate. 

 

23) What is a dB? dB is a logarithmic unit used to describe a ratio. The ratio may be power, sound pressure, voltage or intensity or several other things. This is how we can compare dBi, dBd, and dBm.

 

24) There are 5 grades of wireless (we can agree to disagree) data, voice, Vocera, location and stadium. Those of you that work with Vocera, you know what I mean !

 

25) Wifi is half duplex .. Wave 2 802.11ac will change that .. Lets call it Half Duplex+   :)

 

26) Only one radio can transmit on channel at a time.

 

27) Rules of 3 and 10, RF math know them!

 

28) Apple Bonjour  TTL = 1. This is why Apple services don’t expand past it’s own subnet.

 

29) The proper way in referencing 802.1X is with a capital X. Some reference 802.1x. 802.1X is a standard. The use of a lower case x would suggest an amendment to a standard.

 

30) You often see TKIP and AES referenced when securing a WiFi client. Really it should be referenced as TKIP and CCMP, not AES. TKIP and CCMP are encryption protocols. AES and RC4 are ciphers, CCMP/AES and TKIP/RC4. You can see vendors are mixing a cipher with a encryption protocol.

Which of my random 30 thoughts were interesting to you !?

 

21 comments
5 views

Comments

Jun 18, 2018 04:04 PM

Are you serious about WIFI? Build a lab, purchase tools, practice what you learned. Hands on experience is more valuable then any certificate.-/////I am a wireless project manager and i don't get to deep dive into the technology like i should. I would love to attend a series of classes that start at the basics and transition to the intermediate level 

Feb 16, 2016 02:17 PM

Hi George,

Agree, this is why IF we choose to take advantage of these channels we need to make sure that in our environment we plan in advance to be sure that our clients and AP infrastructure support the UNII 2e channels we want to use. For folks that are not part of our production network, we probably don't care, though from a BYOD and guest network perspective it bears careful considerations because we would not be able to 'control' what devices are used other than policy and of course MDM. My point being is that there are situations where the extra channels would be a welcome addition provided we consider the additional factors associated with their use.

Have a great one!

Sincerely,

Skip Bayro CISSP, CRISC, CCSE, NSA, Comm-AMEL
Mobile - (817) 734-4780
Lead Systems / Sales Engineer, Americas
Fluke Networks / Airmagnet

<~~ Sent from my iPhone 5 ~~>

Feb 16, 2016 12:12 PM

Hi Skip! 

 

Thanks for the reply.

 

Certainly, I think this list could go to #100+ when we start getting into the weeds. On #8 you would surprised. Unless you have absolute control of the end clients you run the risk of clients romaing to areas where UNII2 and UNII2E isn't supported resulting in poor performance.   

 

On our network we have in excess of 25,000 Wi-Fi clients. We test 1 -2 clients a week for production deployments and you would be surprised how many clients don't actually support UNII2 and UNII2E. In HD deployments you almost always see your typical mobiles, iOS and Android and the majority of these devices do comply and support UNII2 and UNII2E channels.  But not so much in the real world enterprise environment, in our testing anyway. 

 

 

Feb 16, 2016 11:21 AM

Top Marks George!

 

Although I agree to disagree with you on a portion of thought #8. While I agree that Channel 165 should be avoided unless it is known that your intended client devices will support it, I disagree that UNII-2e should be completely avoided. Yes, DFS and how it will affect our network is something that needs to be examined and thought about, but we should be doing this anyway as part of good design planning. I haven't really run into any client issues with UNII-2e channel support with todays clients/drivers. While I am certain there are those clients out there with chipsets and/or drivers that may not support the extended channels, I think that now these are the exceptions and not the rule.

 

I would propose that instead of avoiding all of those desperately channels, lets exclude channels 120, 124, 128 and 132, ones that we know fall into the frequency ranges of TDWR (Terminal Doppler Weather Radar) and take advantage of the remaining 7 channels (100, 104, 108, 112, 116, 136, 140). It is true that we must take certain precautions to ensure that we ensure that our gear has radar detection and DFS capabilities, but most quality, commercial grade AP Infrastructure solutions today have this capability.

 

In summation, if the design doesn't dictate the need for a High Density AP installation/channel plan for capacity, then yes, stick with the standard available UNII 1,2 and 3 channel sets, but if the need is there, and with a little extra prior planning, those 7 extra channels can go a long way.

 

Some I would add to the list:

 

#31 - Be judicious with AP power! More power is NOT better (Sorry Tim Allen, but in WiFi this is the case). Turning AP power up to cover "gaps" in a poorly designed network can cause more problems such as inefficient roaming, "Sticky Client", Near-Far and other issues. Remember the wavelength for 5G is HALF that of 2.4G (2.3in vs 4.9in) so 5G will need a bit more power to travel the same distance. RRM (Power) and ARM (Power) usually do a pretty good job of managing this, but remember to spot check it. TRUST but VERIFY.

 

#32 - Disable those low data rates to help improve overall performance and reduce common issues like Sticky Client and Channel overload. Start with 1 and 2Mbps (DBPSK/DQPSK), and 6 and 9 Mbps HR-ERP in the ISM band and 6 and 9 Mbps OFDM in the UNII band.

 

Great Read and Great Points!

 

Sincerely,

 

Skip Bayro

Lead WLAN Systems Engineer, Americas

Airmagnet/Netscout

Aug 06, 2014 09:14 PM

Thank you .. Glad you enjoyed the blog post ..

Aug 06, 2014 06:50 PM

Had no idea Apple did not do OKC. Would explain how busy my radius servers are. Really like points 8 and 9; seems that it has a big impact on effectiveness of 80Mhz channels in the Enterprise. I have a campus near an airport and we get DFS hits.

Feb 25, 2014 06:25 PM

Apple's comments are confusing, just my 2 pennys.  My personal experience, legacy devices had issues on 802.11r enabled WLANs. 

 

Cisco supports OKC/PKC and Stickey Key. Apple's mentin 

 

SKC Cache Support.......................... Disabled

 

 

Feb 24, 2014 08:16 AM

About #12. Apple has this article: http://support.apple.com/kb/HT5535

Which says:

"Even if an iOS device doesn't support 802.11r, iOS 5.1 added support for "pairwise master key identifier caching" (PMKID caching), which can be used with some Cisco equipment to improve roaming between APs. Additional SSIDs may be necessary to support both FT-capable iOS devices and PMKID-caching iOS devices."

 

This suggests that 802.11r and PMKID Caching shouldn't be used together on the same SSID. Or is this just because legacy client's might not work properly?

 

Also, is Apple referring to 802.11i PMK Caching or does Cisco has some secret sauce? From what I've gathered Cisco uses just the standard 802.11i PMK Caching when caching takes place when roaming back to previously associated AP, same as Aruba.

Feb 21, 2014 12:42 PM

I'm glad some folks like my ramblings. :)

 

Have a good weekend all! 

Feb 21, 2014 12:41 PM

We found when 802.11r is enabled, some lagecy devices, most with older drivers failed at asscoiation. Devices that were updated to newer drivers worked fine. Its a mixed bag for sure. 

Feb 21, 2014 02:26 AM

The problem with 11r is the enabling it screws with non-apple devices. :(

Feb 12, 2014 02:16 PM

#12 anyone have any good aruba guides or tips for 802.11r??

Feb 10, 2014 08:25 AM

This is an awesome post, jsut awesome.

 

I would tend to agree with Lee Badman regarding #4, it just not possible sometimes based on architecture and have to live with hallways. Sucks but should be communicated to customer !!!!!

Feb 09, 2014 07:23 PM

#8 beautifully said. That's how I have my environment set up. It's funny how many times I must justify it when working with Aruba folks.

Feb 06, 2014 06:00 PM

An excellent list George!

 

On item #12, iOS does support sticky key caching (SKC), which can reduce the number of repeated roundtrips to the RADIUS server.

Feb 06, 2014 09:25 AM

#29 drives me crazy.

 

#8/9 Do a lot of devices not support UNII2? Do you design without these channels? How will this affect your ac 80mhz designs?

 

#31 Don't trust what the marketting team tells you, verify yourself :)

Feb 04, 2014 07:12 PM

good stuff there george!, thats why you are the wirelesssguru!

 

Feb 04, 2014 05:46 PM

Hi George,

Great quick list for everyone to digest and understand! I agree with *almost* everything you said :) Just a few quick thoughts of mine on some of these items:

 

2) If the frame is at a data rate which the client can't demodulate because it's SNR is too weak, it will only use the PLCP Header Signal / Length field to determine how long to defer access for the current frame only. It won't be able to look into the MAC layer at the destination address or the NAV timer to defer for future required frames (like ACK or fragment burst). Remember there is both physical and virtual carrier sense.

 

5,6) Great points!!! Everyone should understand these as they are critical for modern WLANs.

 

9) DFS weather radar (and military radar) detection is HIGHLY dependent on location! Most locations I actually don't see DFS radar triggers. I'd say it's definitely the minority of situations where I've run into an issue. But it does exist and WLAN admins should check to see if a location is affected before designing around DFS channels.

 

12) Let's get moved over to Fast Transition enabled WLAN's baby! Oh yeah, once some notable client compatibility issues get worked out (cough *OS X* cough).

 

13) The group encryption key actually has some interesting developments being made by vendors when implementing IPv6 support. Since IPv6 relies so heavily on multicast RA's and ND, there can be an issue where one SSID supports multiple backend VLANs through dynamic assignment but clients then receive and assign themselves addresses in ALL backend VLANs because they receive the multicast RA's from all subnets. Some vendors are now breaking up the group encryption keys on a per-VLAN basis, and the device is assigned the GTK from only the one VLAN they have been assigned into. This fixes the IPv6 multicast issue. (Other vendors are choosing to convert IPv6 multicast into unicast frames to get around this issue, so there is more than one way to skin the cat here. I believe Cisco is doing the GTK method; not sure how Aruba is doing this yet.)

 

16) Yes, read release notes! Also TEST YOUR CLIENTS before deploying new code!

 

17) I have an SSID overhead calculator on my blog. I won't link to it in bad form though :)

 

22) Every serious Wi-Fi engineer that I've ever met has a home lab. And they use it... regularly. It's the name of the game!

 

24) 5 grades of Wi-Fi... hmm... kinda reminds me of 5th Gen Wi-Fi :)  #poke

 

28) Apple Bonjour also has a multicast address in the range reserved for link-local multicast. So even if the TTL were larger, routers won't forward it. No bueno!

 

29) I see you are a stickler for details like I am!

 

30) Thanks for pointing this out. I've caught myself mixing protocol and cipher terminology and will be sure to reference them properly.

 

Overall, great list George! Keep on truckin' (or should I say boatin').

 

Cheers,

Andrew von Nagy

 

Feb 04, 2014 04:23 PM

I fully agree with #4- but often design is beholden to architects and such, sadly. When they demand and overrule, sometimes you have to make the best of the design you'fd rather not have. Livin' in the world sucks sometimes, baby...

Feb 04, 2014 03:47 PM

VERY NICE!!!

Feb 04, 2014 03:24 PM

GOOD Stuff man!