This new feature released in early beta has made the cut to public release. This tool gives us as engineers another tool in the tool box. 

iOS 13 and iPadOS are an ongoing evolution of functionality and how we can use them in our workflows.  We’ve all seen the WWDC keynotes, news articles, and YouTube videos displaying the new abilities coming this fall.  Again as wireless engineers we ask, “What’s in it for me?”  

 Hold on to you RF hats, because iOS13/iPadOS has brought an unexpected diamond to us as well! You are now looking at WI-Fi Diagnostics on iOS13 and iPadOS! What you are seeing is live data utilizing the iOS 13 & iPadOS beta and the Apple WiFi Performance Diagnostics profile for iOS.

1. Make sure you have the latest version of iOS 13.
2. Use the link https://developer.apple.com/bug-reporting/profiles-and-logs/?name=Wi to get to the profiles page
3. Click the Wi-Fi for iOS Profile link.
4. Link will lead you sign into Apple Developer.  If you don’t have an account you can create one for free.
5. After two-factor authentication is complete you will be asked to allow to download the configuration profile.
6. Choose a device, in our case we want the device specific choice iPhone or iPad. 
7. You’ll se the profile downloaded complete and next steps.
8. Open up Settings and right under your iCloud information you’ll see a Profile Downloaded section that normally isn’t there.
9. Click it and verify the signed by/description for WiFi Performance Diagnostics then click Install in the top right corner. 
10. You’ll be asked for your iPhone passcode.
11. You’ll be prompted one more time with Consent details and Install in the top right corner.
12. Install one more time will pop up from the bottom.
13. Profile will be installed and you can Done in the top right hand corner.
14. Optional - If you want to verify/remove the profile its located under Settings>General>Profiles & Device Management.

Now with the profile installed, you’ll have the ability to  see the diagnostics page of the wireless network your connected to.

Open up Settings>Wi-Fi.

You’ll see the Wi-Fi networks available and the one your  currently connected to.  Click on the “blue circle i” next to your currently connected network.

Click on Diagnostics and you’ll be lead to valuable wireless related information!  Information including:

https://www.cisco.com/c/en/us/support/docs/field-notices/702/fn70208.html?emailclick=CNSemail 

Want to learn more about the new Side Kick? 

http://www.cleartosend.net/cts-109-ekahau-sidekick-spectrum-analysis-finnish-rap/

The question comes up from time to time about using a Mac Book Pro OSX for real-time video. While it can be done and works well most of the time in a stationary fashion you need to be aware of what limitations you should expect, especially if you are using enterprise grade security.

Knowing 802.11r is not supported on a Mac Book Pro OSX, how do I know, becuase Apple said so here: https://support.apple.com/en-us/HT206207

I wanted to see if OKC and SKC (Sticky Key) was supported. We did this testing in a controlled enviroment. 

 http://www.my80211.com/storage/pdf/ACTIVEEXPERT.APPLE.MAC.ROAMING.0725.2017.pdf

ENJOY!

Enjoy!

I plan to release my CWNA, CWDP and CWAP soon after I clean them up for public view.

http://www.cram.com/flashcards/cwsp-1348185 

When dealing in a multi WiFi NIC environment, especially when dealing with a single vendor, WiFi NIC information should be handy. Here is a link that you should bookmark. 

http://ark.intel.com/products/family/59484/Intel-Wi-Fi-Product

It also provides a quick and handy comparison between Intel WiFI NICs. 

In the last month or so Intel has quietly added driver release notes to their latest two driver releases, 19.60 and 19.70. What you might find interesting, Intel doesn't disclose any open issues, but they mention “Key Issues Fixed and Changes”. In other words here is what we fixed, but we wont disclose any existing problems.

I applaud Intel for giving the community and customers who support them this added information. I hope they disclose open issues in the future. 

Enjoy 

https://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000017246.html

