The test

I used one Zebra TC53 and changed only two things: the Android version (11 or 14) and what the device was doing (a regular shopping app or a VoIP call). That gave me four scenarios:

• Android 11 using a regular shopping app
• Android 11 on a VoIP call
• Android 14 using a regular shopping app
• Android 14 on a VoIP call

Everything else stayed the same:

• Device: the exact same Zebra TC53
• Location: the exact same grocery store, which has high AP density
• Path: I walked the exact same path every time
• Applications: the exact same apps every time
• Network: WPA3 with EAP-TLS, and 802.11k/r/v enabled on 5 GHz

Each run is a capture of the client’s uplink frames, so the chart shows the client’s RSSI over time, the probing it did before roaming, and every roam event. All device and AP identifiers are anonymized.

Explore the data

Use the dropdown to switch between the four scenarios. Hover over the chart to inspect individual samples, probes and roams. If the embed doesn’t work for you, open it in its own tab, or skip down to the screenshots in the appendix.

What I saw

Android 11, shopping app

This one looks like a textbook roam. Twelve roams in about 220 seconds, all 5 GHz to 5 GHz, and every one used 802.11r with a reassociation. No disassociations and no deauths. The capture shows the Fast Transition authentication frame within two seconds on every roam.

The client was also very active before each roam. The probes column shows between 79 and 103 probes per roam, around 90 on average.

Android 14, shopping app

Same clean pattern: every roam was 5 GHz to 5 GHz, with 11r and a reassociation, and no disassociations or deauths. The difference is how many times it roamed. I got eight roams in about 232 seconds, compared with twelve in about 220 seconds on Android 11, walking the same path. The probe counts were lower too, between 64 and 84 per roam, around 74 on average.

Android 14, VoIP call

Still clean. All seven roams used 11r with a reassociation, with no disassociations or deauths. Probing dropped again, between 49 and 79 per roam, around 60 on average. There was also one little ping-pong: the client went from ap-4 to ap-5 and then back to ap-4 about 14 seconds later before moving on to ap-6.

The signal was a little lower at the moment of the roam on this one. The median RSSI in the three seconds before each roam averaged about -69 dBm, compared with about -64 dBm for the Android 14 shopping app and about -61 dBm for the Android 11 shopping app.

Android 11, VoIP call

This is the one that stands out. Only three roams in about 163 seconds, and none of them used 11r. No Fast Transition and no reassociation. Instead, every roam shows a deauth. The client also barely probed: one or two probes per roam, compared with 50 to 100 in the other three runs.

The deauths here aren’t a roam in the way we normally think of one. The client was no longer able to pass traffic on its WiFi connection, so the OS forcibly disconnected it. The “roam” you see is the device rediscovering the network and connecting again.

It also stayed on an AP for a long time while the signal got bad. The RSSI dropped to -86 dBm at the lowest point, and the first roam happened with the signal around -84 dBm. For comparison, the lowest RSSI in the Android 11 shopping run was -71 dBm.

Why would a VoIP call make the device so reluctant to roam? The main theory is that the call itself is influencing the device not to roam, because it suspects a roam will interrupt the call. My guess is that this is old logic from when networks were designed for coverage and didn’t have fast roaming mechanisms like 802.11r. That’s a theory, not something this test proves, but it fits what the data shows: the client held on to a weak AP until the connection broke.

Takeaways

• The infrastructure was identical, but the roaming wasn’t. 11k/r/v was enabled, but it was only used on three of the four runs. Having 802.11r turned on doesn’t guarantee the client will use it for every app on every OS version.
• The app matters as much as the OS. Android 11 roamed cleanly with the shopping app and very differently on the VoIP call. If I had only tested one app, I would have told you the wrong story about Android 11.
• Test with the apps your users really run. A roam that looks great with a web browser or a shopping app doesn’t tell you anything about voice. The VoIP call is the scenario where a slow or sticky roam hurts the most, and it’s the one that has to be tested.
• Look at the frames. The capture is what shows whether a roam was a Fast Transition with a reassociation or a forced disconnect followed by a full reconnect, which is a very different experience for the client.

Keep in mind this is one device, one store and one walk for each scenario, so treat it as a data point and not a rule. If you’ve seen the same on other devices or OS versions, I’d like to hear about it.

