Sunday, December 1, 2019
Tuesday, November 19, 2019
When setting up new Cisco WLAN controllers, I find it easier to set one up, get it working properly and then copy the configuration off of it and put it on another WLC and change what needs to be changed in order for it to become a backup controller. You know – the IP addresses need to change, hostname, and then set up the mobility configuration. Everything else as well – I’m sure I am forgetting to mention something.
My most recent pair of WLCs threw a curve ball. I set up the first 3504 WLC via the CLI while on the bench with a very basic config, then copied my base config file to it via TFTP. Everything went well, and the system rebooted. After relogging in via CLI, I tested the Service Port’s IP config with a patch cable to my ethernet port on my laptop. I tried to browse to it, and nothing happened.
I pinged the WLC, and the service port responded. I then SSH’d into the service port and it worked perfectly. But no web browsing!
I went home and came back to work the next day, and I could browse to the WLC. Nothing changed. I thought that was a bit strange.
After getting the WLC all setup like I wanted, I copied the controller’s config off the WLC via TFTP and began to set up the backup controller’s configuration. Everything was successful, and I changed what needed to be changed via CLI, saved the config and rebooted it. When it came up, there was no browsing – same as the first WLC. I looked at the system time, and it was set properly, however it was not connected to the internet and the NTP configuration was not in use.
After asking a few friends and googling around, I started trying different things one by one. I found one post where someone had to regenerate the webauth certificate (for something else), and I also found in that same post there was a command to regenerate the webadmin certificate as well.
I ran the “config certificate generate webadmin” command and executed quickly, however it did not appear to do anything. I saved the config and typed “reset system” and it rebooted. When it came back up, I could browse to the WLC.
I honestly have absolutely no idea why this worked, but it did. I do not know why the first WLC worked the next day, but not the first day when I configured it. If my friend Sam Clement’s theory was correct, it was the NTP setting – and I suspect it had not timed out. My timeout was set to one day, and I do not know if more than 24 hours had passed when I checked the first controller again and it magically worked.
I hope this helps someone, since when I searched, I found no references to anyone else having this same issue.
Thursday, October 17, 2019
Near the bottom, you will see “Charge battery via PoE”. It will likely not be enabled if you have determined that your EtherScope nXG is not charging via PoE. Simply tap that with your finger and enable it, then press the “back” triangle in the lower left, under the word “Management”.
Now that you have pressed the “back” arrow button, you should be at the screen below:
Tuesday, September 3, 2019
There is a lot of confusion and false expectations regarding 802.11ax flavored Wi-Fi these days. Articles that compare 802.11ax to switches sets a dangerous president and leads to confusion in the marketplace as to what 802.11ax is and what it can do.
Take this article as an example:
"802.11AX TO THE RESCUE"
"With 802.11ax, MU-MIMO has been enhanced to support uplink traffic, from the client to the AP, and will support up to eight clients at a time (802.11ac allowed for eight, but no one implemented more than four). This doubles the number of devices to which an AP can talk, and because traffic is supported in both directions, clients can transmit simultaneously back to the AP, similar to how an eight-port switch would work on a wired network."
Here is where the confusion lies: A client cannot transmit simultaneously back to the AP while receiving a frame from the AP - meaning, full duplex. That is not in any 802.11ax draft amendment. If this was possible, this is still not similar to how an eight port switch works. Ethernet switching allows clients to send traffic on the wire whenever they want because the connection to the network is not a shared medium. Wi-Fi is an unbounded, shared medium in unlicensed frequency band.
"Wider channels can support even more sub-channels. An 80 MHz wide channel can support up to 37 clients at a time. Like MU-MIMO, OFDMA supports downlink traffic, from the AP to the clients, and uplink traffic, from the clients to the AP. If MU-MIMO is a high speed 8-port switch, then OFDMA is a lower speed 37 port switch."
Here is where the confusion lies: A client cannot transmit simultaneously back to the AP while receiving a frame from the AP - meaning, full duplex. That is not in any 802.11ax draft amendment. If this was possible, this is still not similar to how a thirty seven port switch works. Ethernet switching allows clients to send traffic on the wire whenever they want because the connection to the network is not a shared medium. Wi-Fi is an unbounded, shared medium in unlicensed frequency band. Also, an 80 MHz channel is simply the aggregation of four 20 MHz channels into one channel. If there are twenty 20 MHz channels and five 80 MHz channels, they are using the same spectrum. Currently, date frames are transmitted consecutively using the entire channel. For example, if a client is connected to a 20 MHz wide channel and sends data, the entire channel is taken up and then the AP and clients take turns, one at a time, sending data on the channel. This will continue until all of the legacy 20 MHz client devices (802.11a, 802.11n, 802.11ac) are removed from the network. This includes the WLAN's access points and client devices, and also neighboring WLANs that are within earshot of the 802.11ax network. It is not uncommon to do a survey of an existing building and see 700+ neighboring access points. This number does not include the client devices on those 700+ access points.
"This has led to designs with more lower-bandwidth channels to reduce interference. 40 MHz-wide channels are the norm in office deployments, with 20 MHz wide channels used in high density offices or in environments where there are fewer channels available because of noisy RF neighborhoods. BSS coloring allows the network to assign a “color” tag to a channel and reduce the threshold for interference. Network performance is improved because APs on the same channel can be closer together and still transmit at the same time as long as they are different colors. Because we can have fewer channels, it may also be possible for organizations to use wider channels, such as 80Mhz channels in some or all of their network."
Here is where the confusion lies: The previous paragraph states "This has led to designs with more lower-bandwidth channels to reduce interference. 40 MHz-wide channels are the norm in office deployments, with 20 MHz wide channels used in high density offices or in environments where there are fewer channels available because of noisy RF neighborhoods." Enterprise Wi-Fi networks should usually be set to 20 MHz channel plans because of the density of access points due to the data/voice/RTLS/higher density design and the noisy RF neighborhoods of the facilities. 80 Mhz channels are not usually used in Enterprise environments, therefore that does not apply.
"If MU-MIMO and OFDMA make the wireless network behave more like a switched environment, then BSS coloring adds switching capacity to the network."
There is a lot of confusion regarding 802.11ax - especially with this subject. MU-MIMO and OFDMA does not make the wireless network behave like a switched environment, therefore that statement is not accurate. Switching uses CSMA/CD, (carrier sense multiple access with collision detection) and Wi-Fi uses CSMA/CA, which is carrier sense multiple access with collision avoidance. The two are massively different than each other - CD can sense a collision, which usually does not happen now that we plug hosts into switches and the collision domain exists between the host and the switch. Collision Avoidance is still the same. The medium is still in a shared spectrum with all those cordless phones, video cameras neighboring networks and everything else I have forgotten to mention. None of those things exist in the copper cabling between a host and a switch with CSMA/CD. There is no way to "detect" a collision with Collision Avoidance - if the station did not receive an acknowledgement for the unicast packet it transmitted, it will retransmit the packet, assuming the receiver did not receive it.
"With MU-MIMO, an AP can behave like a high speed, 600 Mbps per client 8 port switch, great for large file transfers and high-performance clients. OFDMA allows an AP to behave like a lower speed, ~25 Mbps per client 37 port switch, good for normal network use and voice and video streaming. An AP can switch back and forth between these two modes every transmit cycle as the needs of the clients change. We don’t have a dedicated connection for each device like you would in a wired network, but we are able to adjust the amount of network capacity allocated to each device depending on need, which is something wired networking can’t do. Although we don’t have a full-duplex switch, we effectively have time-division duplexing that emulates full duplex over shared/half-duplex mediums. In the end, we gain a lot of the benefits of switching and wireless and 802.11ax is likely to be the point where we think of Wi-Fi less like an old bridged network and more like a high-speed modern switched network."
Even more confusion: An AP cannot behave like a high speed, 600 Mbps per client 8 port switch. Switches use CSMA/CD, and 802.11ax will use CSMA/CA. A switch is full duplex - meaning simultaneous transmit and receive to a client, as long as the port negotiates properly. 802.11ax is not full duplex. Switches commonly use gigabit speeds on every host port, and 802.11ax does not equal an eight port (or 37 port) 1000 Mbps full duplex (no collision domain) Ethernet switch. We do not "gain a lot of the benefits of switching" with 802.11ax. We do not have collision detection, we still share the frequency/channel with all the other wireless devices on that frequency, and we do not have full duplex (simultaneous) transmit and receive to a client.
Wednesday, August 21, 2019
NetAlly's (formerly NetScout) AirCheck G2 gets a facelift with version 4.0 firmware
We learned at Mobility Field Day 4 that NetAlly has been working on version 4.0 of the AirCheck G2 firmware, so here is a quick post on how I upgraded mine. I decided to take the “offline” approach because sometimes you don’t have an Internet connection to get the job done. I know that seems hard to believe, but I once worked at a place where no USB anything, no phones, no cameras, no nothing was allowed through the checkpoint.
So here goes:
Download the AirCheck G2 Manager v3.1.485 software from the support page at NetAlly.com (http://www.netally.com/support/downloads), and install it on a PC. (I installed on Windows without issue)
Note: When you get to the website, scroll down until you see this, and select the Aircheck G2.
When AirCheck G2 is selected, these files will show up: I downloaded all of them into the same folder.
For whatever reason, I could not download the MAC Prefix File, so I scraped it into a Notepad and saved it as a .txt file.
Download AirCheck G2 v4.0 firmware (https://www.netally.com/support/), and save it also. I put mine in the same folder. The firmware is the ACFX file.
Launch the newly installed AirCheck G2 Manager v3.1.485.
Attach your AirCheck G2 unit to your computer using the micro USB cable.
In AirCheck G2 Manager v3.1.485 go to the Device Info screen, select the “Update AirCheck G2 Firmware…” button.
Follow the prompts to upgrade your unit to the v4.0 firmware. The unit reboots and takes several minutes, so do not do this step if you don’t have time to do it.
Next, I uploaded the vendor OUI text file I created. This was extremely simple.
Now I am going to see if everything “added” to the firmware works as described:
1. 802.11ax Visibility: I have an 802.11ax client on the network and I will see if the AirCheck G2 sees it: (and it does)
How did I take that screenshot from my AirCheck G2? This is on page 104 of the manual: (I didn’t know how to do it either)
I used the AirCheck G2 Manager to get the screenshot since I am using the non-link-live way of upgrading my AirCheck G2 today. I simply transferred them to my PC – it was very painless to accomplish.
Identify 802.11ax Networks – Sadly, I do not have an 802.11ax access point to verify this – however I could clearly see my 802.11ax laptop was identified.
2. Combined Utilization View: This option allows the combination of 802.11 utilization and non-802.11 utilization into a single total utilization graph that will include 802.11a/b/g/n/ac/ax traffic and non-802.11 traffic.
Here is how to get there to make the change: (I made the change back and forth but did not have an environment to see any results)
3. iPerf Test Results Uploaded to Link-Live:
In order to get to the iPerf test function, you first need to connect the G2 to an AP or Network, run a test and when complete, look at the bottom of the screen for “Tests”.
If you use the NetAlly Test accessory, it should show up in the list. If you don’t know what I am referring to, look at this link: https://www.netally.com/products/testaccessory/
I use the WLANPi iPerf server (available here: http://www.wlanpi.com/ and I had to enter in the IP address of my device. I ran the iPerf test just fine, and it did upload to Link-Live, however it did not end up in my inbox like all the other tests I ran. I am not sure if this is because I am using the wlanpi instead of the NetAlly device.
Overall, the new version 4.0 does what it says it does. I would like to see the iPerf end up in my inbox automagically in a future release, or possibly some documentation on how to make it happen.
Monday, July 15, 2019
Ekahau users that use the Sidekick have probably discovered that the Sidekick “hears” better than other devices? How much better, you ask?
Since I do a lot of validation surveys, I decided to do a comparison between four devices. The 5 GHz Vocera “communicator” badge that is deployed quite a bit in Healthcare, the “Netscout” AirCheck G2 (in parenthesis because I heard that Netscout doesn’t own that product anymore though the name is still on the box), my handy dandy Samsung Galaxy S7 Edge (that just so happens to be the platform used by a company that deploys Google Glasses), and my trusty Sidekick.
My main concern was “what is my Vocera offset” for doing surveys to determine if the WLAN is voice quality. So, we took two Vocera badges and put them side by side, and during our testing, averaged the two into one measurement. I must say this was easy, since the Vocera badges usually agreed with each other within one dB.
We tried not to skew the results in any way. We didn’t look at previous results during the testing. We didn’t look at other results and compare while testing. We simply walked through a medical office building and randomly stopped in areas and took readings. This was intentional, as we didn’t want to add “intelligence” into the equation. We even took measurements in the basement, where coverage was minimal. When complete, we added them up and divided by the number of readings. Very simple.
Sometimes we throw out “highs and lows”, and average the rest.
When using the data we gathered, not tossing out the highs and lows, our offsets came out like this:
Vocera -11.66 db
AirCheck G2 -13.44 dB
Galaxy S7 Edge -13.66 dB
When using the data we gathered, tossing out one high and one low, our offsets came out like this:
Vocera -12.00 db
AirCheck G2 -13.14 dB
Galaxy S7 Edge -13.28 dB
Moving forward, I feel as though a 12 dB offset can be used in my environment when looking at the WLAN surveys with Vocera communicators in mind.
Actual readings walking a floor of a medical office building:
Ch: Vocera G2 S7 Sidekick
44 -46 -49 -55 -40
44 -77 -75 -76 -64
64 -61 -56 -56 -46
56 -69 -74 -76 -55
52 -68 -69 -74 -59
36 -73 -74 -75 -62
161 -68 -66 -60 -53
36 -70 -79 -76 -59
48 -78 -84 -90 -67
dB Difference between each device and SK
Ch: Vocera G2 S7 Sidekick (original dB reading)
44 6 9 15 -40
44 13 11 12 -64
64 15 10 10 -46
56 14 19 11 -55
52 9 10 15 -59
36 11 12 13 -62
161 15 13 7 -53
36 11 20 17 -59
48 11 17 23 -67
Monday, June 3, 2019
Many times I get floor plans that are not the color that I prefer. I love black and white floor plans – I like to survey with black and white, plan when them in black and white, and if I need to upload them into a NMS, such as Cisco Prime, I fell they look much nicer as well. I do this because I use colors for the heat maps in Ekahau Pro, and I feel this is a much cleaner look. But how do we get them into B&W without spending a lot of time on them?
I wanted to share how I convert my plans to B&W when I get a colored PDF, such as the snippet of the floor plan below I received recently. This was a PDF, and as you can see, it has a lot of red walls on there. Using the Microsoft Snipping Tool, I snipped the floor plan from the drawing and I sanitized it quickly, removing names, etc, by using the “Custom Pen” and selecting the color white. It takes a few minutes to figure out how to do this, but when you do, it works well. For me it does, anyway.
Next, the floor plan needs to be saved. I save it as a .jpg file, then close it. Now I open it in Microsoft Paint, and then save it as a monochrome bitmap. See below:
Now the floor plan is saved in black and white. I close Microsoft Paint and then reopen the file again in Microsoft Paint, saving it as a .jpg. I do this last step because I sometimes find it doesn’t upload properly into Cisco Prime.
This only takes a few minutes and is well worth in if you want clean black and white floor plans without spending hours and hours on them, or spending a lot of money of software that will do it for you. There is a slight degradation on some floor plans, so you’ll have to see if this is good enough for you.