• A vulnerability in the mesh code of Cisco Wireless LAN Controller (WLC) software could allow an unauthenticated, remote attacker to impersonate a WLC in a meshed topology.
  
  The vulnerability is due to insufficient authentication of the parent access point in a mesh configuration. An attacker could exploit this vulnerability by forcing the target system to disconnect from the correct parent access point and reconnect to a rogue access point owned by the attacker. An exploit could allow the attacker to control the traffic flowing through the impacted access point or take full control of the target system.
  
  Cisco has released software updates that address this vulnerability. Note that additional configuration is needed in addition to upgrading to a fixed release. There are no workarounds that address this vulnerability.
  
  This advisory is available at the following link:
  https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170315-wlc-mesh

Affected Products

• Vulnerable Products

  This vulnerability affects the following products running a vulnerable version of Wireless LAN Controller software and configured for meshed mode:
  

  • Cisco 8500 Series Wireless Controller
  • Cisco 5500 Series Wireless Controller
  • Cisco 2500 Series Wireless Controller 
  • Cisco Flex 7500 Series Wireless Controller 
  • Cisco Virtual Wireless Controller
  • Wireless Services Module 2 (WiSM2)

  Refer to the "Fixed Software" section of this security advisory for more information about the affected releases.

  To determine whether a WLC is configured for meshed mode, use the show ap config general command and verify that the AP mode is set to Bridge. The following example shows a WLC configured for meshed mode:
  
  

  Cisco AP Identifier.............................. 23
  Cisco AP Name.................................... ap1
  
  [...]
  AP Mode ......................................... Bridge  
  AP Role ......................................... RootAP

  [...]

  Note: Meshed mode is not enabled by default.

  Products Confirmed Not Vulnerable

  No other Cisco products are currently known to be affected by this vulnerability.
  
  The following products are not affected by this vulnerability:
  

  • Integrated controller in Cisco Catalyst 3850 Series Switch
  • Integrated controller in Cisco Catalyst 3650 Series Switch
  • Cisco Mobility Express 
  • Cisco 5760 Wireless LAN Controllers 

Workarounds

• There are no workarounds that address this vulnerability.

Fixed Software

• Cisco has released free software updates that address the vulnerability described in this advisory. Customers may only install and expect support for software versions and feature sets for which they have purchased a license. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license: 
  http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html

  Additionally, customers may only download software for which they have a valid license, procured from Cisco directly, or through a Cisco authorized reseller or partner. In most cases this will be a maintenance upgrade to software that was previously purchased. Free security software updates do not entitle customers to a new software license, additional software feature sets, or major revision upgrades.

  When considering software upgrades, customers are advised to regularly consult the advisories for Cisco products, which are available from the Cisco Security Advisories and Alerts page, to determine exposure and a complete upgrade solution.

  In all cases, customers should ensure that the devices to upgrade contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers.

  Customers Without Service Contracts

  Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco TAC:
  http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

  Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.

   

  Fixed Releases

  Customers should upgrade to an appropriate release as indicated in the following table:

   

  

   

   

NOTICE: 

THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTY OF MERCHANTABILITY. YOUR USE OF THE INFORMATION ON THE FIELD NOTICE OR MATERIALS LINKED FROM THE FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.

Revision History

Revision	Date	Comment
1.0	03-MAR-2017	Initial Public Release

Products Affected

Problem Description

CP-8821 wireless phones deployed in Wireless LAN (WLAN) infrastructures do not work properly. The issues are caused by both 8821 phone and WLAN software bugs.

Background

CP-8821 new wireless phone adoption guidelines are not followed.

Problem Symptoms

Customers that deploy the 8821 in new and established WLAN infrastructures see these issues:

• Poor voice quality
• Audio gaps
• Lost registration
• Problems with roaming
• User interface hangs/restarts 

   

Workaround/Solution

Software updates and configuration modifications are required for Unified Communications Manager, the Cisco WLAN Controller, and the 8821 Wireless Phone. While these modifications will not resolve all known issues, they do address the most critical problems. It is HIGHLY recommended that the customer becomes familiar with instructions and content of the 8821 Wireless Deployment Guide found on Cisco.com.

Unified Communications Manager
- Recommend Version 10.5(2), 11.0(1), 11.5(1), and later

Unified Survivable Remote Site Telephony (SRST)
- Recommend Version 11.0, 11.5, and later