Questions or comments? Find me on LinkedIn

Appendix: the four runs

If the interactive version above doesn’t work for you, here are the four runs as images. Each one shows the client’s RSSI over time, the probe-start markers and the roam events, with the roam table underneath.

Android 11, shopping app

Android 11, VoIP call

Android 14, shopping app

Android 14, VoIP call

2. Grab any controller that is running the same AOS version and has the same kind of licenses (AP, PEF, RFP, etc) and console into it

3. Wipe the controller by doing a write erase (Note: do not do a write erase all because it will wipe out your licenses)

4. Go through the setup wizard a day just hit enter on everything (besides putting on an ipv6 address as that actually requires some input) and give generic administration and enable password and reboot

5. Login to your now “clean” controller, do a config terminal and paste in your script

6. Check the boot file of the controller by doing a show boot (it should be defult.cfg) and do a write memory

7. Insert a USB into the controller. Verify you can see its contents by doing a dir usb: partition [0|1]

8. Copy the configuration from the controller to the USB drive by doing a copy flash: default.cfg usb: partition 1 <filename>.cfg (adjust the filename from flash or USB partition if yours is different)

9. Take your new configuration file and tftp it to the controller you wish to wipe using copy tftp: <iPhone address> <filename> flash: <filename>

10. Verify it was successfully copied by doing a dir

11. Now edit the boot file of the controller by doing a boot config-file <filename>

12. Verify that it is now the boot file by doing a show boot

13. Reload the controller by doing a reload (if it asks you to save the configuration, select NO)

14. The controller will now boot up using the new configuration file.

15. Login to the controller, do an enable then do a boot config-file default.cfg and then a write memory

Done!

This is for Ekahau and Aruba Networking products. I have also already created a training video for the on-site technicians on how to use and configure ESS, as well as the survey process. This is basically a checklist for the remote WLAN engineer that is reviewing the survey and making decisions. I had already developed this for the project, so I thought I might as well modify it and share it with the rest of the WLAN community for anyone else that may find themselves in a similar situation.

First is a flowchart for quick reference. Then below it is a more detailed overview of the items. Enjoy!

RF Survey Checklist

1. Have onsite technician send you a screen capture of how their channels are configured

2. Verify with technician that they are on the latest version of Ekahau

3. Verify all APs are up and functioning

4. Verify AP groups that APs are currently in and change the power in the ARM profiles to the following: ***pre-determined EIRP values***

5. Set all ARM profiles to maintain

6. Have technician start first run

7. Once survey file is received, set ARM profiles back to single band

8. Check that survey paths are not too far apart by setting Options > Signal Prediction: Off and verifying that there are no holes between survey paths

9. Double check channel configuration and # of NICs using RTFM and Survey tab

You can see the recorded information to verify that the correct channels were confirmed per NIC. Big red flags is seeing whole UNII bands missing or missing a radio in the Access Points tab on the survey. Double check what they are seeing in this view vs the “show ap active” from the controller to make sure we are seeing SSIDs on the channels the APs are broadcasting on. If the channel configuration was not correct, the onsite resource HAS to re-walk the site.

10. Remove survey paths from view

11. Filter signal strength view to only include your APs

12. Start identifying coverage gaps and moving APs to the next power group as needed.

Main 3 groups:

Low-power

a xx dBm

g xx dBm

Med-power

a xx dBm

g xx dBm

High-power

a xx dBm

g xx dBm

Groups can have custom power levels if needed. Choose an unused AP group that you want those APs in that need non-standard power levels and edit its ARM profile. Example:

configure terminal
rf arm-profile "New-power-g"
  max-tx-power xx
  min-tx-power xx

Try to keep similar power levels for all APs on a floor – avoid situations where you have some APs transmitting at higher power levels (> or = 15 dBm EIRP) and some other transmitting at lower power levels (< or = 6 dBm) on the same floor

13. 5 GHz is using 40 MHz channels by default, based on regulatory domain + density of APs, determine whether it needs to be moved to 20 MHz. This is edited in the ARM profiles with the command “40MHz-allowed-bands-none” and needs to be done on all “a” ARM profiles.