Unified Communications Manager Express: 10.x, 11.x, and later
- Recommend Version 11.0, 11.5, and later

Hosted Collaboration Solution (HCS): 9.x, 10.x, 11.x, and later 
- Recommend Version 11.0, 11.5, and later

Wireless LAN Controller (WLC) and Access Points (APs) 
- Refer to the 8821 Wireless Deployment Guide for supported AP listings. Any AP model that is not listed in the deployment guide is not supported.

Cisco WLC and Cisco Lightweight APs
- Recommend at least Version 8.0.140.0, 8.2.141.0, or later 
- For the latest code recommendations for the AireOS based Cisco WLC, also refer to TAC Recommended AireOS Builds.

Cisco Meraki Access Points
MR18, MR24, MR26, MR32, MR34, MR42, MR52, and MR53 indoor AP platforms and the Cisco Meraki MR72 outdoor AP platform only. 

Cisco Autonomous APs
- Recommend Version 12.4(25d)JA2, 15.2(4)JB6, and 15.3(3)JD

8821 Wireless Phone
- Recommend latest Software Release 11.0(3) SR1 or later

Refer to the 8821 Wireless Deployment Guide for all settings, configurations, and troubleshooting recommendations.

These commands must be issued on all Cisco WLCs as a workaround for Cisco bug ID  CSCvd06463 - IOS AP doing AMSDU aggregation for voice traffic in queue 0 despite BA req declined by 8821:

These are the commands for 5 GHz, if Cisco 8821 on 5 GHz is used:

• config 802.11a disable network
• config 802.11a 11nSupport a-msdu tx priority all disable 
• config 802.11a enable network 

These are the commands for 2.4 GHz, if Cisco 8821 on 2.4 GHz is used:

• config 802.11b disable network
• config 802.11b 11nSupport a-msdu tx priority all disable
• config 802.11b enable network 

   

CDETS

To follow the bug ID link below and see detailed bug information, you must be a registered customer and you must be logged in.

Compliance Hold

In order to ensure successful deployment of the 8821, these actions must be taken before Sales Orders are released:

1. Perform a Wireless Network Site Survey.
2. If a partner is responsible for the installation, verify that the partner has certification for Voice over WLAN.
3. Confirm that the wireless infrastructure (WLC, APs, and so on) runs on the latest released version of the firmware.

Save 20% off any pass with our exclusive promo code: STEFANICK

https://l.feathr.co/interop-itx-george-stefanick-n

When I make changes in an effort to resolve an issue I like to take the easy approach to get the users perspective if the issue has improved. Clearly some issues are black and white in terms that the issue is fixed and resolved or not.

Other times problems require small changes in an effort to improve a solution. Because maybe you aren't sure of the fix and you need to layer (Onion approach) back on complexity to see if we get improvement. 

Read the complete blog post here:

https://community.arubanetworks.com/t5/Technology-Blog/Onion-Approach-to-wifi-troubleshooting-basics-Same-Better-or/ba-p/274757

So you want to upgrade your controllers? What better place to start then a TAC recommend list. If you're like me you will want to do your research, read the release notes, search the forums, and test the code release on a test controller before pushing to your production environment. 

Enjoy! 

https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html 

Cisco announces the end-of-sale and end-of-life dates for the Cisco Aironet Access Point Module for 802.11ac. The last day to order the affected product(s) is July 3, 2017. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers' service contract.

http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/wireless-services-module-2-wism2/eos-eol-notice-c51-738008.html?emailclick=CNSemail 

http://www.cisco.com/c/en/us/products/collateral/wireless/flex-7500-series-wireless-controllers/eos-eol-notice-c51-738009.html?emailclick=CNSemail

Since getting my hands on the AirCheck G2 I’ve had it in some of the most challenging environments you will find on earth to do WiFi. 

As I mentioned the G2 just got a whole lot better this week with release v1.1. NETSCOUT introduced 13 new features. Sit back because there is a lot more goodness to come! 

My top 3 favorite new features:

#1 Emulate user device received signal levels with custom signal level adjustments.
#3 Focus your testing by selecting which channels to scan.
#9 A Show vs. Exclude option is added for SSID Filtering, so you can view all SSIDs except the ones you specify, or view only the ones you specify. 

New Features   

#1 Emulate user device received signal levels with custom signal level adjustments.

• Settings >> 802.11 Settings >> Custom Signal Adjustments
• Adjustments will apply to signal levels but not to noise and SNR levels.
• Adjustments are applied everywhere except the Locate Access Point / Locate Client screens.
• Adjusted signal levels are shown with an * indicator: 

#2 Aruba access point names advertised in the beacons are now shown.

#3 Focus your testing by selecting which channels to scan.

•  Settings >> 802.11 Settings >> Channels and Bands
• AutoTest will still scan all channels in 2.4GHz so that the Adjacent Channel Interference 
• Test will be accurate. However, only channels selected for scanning will be listed in CCI 
• and ACI results.
• If you view channel details for a channel that is not selected for scan, AirCheck G2 will still dwell on that channel while on the channel details screen. 

#4 Access Point basic and extended supported rates are shown to identify mis-configurations that result in slow performance (Max 11n/ac rates are still shown under 802.11n/ac Capabilities as in v1.0). 

#5 AutoTest Co-Channel Interference and Adjacent Channel Interference tests: view the actual APs that were counted on each channel by touching that result. 

#6 Retry rate, a critical key performance indicator, is added to the Network and Access Point connection tests.

#7 Support for a USB headset for use in the Locate Access Point or Client audio function. These models have been tested:

•  Logitech ClearChat Comfort/USB Headset H390
•  Koss Communications USB Headset CS95-USB
•  iMicro IM320 USB Headset
  Microsoft LifeChat LX-4000 for Business 
• Plantronics Blackwire C320-M 

#8 Session and screen capture files can now be saved directly to a USB drive.

• Settings >> Manage Files. “Save to USB” button is at the bottom.
• FAT32 file format is supported. exFAT or NTFS file formats are not supported. 

 #9 A Show vs. Exclude option is added for SSID Filtering, so you can view all SSIDs except the ones you specify, or view only the ones you specify. 

• Settings >> 802.11 Settings >> SSID Filter

#10 Touch the Profile name in the display’s status bar to go right to the Profile settings. 

#11 A web proxy to facilitate Link-Live uploads of test results is added.

•  Settings >> Device Settings >> Link-Live 

#12 AirCheck G2 Manager Reports are now localized in 9 different languages.

#13 When in AirCheck G2 Manager with an AirCheck G2 connected, if you drag one or more profiles from Local Profiles to AirCheck G2 Profiles, the profile that will come up in the AirCheck G2 when it reboots is indicated with a green star. 

Cisco Wireless IP Phone 8821 Data Sheet

http://www.cisco.com/c/en/us/products/collateral/collaboration-endpoints/wireless-ip-phone-8821/datasheet-c78-737346.html

Cisco Wireless IP Phone 8821-EX Data Sheet

http://www.cisco.com/c/en/us/products/collateral/collaboration-endpoints/wireless-ip-phone-8821-ex/datasheet-c78-737347.html 

http://spectralinkplus.com/wp-content/uploads/2016/06/Cisco-Spectralink_PIVOT_HowToBuyGuide_A4_062016_SH-v3.pdf

Cisco announces the end-of-sale and end-of-life dates for the Cisco Unified Wireless IP Phones 7925G, 7925G-EX, and 7926G. The last day to order the affected product(s) is October 15, 2016. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers' service contract.

Read the official EOS and EOL:

http://www.cisco.com/c/en/us/products/collateral/collaboration-endpoints/unified-ip-phone-7900-series/eos-eol-notice-c51-737580.html?emailclick=CNSemail

 WDC session Unified Logging and Activity Tracking session, Friday 7:00-7:40 pm - 41:00 minute mark.

Read this blog post in its entirety: 

http://community.arubanetworks.com/t5/Technology-Blog/Apple-iOS-10-Beta-Sysdiagnose-Logging/ba-p/270978 