14. Need to try achieve at least xx signal strength and xx SNR on both bands. Use best judgement on (1) How to achieve this (2) If it is plausible to achieve this (3) If it makes sense to achieve this – particularly on 2.4, you want to balance CCI with SNR/RSSI requirements.

15. If seeing an excessive amount of 2.4 coverage, consider turning off 2.4 radios. This outlines a good process:

https://www.ekahau.com/blog/2016/09/27/guest-blog-using-ekahau-site-survey-to-create-a-2-4-ghz-radio-plan/Once last change is made, wait 10 minutes, set ARM back to maintain, and clear technician for another run.

16. Repeat process until surveying is complete

17. Document any outstanding issues. Examples of issues:

1. Multiple adjacent APs on the same channel
2. High co-channel interference
3. Large coverage areas for single APs
4. Areas that don’t meet required signal strength and/or SNR
5. Walls with higher-than-expected attenuation

18. Once complete, take ARM out of maintain

19. Name all surveys as [SITECODE]_Survey_v1, v2, etc with last file having a _Final

ap provisioning-profile "default"
!
ap provisioning-profile "no-usb"
usb-power-mode disable
ap-poe-power-optimization enabled

ap-group "Warehouse-Lab"
virtual-ap "TEST"
dot11a-radio-profile "Warehouse-Lab-ARM-a"
dot11g-radio-profile "Warehouse-Lab-ARM-g"
ap-system-profile "BuildingProfile"
provisioning-profile "no-usb"

BLE scanner (android app “BLE Scanner”) next to the AP and picking up no signal

(Test) # show ap database

AP Database
-----------
Name               Group          AP Type  IP Address   Status          Flags  Switch IP    Standby IP
----               -----          -------  ----------   ------          -----  ---------    ----------
40:e3:d6:c5:8a:14  Warehouse-Lab  225      10.42.68.20  Up 23h:42m:20s  2      10.42.68.10  0.0.0.0

Flags: U = Unprovisioned; N = Duplicate name; G = No such group; L = Unlicensed
I = Inactive; D = Dirty or no config; E = Regulatory Domain Mismatch
X = Maintenance Mode; P = PPPoE AP; B = Built-in AP; s = LACP striping
R = Remote AP; R- = Remote AP requires Auth; C = Cellular RAP;
c = CERT-based RAP; 1 = 802.1x authenticated AP; 2 = Using IKE version 2
u = Custom-Cert RAP; S = Standby-mode AP; J = USB cert at AP
i = Indoor; o = Outdoor
M = Mesh node; Y = Mesh Recovery

Total APs:1

One AP up in the database

(Test) #show ap debug ble-table ap-name 40:e3:d6:c5:8a:14
No AP found with ap_name 40:e3:d6:c5:8a:14

Controller returning error on BLE command since it has no BLE turned on (USB port turned off)

Configure to AP provisioning profile back to the default (enabling USB port)

(Test) #configure t
Enter Configuration commands, one per line. End with CNTL/Z

(Test) (config) #ap-group Warehouse-Lab
(Test) (AP group "Warehouse-Lab") #provisioning-profile "default"
(Test) (AP group "Warehouse-Lab") #end
(Test) #write mem
Saving Configuration...

Configuration Saved.

After <1min I see something pop up on my BLE scanner with a strong signal

Issue same ap debug command to see BLE table

(Test) #show ap debug ble-table ap-name 40:e3:d6:c5:8a:14

BLE Device Table
----------------
MAC                HW_Type    FW_Ver        Flags   Status  Batt(%)  RSSI  Major#  Minor#  UUID                                  Tx_Power  Last Update  Uptime
---                -------    ------        -----   ------  -------  ----  ------  ------  ----                                  --------  -----------  ------
88:c2:55:ca:cf:3b  LS-BT1USB  OAD B 1.1-25  0x0083  LIA     USB      ---    0       0       4152554E-F99B-4A3B-86D0-947070693A78  14        18s          2m:20s

Total beacons:1