As an important reminder, due to Microsoft code signing changes, old versions of AnyConnect (pre 3.1MR13 or 4.2MR1) will no longer run on Windows platforms as of 1/1/2017. While Cisco always recommends running current versions of AnyConnect for the most recent bug fixes, it is critical that customers upgrade any Windows users prior to this date in order for AnyConnect to still be able to run on those systems.

We always recommend the latest version of AnyConnect (4.x) at the time of updating, which today would be 4.3 or the latest 4.2 MR.

3.1MR14 is currently available for customers and is unaffected by this deadline, but the 3.x release train is no longer eligible for bug fixes.

Customers must have a Plus, Apex or VPN Only license with an active support contract in order to access 4.x software releases.

http://www.cisco.com/c/dam/en/us/products/security/anyconnect-og.pdf 

Release Notes:http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect43/release/notes/b_Release_Notes_AnyConnect_4_3.html#reference_AA75AD8674C4409DBA57F2EBD9CAE3BB

Code Signing Certificates: Windows will no longer trust files with the Mark of the Web attribute that are signed with a SHA-1 code signing certificate and are timestamped after 1/1/2016." Refer to the Microsoft documentation for more details: here

• Prime AP Migration Tool Part 1: Explore the background with HA and prerequisites
• Prime AP Migration Tool Part 2: Details on how to upgrade, using the free IPTel supplied tool

Caveats, Hints and Tips 

A code upgrade is a MAJOR change in any wireless network. The following notes have been collated on the back of real world experience upgrading large sites with thousands of APs. You must work VERY cautiously on a large or critical site upgrade.

Liability Disclaimer 

We supply the tools on this website free of charge for the wireless community use. Note with all our tools the liability disclaimer – we do our best to make these tools as useful as we can, but accept no liability for their use or misuse:

https://www.iptel.com.au/terms-and-conditions-for-usage-of-provided-tools.html

AP Migration Process

There are caveats later in this blog – familiarise yourself with these – if you are unsure of what you are doing do not run this script on a live network. Practice in your lab environment until you are happy with the process.

Access the tool from the IPTel website – here’s the link: https://www.iptel.com.au/ap-migration-tool.html

You will need to make a choice when moving APs – do you upgrade the spare WLC to the new code and upgrade APs on their way over, or just do a straight move then upgrade the primary WLC and upgrade them on the way back. There’s pros and cons to each method.

At some point you need to upload the new WLC code to your controller – this can be done at any stage prior to, or after offloading all the APs.

A screen shot of the tool is shown below:

Prime AP Migration Tool – Entry Screen

The process is as follows:

• Select the ‘Move AP Script’ radio button
• Enter the ‘From’ details in the Controllers section (hostname and IP address of your current Primary WLC)
• Enter the ‘To’ details for the spare / holding platform WLC to move the APs to
• In the Access Points box, paste in a list of all your APs
• Click the generate button

This will generate a list of commands to be pasted to the WLC GUI. When pasted into the GUI, APs will have the order of their Primary controller changed – the commands will then reload the AP and it will move to the secondary platform.

Once all APs are moved, you can upgrade the primary WLC (or HA if its in HA mode) without affecting any of the APs.

When you’re ready to move the APs back to the original WLC, select the ‘Reset AP Script’ button and click the Generate button – this will generate the reverse script to return the APs back to the Primary WLC.

Pre-download

To reduce the impact of the upgrade (speed up the process), pre-download the new AP image to the APs before moving them to a WLC that uses a different code version. Note that without a pre-download, APs will have to download the correct image then reload to boot that image when you move them between WLCs with different code versions! To do a pre-download, you need to download the new code onto the WLC but don't reboot onto it. You will then be able to pre-download that code to all APs (or a single AP at a time if you want to test) either via the GUI or the CLI.

Liability Disclaimer 

We supply the tools on this website free of charge for the wireless community use. Note with all our tools the liability disclaimer – we do our best to make these tools as useful as we can, but accept no liability for their use or misuse:

https://www.iptel.com.au/terms-and-conditions-for-usage-of-provided-tools.html