APB UI:[0/NO_UPGRADE_REQD]:65535(0xffff) blks:0/0 rep:0  total:0(0x0)
APB UI:upg_b_status-next:0x00/ooo:0x00/next2:0x00/upg_b:0x00/allrx:0x00/oooBlk:0x00/oooBlk:0x00/oooBlk:0x00
APB UI:upg_b_status_errs-inv_upg:0x00/inv_cmd:0x00/inv_op:0x00/buf_tl:0x00/good:0x00
APB UI:acks/ka-From APB:0x00/0x00 From app:0x00,0x00/0x00
APB UI Clock:Start:1970-01-01 00:00:00  End:1970-01-01 00:00:00  Current:2017-04-04 11:58:52
Note: Battery level for LS-BT1USB devices is indicated as USB.
Note: Uptime is shown as Days hour:minute:second.
Note: Last Update is time in seconds since last heard update.
Status Flags:L:AP's local beacon; I:iBeacon; A: Aruba Beacon; H: Aruba HiPower Beacon
:U:Image Upgrade Pending

We can now capture the beacon mac address and any other needed information

Go back and put on the “no-usb” provisioning profile

(Test) #configure t
Enter Configuration commands, one per line. End with CNTL/Z

(Test) (config) #ap-group Warehouse-Lab
(Test) (AP group "Warehouse-Lab") #provisioning-profile "no-usb"
(Test) (AP group "Warehouse-Lab") #end
(Test) #write mem
Saving Configuration...

Configuration Saved.

Verify the BLE beacon is off again by checking BLE scanner and issuing BLE table command

(Test) #show ap debug ble-table ap-name 40:e3:d6:c5:8a:14
No AP found with ap_name 40:e3:d6:c5:8a:14

https://youtu.be/1sbHIb4Cn3U

http://www.ekahau.com/wifidesign/blog/2016/09/27/guest-blog-using-ekahau-site-survey-to-create-a-2-4-ghz-radio-plan/

Once you paste from :loop to goto loop into notepad and save as a .bat file, you will see this little icon:

Double-click that and it will open up your command line and it will look like this:

If you’ve been working in WiFi for at least a little while, then you should know what most of these mean. Really important ones to pay attention to are BSSID (mac address of the radio of the AP you are connecting to) and Signal (received signal strength from AP).

As you can see, the signal strength is in a percentage. If you want to convert this percentage to dBm, use the following formula (quality=Signal %):

quality = 2 * (dBm + 100) where dBm: [-100 to -50]

dBm = (quality / 2) – 100 where quality: [0 to 100]

So a 50% would be a -75 dBm. A 70% would be -65 dBm. 100% is -50 dBm or better. Those are the markers I keep in my head when looking at it.

This is great for real time monitoring of how your client is behaving, but what if you want to record the output? Maybe you want to save the output in a text file? Well, my good WiFi buddy, you are in luck. You would then edit the batch file to look like this:

:loop
netsh WLAN show interfaces >>WLANstat.txt
timeout /t 5
goto loop

You can replace “WLANstat” with whatever you want to name the file.

Now when you run it, the output in the command line will look like this:

Now you’re probably saying “What the heck, Matt?!? Now it’s not showing me any of the statistics! What a dumb blog.”

Take a chill pill, friend, and look at your desktop. Notice anything different? Like maybe a text file that wasn’t there before? You should see a text file appear after you ran the batch file:

Open the text file and now there is the output:

Starting to trust me yet?

OK, so now we have our output being saved in a text file to review later. We’re done here, right? Wrong, good sir, wrong. Wouldn’t it be nice to have some sort of timeline to reference? It would, right? That’s what I thought as well. So, after an hour or so of furious googling, playing, scripting, cursing, googling more, scripting more, cursing more, and having a beer I found a way to get the timestamp in there. Now I am posting it here to hopefully help my WiFi brethren not have to endure what I did.

Edit your batch file to now look like this (by the way, Notepad++ is great for this because you can just right click the file then click “Edit in Notepad++”):

:loop
set time_hh=%time:~0,2%
if %time_hh% lss 10 (set time_hh=0%time:~1,1%)
set time_mn=%time:~3,2%
set time_ss=%time:~6,2%
set time_ms=%time:~9,2%

echo %time_hh%:%time_mn%:%time_ss%.%time_ms% >> WLANstat_%date:~-4,4%%date:~-7,2%%date:~-10,2%.txt
netsh WLAN show interfaces >>WLANstat_%date:~-4,4%%date:~-7,2%%date:~-10,2%.txt
timeout /t 5
goto loop

The string after the filename will append the date in the filename…..just for extra awesomeness….

Now when you run the batch file, the output in the command line should look like this:

Now you should see a text file appear on your desktop with the date in the filename (YearDayMonth – you can play with the string if you want this different):

When you open the text file, you should see the time above each output (Hour:Minute:Second.Millisecond – you can delete the “set time_ms” line if you don’t want the milliseconds):

So, if you want to document the roaming behavior and perceived signal strength of a Windows client on the network without having to login to the network and look through logs, just open the batch file and walk around and close it when you are done. It’s super quick and easy and gives you some pretty valuable information.

Comment below or tweet me @mattbfrederick with any feedback/questions.

Thanks for reading!

Edit: I found John’s original blog post on this:

http://wifijohnny.blogspot.com/2016/04/windows-wlan-troubleshooting-with.html

1. Create a script that can be copied and pasted into a controller

hostname ZaphodBeeblebrox
!
enable bypass
!
banner motd ~
"NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE"
"This is a private network device. If you are not authorized to"
"access this device, disconnect at once! Actual or attempted use,"
"access, examination, or configuration change by an unauthorized"
"person external to the Corporation will result in criminal and civil"
"prosecution to the fullest extent of the law. Unauthorized login"
"attempts by internal personnel will be reported immediately to the"
"violator's management and may result in disciplinary action."
"NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE"
~
!
clock timezone UTC 0
!
license profile centralized-licensing-enable
!
ipv6 enable
!
ipv6 mld
!
vlan 2 Native
vlan 42 MGMT
!

interface vlan 850
ip address 10.10.10.42 255.255.255.0
!
Interface Loopback
no ip address
!
ip default-gateway 10.10.10.1
!
interface gigabitethernet 0/0/2
description "Link to SomeSwitch"
trusted
ip access-group "mcast_opt" session
switchport mode trunk
switchport trunk native vlan 2
switchport trunk allowed vlan 42
!
interface gigabitethernet 0/0/0
description "Undefined"
trusted
ip access-group "mcast_opt" session
switchport mode trunk
switchport trunk native vlan 2
switchport trunk allowed vlan 42
!
interface vlan 1
no ip address
shutdown
!
syslocation "Magrathea"
syscontact "DentArthurDent"
snmp-server community "KnowWhereYoureTowelIs"
!
mgmt-server type amp primary-server 10.10.10.43 profile default-amp
!
aaa authentication-server tacacs "AAAserver"
host "10.10.10.50"
key PanGalacticGoggleBlaster
session-authorization
!
aaa authentication mgmt
server-group "mgmt"
enable
!
aaa tacacs-accounting server-group mgmt mode enable command all
!
snmp-server enable trap
snmp-server host 10.10.10.100 version 2c KnowWhereYoureTowelIs udp-port 162
snmp-server host 10.10.10.101 version 2c KnowWhereYoureTowelIs udp-port 162
snmp-server trap source 10.10.10.42
logging level warnings security
logging level warnings network
logging level warnings system
logging level warnings user
logging level warnings wireless
!
localip 0.0.0.0 ipsec ThrowSelfAtGround&Miss
!
enable secret
password
password
!

write memory

mgmt-user admin root
password
password
!

2. Grab any controller that is running the same AOS version and has the same kind of licenses (AP, PEF, RFP, etc) and console into it
3. Wipe the controller by doing a write erase (Note: do not do a write erase all because it will wipe out your licenses)

(Trillian) #write erase
All the configuration will be deleted. Press 'y' to proceed :
Write Erase successful

(Trillian) #reload
Do you really want to restart the system(y/n): y
System will now restart!

4. Go through the setup wizard a day just hit enter on everything (besides putting on an ipv6 address as that actually requires some input) and give generic administration and enable password and reboot

Enter Switch Role (master|local|standalone) [master]:
Enter VLAN 1 interface IP address [172.16.0.254]:
Enter VLAN 1 interface subnet mask [255.255.255.0]:
Enter IP Default gateway [none]:
Do you wish to configure IPV6 address on vlan 1 (yes|no) [yes]: no
This controller is restricted to Country code US for United States, please confirm (yes|no)?: yes
Enter Time Zone [PST-8:0]:
Enter Time in UTC [02:49:39]:
Enter Date (MM/DD/YYYY) [8/12/2016]:
Enter Password for admin login (up to 32 chars): ********
Re-type Password for admin login: ********
Enter Password for enable mode (up to 15 chars): ********
Re-type Password for enable mode: ********
Do you wish to shutdown all the ports (yes|no)? [no]: no