This article is the first in a series dedicated to how to upgrade your Cisco WLCs within the minimum of client impact. This article provides the background and pre-requisites, with further articles detailing the process. In addition, IPTel have provided the AP migration tool to make life easy to transfer APs from one WLC to the next.

If you've not see the other two articles in this series, you can catch up with the two links below - check the caveats, hints and tips before you start any upgrades:

• Prime AP Migration Tool Part 2: Details on how to upgrade, using the free IPTel supplied tool
• Prime AP Migration Tool Part 3: Caveats, Hints and Tips on WLC code upgrades

The tool can be found on this link: https://www.iptel.com.au/ap-migration-tool.html

The bad news is that you need some spare hardware - if you have only a single controller or only a HA pair (in SSO mode) then you can’t do a seamless upgrade. 

When you upgrade the HA pair it copies the new code between the WLCs and reloads each in turn – you’re in for a 15 – 20 minute outage.

The process is even worse if you've not done a pre-upload of code to your APs prior to the WLC code upgrade – once the WLCs are operational on the new code, the APs will join, download, reload onto the new code and join again. The network is going to be unstable while this process occurs.

High Availability (HA)

Firstly, let's have a quick segway onto the issue of High Availability. If you've got one WLC and it goes offline, you're, well offline. If you happen to have a spare WLC handy AND a copy of your config, all good. You can restore the failed controller and maybe have 3 - 4 hours of downtime.

Don't have a spare onsite, and oops, don't have the recent config? You're in real trouble - it could be days or weeks until you return to service.