Current choices are:

System name: Aruba7005
Switch Role: master
VLAN 1 interface IP address: 172.16.0.254
VLAN 1 interface subnet mask: 255.255.255.0
Option to configure VLAN 1 interface IPV6 address: no
Time Zone: PST-8:0
Ports shutdown: no

If you accept the changes the switch will restart!
Type  to go back and change answer for any question
Do you wish to accept the changes (yes|no)yes

5. Login to your now “clean” controller, do a config terminal and paste in your script

(Aruba7005)
User: admin
Password: ********
(Aruba7005) >en
Password:********
(Aruba7005) #configure t
Enter Configuration commands, one per line. End with CNTL/Z

(Aruba7005) (config) #hostname ZaphodBeeblebrox
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #enable bypass
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #banner motd ~
Enter TEXT message [maximum of 4095 characters].
Each line in the banner message should not exceed 255 characters.
End with the character '~'.

"NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE"
"This is a private network device. If you are not authorized to"
"access this device, disconnect at once! Actual or attempted use,"
"access, examination, or configuration change by an unauthorized"
"person external to the Corporation will result in criminal and civil"
"prosecution to the fullest extent of the law. Unauthorized login"
"attempts by internal personnel will be reported immediately to the"
"violator's management and may result in disciplinary action."
"NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE"
~
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #clock timezone UTC 0
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #license profile centralized-licensing-enable
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #ipv6 enable
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #ipv6 mld
(ZaphodBeeblebrox) (config-mld) #!
(ZaphodBeeblebrox) (config) #vlan 2 Native
(ZaphodBeeblebrox) (config) #vlan 42 MGMT
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #
(ZaphodBeeblebrox) (config) #interface vlan 42
(ZaphodBeeblebrox) (config) #   ip address 10.10.10.42 255.255.255.0
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #Interface Loopback
(ZaphodBeeblebrox) (config-loop)#  no ip address
(ZaphodBeeblebrox) (config-loop)#!
(ZaphodBeeblebrox) (config) #ip default-gateway 10.10.10.1
Warning: Route will be added when nexthop is resolved
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #interface gigabitethernet 0/0/2
(ZaphodBeeblebrox) (config-if)# description "Link to SomeSwitch"
(ZaphodBeeblebrox) (config-if)# trusted
(ZaphodBeeblebrox) (config-if)# ip access-group "mcast_opt" session
(ZaphodBeeblebrox) (config-if)# switchport mode trunk
(ZaphodBeeblebrox) (config-if)# switchport trunk native vlan 2
(ZaphodBeeblebrox) (config-if)# switchport trunk allowed vlan 42
(ZaphodBeeblebrox) (config-if)#!
(ZaphodBeeblebrox) (config) #interface gigabitethernet 0/0/0
(ZaphodBeeblebrox) (config-if)# description "Undefined"
(ZaphodBeeblebrox) (config-if)# trusted
(ZaphodBeeblebrox) (config-if)# ip access-group "mcast_opt" session
(ZaphodBeeblebrox) (config-if)# switchport mode trunk
(ZaphodBeeblebrox) (config-if)# switchport trunk native vlan 2
(ZaphodBeeblebrox) (config-if)# switchport trunk allowed vlan 42
(ZaphodBeeblebrox) (config-if)#!
(ZaphodBeeblebrox) (config) #interface vlan 1
(ZaphodBeeblebrox) (config-subif)#no ip address
(ZaphodBeeblebrox) (config-subif)#shutdown
(ZaphodBeeblebrox) (config-subif)#!
(ZaphodBeeblebrox) (config) #syslocation "Magrathea"
(ZaphodBeeblebrox) (config) #syscontact "DentArthurDent"
(ZaphodBeeblebrox) (config) #snmp-server community "KnowWhereYoureTowelIs"
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #mgmt-server type amp primary-server 10.10.10.43 profile default-amp
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #aaa authentication-server tacacs "AAAserver"
(ZaphodBeeblebrox) (TACACS Server "AAAserver") #   host "10.10.10.50"
(ZaphodBeeblebrox) (TACACS Server "AAAserver") #   key PanGalacticGoggleBlaster
(ZaphodBeeblebrox) (TACACS Server "AAAserver") #   session-authorization
(ZaphodBeeblebrox) (TACACS Server "AAAserver") #!
(ZaphodBeeblebrox) (config) #aaa authentication mgmt
(ZaphodBeeblebrox) (Management Authentication Profile) #   server-group "mgmt"
(ZaphodBeeblebrox) (Management Authentication Profile) #   enable
(ZaphodBeeblebrox) (Management Authentication Profile) #!
(ZaphodBeeblebrox) (config) #aaa tacacs-accounting server-group mgmt mode enable command all
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #snmp-server enable trap
(ZaphodBeeblebrox) (config) #snmp-server host 10.10.10.100 version 2c KnowWhereYoureTowelIs udp-port 162
(ZaphodBeeblebrox) (config) #snmp-server host 10.10.10.101 version 2c KnowWhereYoureTowelIs udp-port 162
(ZaphodBeeblebrox) (config) #snmp-server trap source 10.10.10.42
(ZaphodBeeblebrox) (config) #logging level warnings security
(ZaphodBeeblebrox) (config) #logging level warnings network
(ZaphodBeeblebrox) (config) #logging level warnings system
(ZaphodBeeblebrox) (config) #logging level warnings user
(ZaphodBeeblebrox) (config) #logging level warnings wireless
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #localip 0.0.0.0 ipsec ThrowSelfAtGround&Miss
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #enable secret
Password:********
Re-Type password:********
(ZaphodBeeblebrox) (config) #!
(ZaphodBeeblebrox) (config) #
(ZaphodBeeblebrox) (config) #write memory
Saving Configuration...

Configuration Saved.

(ZaphodBeeblebrox) (config) #
(ZaphodBeeblebrox) (config) #mgmt-user admin root
Password:********
Re-Type password:********
Password changed. Please re-authenticate

6. Check the boot file of the controller by doing a show boot (it should be default.cfg) and do a write memory

(ZaphodBeeblebrox) # show boot
Config File: default.cfg

Boot Partition: PARTITION 1

(ZaphodBeeblebrox) #write mem
Saving Configuration...

Configuration Saved.

7. Insert a USB into the controller. Verify you can see its contents by doing a dir usb: partition [0|1]

(ZaphodBeeblebrox) #dir usb: partition 1
Listing /mnt/usbdisk/slot0/1

drwxr-xr-x    3 root     root        16384 Apr 28  2014 $RECYCLE.BIN
drwxr-xr-x    2 root     root        16384 Jul  9  2014 ODB$
-rwxr-xr-x    1 root     root    3839401984 Jul 29 21:22 SW_DVD5_WIN_ENT_10_1511_64BIT_English_MLF_X20-82288.ISO

(ZaphodBeeblebrox) #

8. Copy the configuration from the controller to the USB drive by doing a copy flash: default.cfg usb: partition 1 .cfg (adjust the filename from flash or USB partition if yours is different)

(ZaphodBeeblebrox) #copy flash: default.cfg usb: partition 1 Cutoverconfig.cfg
....File default.cfg copied to /mnt/usbdisk/slot0/1/Cutoverconfig.cfg successfully.

9. Do an eject usb

10. Take your new configuration file and copy it to the controller you wish to wipe using copy : flash:

(FordPrefect) #copy usb: partition 1 Cutoverconfig.cfg flash: Cutoverconfig.cfg
....File Cutoverconfig.cfg copied to flash successfully.

11. Verify it was successfully copied by doing a dir

(FordPrefect) #dir

-rw-r--r--    1 root     root         6331 Aug 12 02:50 AUDITTRAIL-HISTORY.log
-rw-r--r--    1 root     root         3494 Aug 12 02:50 AUDITTRAIL-LOGIN_OUT-HISTORY.log
-rwxr-xr-x    1 root     root        24664 Aug 12 03:04 Cutoverconfig.cfg

12. Now edit the boot file of the controller by doing a boot config-file

(FordPrefect) #boot config-file Cutoverconfig.cfg

13. Verify that it is now the boot file by doing a show boot