The HA part codes from Cisco are much cheaper than the fully licenced controllers and inherit the licence once connected - you now have completely seamless fail over (depending on the code version you're running).

That's the good news. The bad news is that you essentially have one single unit, just operating across two pieces of hardware. Make a config error on one and you've just made it on both. There's an outside chance of a bug taking both out at once, but in any case, when you do a code upgrade they will both reload.

The answer to this is a spare controller.

Spare Controller

To overcome this for sites which cannot have any interruption in service, we have developed designs and techniques. The first stage is ensuring you have a spare controller in the network. Fortunately due to Cisco licencing, you can buy the minimum priced HA unit and use this as an HA secondary; once in HA secondary mode (with SSO disabled) it will licence itself for the full number of APs – but only for 90 days (after which there’s a ‘nag’ message).

In addition to providing a holding platform during code upgrades, adding a Spare controller also adds to the overall resilience of the network. We normally configure this as the secondary controller on each AP; it can act as a secondary to multiple primary HA pairs of controllers (you need to configure this for each AP though).

Holding Platform

Once the Spare WLC is in place as the holding platform, you’re all set to be able to do seamless upgrades. The basic premise is to gradually move all APs from the current WLC (or HA pair) to the spare platform. Gradually moving the APs mean any clients will just roam when the AP disappears during the move. To reduce the impact even further, randomise the order in which APs are moved, so you only move one AP at a time in a particular area.

The Prime AP Migration tool is designed to perform just this task – work out a randomised list of APs to change their primary controller to be the spare – they are then rebooted and the AP reconnects on the spare WLC.

Liability Disclaimer 

We supply the tools on this website free of charge for the wireless community use. Note with all our tools the liability disclaimer – we do our best to make these tools as useful as we can, but accept no liability for their use or misuse:

https://www.iptel.com.au/terms-and-conditions-for-usage-of-provided-tools.html

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

Read this blog post in its entirety:

http://community.arubanetworks.com/t5/Technology-Blog/30-Random-Technical-Thoughts-by-a-WiFi-Engineer/ba-p/137033 

The 802.11 standard section 8.4 comments on reason codes and status codes. I’ve used these myself when troubleshooting frame captures. These codes provide insight to Wi-Fi related problems like stations connecting and disconnecting. Lets dive in and see what the standard says about reason and status code fields. Then lets look at real world frame captures and see these codes at work.

802.11 Standard Overview

8.4.1.7 Reason Code field 

This Reason Code field is used to indicate the reason that an unsolicited notification management frame of type Disassociation, Deauthentication, DELTS, DELBA, DLS Teardown, or Mesh Peering Close was generated. It is contained in the Mesh Channel Switch Parameters element to indicate the reason for the channel switch. It is contained in the PERR element to indicate the reason for the path error. The length of the Reason Code field is 2 octets. The Reason Code field is illustrated in Figure 8-41. 

8.4.1.9 Status Code field 

The Status Code field is used in a response management frame to indicate the success or failure of a requested operation. The length of the Status Code field is 2 octets. The Status Code field is illustrated in Figure 8-43.

Reason Code Field 

When conducting frame captures you can find the reason code in some of the management frames like the response and disassociation frames. I like how the 802.11 standard comments:  “unsolicited notification”. 

It’s unsolicited information whereby radios can provide connection information. 

Example: Disassociation frame with reason code 1. This radio is informing the other radio it’s disassociating for unspecified reasons.

Read this blog post in its entirety here:

http://community.arubanetworks.com/t5/Technology-Blog/802-11-Reason-Codes-and-Status-Codes/ba-p/257893

The conversation usually goes something like this: What does Wi-Fi stand for?

Is Wi-Fi an acronym for something? Who came up with the term Wi-Fi? Who owns the name Wi-Fi? Is it WiFi or Wi-Fi?"

When I respond that Wi-Fi is a made up word I get the stare, usually followed by, "really?"

I think the biggest misunderstanding or assumption is many folks think Wi-Fi means “Wireless Fidelity”. This is almost always the response I get when I ask, "what do you think it means?"

Another point of interest is the proper term is Wi-Fi with the hyphen. While many of us, myself included, use the term WiFi that would not be the correct registered trademark. Wi-Fi is a registered trademark of the Wi-Fi Alliance. Here is a link to their brands.

http://www.wi-fi.org/who-we-are/our-brands

Read the entire blog post here: 
http://community.arubanetworks.com/t5/Technology-Blog/What-does-Wi-Fi-stand-for/ba-p/256914 

Read the entire blog post here: 

http://community.arubanetworks.com/t5/Technology-Blog/802-11-TIM-and-DTIM-Information-Elements/ba-p/256997 

Traffic Indication Map (TIM) - 

After reviewing what the 802.11 standard says about TIM. Lets discuss in real world terms what a TIM is and how it works. 

You will specifically find TIM in a management frame called a beacon. A beacon is triggered by default on an access point every 102us. Think of a beacon as a network advertisement. The beacon advertises specific <BSSID> wireless network information such as supported PHY rates, security protocols, supported QoS/WMM, vendor specific information and much much more. Included in the beacon is a TIM information element. 

Example: BEACON WITH TIM

Delivery Traffic Indication Map (DTIM) - 

After reviewing what the 802.11 standard says about DTIM. Lets discuss in real world terms what a DTIM is and how it works. 

You will specifically find DTIM in a management frame called a beacon under the TIM information element. DTIM is to broadcast / multicast traffic as TIM is to unicast traffic.

Under the TIM you will see DTIM count and DTIM period. 

Example: DTIM COUNT / DTIM PERIOD 

https://supportforums.cisco.com/discussion/12755726/80mr3-beta-availability 

8.0.122.x Available - 8.0MR3 Beta

We are pleased to announce the availability of 80MR3 beta (Upcoming 8.0.130.0) for general testing

If you are interested in participating on the beta program, please send email to wnbu-mrbeta@cisco.com with your CCO username, network size and planned usage scenario

Resolved List - 8.0.122.39

<continue.....>

Example: DFS event is under way. The access point is sending an action frame to the cell to announce a channel change.

Category - 0 Spectrum Management
Action - 4 Channel Switch Announcement
Element - New Channel 64

Example: In this example TSPEC. Where a client is requesting a TS <traffic stream>.

Category - 17 WNM
Action - 0 ADDTS Reuquest
Status Code: 0 Admission Accepted

 * Note I believe Omnipeek is decoding this wrong. I believe the category code should read WNM.

Click here for the entire blog post:
http://community.arubanetworks.com/t5/Technology-Blog/802-11-Action-Frames/ba-p/256811