(FordPrefect) #show boot
Config File: Cutoverconfig.cfg

Boot Partition: PARTITION 1

14. Reload the controller by doing a reload (if it asks you to save the configuration, select NO)

(FordPrefect) #reload
Do you want to save the configuration(y/n): n
Do you really want to restart the system(y/n):

15. The controller will now boot up using the new configuration file.
16. Login to the controller, do an enable then do a boot config-file default.cfg and then a write memory

(FordPrefect) #boot config-file default.cfg
(FordPrefect) #show boot
Config File: default.cfg

Boot Partition: PARTITION 1

(FordPrefect) #write mem
Saving Configuration...

Configuration Saved.

Done!

First, a consultant must have a deep technical skill set – there is no way around it. They have to put in the time and work to become an expert in their field. It is morally wrong and outright dishonest to charge a customer a fee for a consultant to come out and they do not know what they are talking about. I have seen scenarios where the customer actually knew what they were talking about and the consultant didn’t. However, since the consultant is the “expert”, the customer entrusts in what their saying and thus corrupts their own knowledge. The consultant has to take the time to stay abreast with new technologies related to their field while solidifying their foundations. Not only that, the consultant needs to research every job and customer needs BEFORE getting to the site. The customer is normally paying a decent fee for their time on-site and the consultant needs to do what they can to not waste the customer’s time. There is no replacement for technical knowledge and no easy way around getting it either.

In addition to being technical, the consultant must have good social skills as well. The customer needs someone that can empathize with their situation and really listen to their needs. A lot of consultants will come in with their own agenda thinking they know what’s best before even talking to the customer – that is not a good way to build a relationship. They need to be able to put themselves in the customer’s shoes and figure out what they are really after. The only way to do that is to truly listen to what they are saying in the initial meeting and walk through. It also means listening to their feedback when you give advice. The customer/consultant relationship should be a partnership. Not making it so makes both of the roles harder than they need to be. Doing so builds trust between the two . When there is trust, the customer is much more susceptible to input from the consultant and much more likely to give repeat business/good reviews to them as well.

In my opinion, a consultant isn’t just a “smart guy”. A consultant is someone who is personable, empathetic, and (most importantly) knows what they are talking about.

Questions or comments? Leave them below and/or find me on twitter @mattbfrederick

Some WiFi engineers have monopolized the word “survey” to mean performing a RF survey (with something like Ekahau, AirMagnet, etc). I have always used the word “survey” to mean “a site visit to gather and record data”. This data can be for a design, for a deployment, or for troubleshooting. A “Design Survey” is a visit to the site to gather and record data in order to develop and deliver a design. A “Deployment Survey” is a visit to the site to gather and record data on how everything was installed and document and changes or tweaks that have to be made. A “Troubleshooting Survey” is a visit to the site to gather and record data on the issues they are having in order to document the fixes that need to be made. A “RF Survey” can be a part of any one of those surveys. This is because surveying RF is a very specific task and only part of what you are doing when surveying the actual site.

For the past few years, I have worked at a VAR that does WiFi as well as PTP, PMP, tower construction, 900 MHz SCADA, wired network deployments, among other things. When surveying a site for a tower build, you look at the land, the soil, look for power lines, airports, roads, perform FAA coordination, etc. When surveying for a PTP, you are looking at trees, tower load, tower space, LoS, performing FCC coordination, etc. The bulk of the surveys we performed did not require site survey software and walking around placing dots on a map.

I know this is only supposed to be about WiFi, but a lot of the companies out there that provide WiFi services also provided non-WiFi services. So, the terms they use (especially one as commonly used as “survey”) need to be able to translate from WiFi to other area as well.

So, a RF survey can be part can be part of a survey. However, it is by no means the only kind of survey you can do. Also, a RF survey for WiFi can be broken down into two categories: an Active RF Survey or a Passive RF Survey. An Active RF Survey is done while your device is actively connected to the SSID when performing the survey. A Passive RF Survey is done while you are not connected to a SSID. Both have their uses, but that is another blog post. Please note that both of these require you to be on-site! There is no such thing as a Predictive Survey – it doesn’t exist. You can do some Predictive Modeling, but any sort of survey requires you to be on-site.

Questions or comments? Leave them below and/or find me on twitter @mattbfrederick