So, you want to do an outdoor WLAN site survey with AirMagnet Survey & Microsoft MapPoint software.  You will need to have MapPoint installed on your machine – I installed Microsoft MapPoint North America 2010 for my configuration.

First, you’ll need a GPS receiver.  I found the following GPS devices have been tested to work with AirMagnet Survey:

1. DeLorme Earthmate GPS LT-20

2. DeLorme Earthmate GPS LT-40

3. Garmin eTrex

4. Garmin eTrex Legend

5. Garmin GPS 18 Deluxe (Use with GPSGate conversion software)

6. Magellan eXplorist XL

7. Magellan eXplorist 500

8. Pharos iGPS-180

When I first started out on this project, I did not have a GPS receiver.  I simply browsed eBay and searched the list I provided above.  I wanted a USB flavored receiver, so I chose the DeLorme Earthmate GPS LT-20.  It came with software, which immediately made its way into the recycle bin.  It cost less than 20 bucks with shipping.

I went through the standard installation of any USB device.  I plugged it into my laptop and let it go out and download the drivers and install them.  It shows up here as the USB Human Interface Device:

You’ll also need serial emulator software.  I went online and downloaded the DeLorme Serial Emulator version 1.09, and installed it.  The file I downloaded and installed was named “InstallSerialEmulator.exe”

Next, configure the serial emulation software with the following parameters: 4800, 8/N/1, no flow control.  You should see a little satellite dish icon on the bottom right of your screen.  Right click it, select ports, and as you can see here, I am using Com 2.  Don’t be fooled into thinking you are to select NMEA.  I was, and it did not work.  I finally stumbled into using my Com 2 port, and using the “Raw” setting. 

When you select the port, only use ports 1 – 9.  Don’t use any others!

To test the serial emulation softwarae, I used Tera Term.  I started Tera Term, chose Com 2, and then went to Setup à Serial Port and set it up with the same parameters I used with the serial emulation software.

At first, I did not see any data scrolling by.  Even though when I right click on the serial emulator software and it shows that Auto-Start is checked, I had to click start.

When I clicked OK, I started to see data scroll past me.  Now I know my GPS is working properly.  I will also state that during the making of this document, I went back and forth quite a few times, taking screenshots and I ended up rebooting this machine to get it working.  Your mileage may vary.

Now you are ready to configure AirMagnet Survey Pro and start your survey.

Step 1. Create a new project, name it, select the directory and select the GPS option and click next.

Next you will import the map from MapPoint.  You will have to be connected to the Internet when you set your project up, so do it from somewhere with connectivity.  Iif you are not connected to the Internet, this is the message you will recieve when you choose MapPoint from the Import Outdoor Street/Campus Map:

Choose MapPoint from the Import Outdoor Street/Campus Map (GPS) Image

Microsoft MapPoint will automatically start, and bring up a window for you to zoom in and select the outdoor area you are going to survey.  Zoom in to the area that you want and press OK.

You’ll see the GPS coordinates of the top left and bottom right of the box you selected as your survey area.  Click next.

I’m going to choose an outdoor residential area.  Notice how it sets my propagation assessment to 300 feet.  I set my power to 30 milliwatts since I am guessing that is the output power of most access points in the neighborhood. Click Next, and then click Finish.

Before you can start surveying, you need to configure AirMagnet Survey to that it knows about your GPS receiver.  From Survey mode, select File > Configure > Settings. Check the “Enable GPS port” box.  Then click on the Configure button and configure the Com port – I am using Com 2 for my configuration.  When complete, click OK twice.

You should test to make sure your GPS is configured correctly in AirMagnet Survey.  Select the “Tools” tab from the bottom right portion of the toolbar on the bottom of your survey.  Click on the GPS Information tab, and you should see GPS coordinates.  If you do not see anything, your AirMagnet Survey application is not seeing your GPS receiver.  The first time I used the GPS receiver I did not see anything, and I needed to go back and set up my com ports correctly.

I went outdoors, waited for my GPS receiver to get a fix, and then walked down the street.  I walked down one side of the street, down a little path at the end, and then back on the other side of the street.  I would estimate the survey was accurate most of the time, and when it wasn’t, it was about 20 feet away from where I was really standing.  Pretty good if you ask me.

One thing to note – I did lose my GPS fix when I was under some very large Oak trees.  If you think you might lose reception, keep an eye on your screen.  You may see a message like this:

Overall, I’m pretty happy with AirMagnet’s GPS functionality.  It all went together relatively quickly and painlessly.  Remember to configure your serial emulation properly and you’ll do fine.

For those of you who are wondering what the final product looks like, here it is:

Is evaluating every device on your WLAN necessary? Yes!

I was recently tasked with assisting in the wireless configuration of an evaluation/demo unit that was going to be on-site for a few days. The device was a portable x-ray machine with a remote plate that communicates with the portable unit.

After assisting with the configuration of the portable unit, I inquired as to how the remote plate communicates with the portable. I was told it had an 802.11n bridge built in and that is how it communicated. Since I could not access the configuration of the portable or the plate, I used my protocol and spectrum analyzer to see how it was communicating.

As soon as the main unit was turned on, I noticed an access point on channel five.  The technicians ran a test of the portable x-ray and the remote plate for me and this is what I saw when the unit took the picture and transferred it over the “bridge link”.

As the saying goes, the packets never lie. Here are a few screen captures from my protocol analyzer.

From all the evidence here, knowing those packets never lie, is this configuration really a bridge?  I discovered that it is not a bridge - it is really an access point and the panel is a client.

Is the channel set up properly? No. It is set to channel 5, which is not a best practice in the 2.4 GHz range.

What is your opinion of the Channel Bonding?   I do not believe in channel bonding in the 2.4 GHz range.

Would you allow this device in your environment?

For those of you like me who always want to know what’s under the hood – here’s what I found:

AirMagnet Applications - Internet connection not found error

I recently had an issue with my Fluke AirMagnet toolset that I would like to share.

I was going to do a site survey Friday afternoon. I had not used my survey laptop in several months when I pulled it out of the survey kit that morning, and decided now would be a good time put the latest versions of WiFi Analyzer and Survey Pro on it.

I downloaded the latest builds and licenses and installed both packages, and copied the licenses into the appropriate folder.  I tested both builds – I fired up WiFi Analyzer and it worked just fine with my Orinoco 8494 USB adapter; I opened the last project in Survey Pro and it worked as expected.  I did not use control panel à Add or Remove Programs first, however.  I just ran the executables.

I put my laptop back into my kit and went out to the site several hours later.  The site did not have any internet access when I arrived.  I got everything ready to do the work I was going to do and tried to start my AirMagnet Survey software.  I was surprised when I received this message:

Needless to say I was not amused.  I then tried my AirMagnet WiFi Analyzer, and got the same exact message:

Now I was doubly not amused.  I packed everything back up and went back to the office.  When I arrived, I booted up my laptop and both software packages worked – presumably because I was back on the network.

I then turned off my Wi-Fi adapter and tried to start Wi-Fi Analyzer.  Within milliseconds, I got the same error as before when launching the application.  I'll spare you the jpeg this time.

I called on a few WLAN Engineer friends and we all agreed that this was not something Fluke was doing on purpose, and it must be something on my machine.  To prove this point, several of my friends tried their machines (with similar builds) while not connected to a network and their applications started without issue.

I decided to start over.  I went to the Control Panel à Add or Remove Programs, and removed both apps and reinstalled them.  I got the same results as before – when on the network, my apps started, and when not on the network, they would not start.

I let the machine rest (and me) overnight, and in the morning I reached out to my friends again for sympathy, sanity checks, and advice.  One friend in particular (THANK YOU JH!!!) stated that she has always had to not only remove the software via the Control Panel, but to also nuke the C:\Program Files\AirMagnet Inc\AirMagnet Laptop folder after removing the software.

Since I had nothing else to lose, I went to the Control Panel à Add or Remove Programs, and removed both apps, then blew away the folders and then reinstalled the applications.  Problem solved, lesson learned.  Many thanks go out to everyone who offered up suggestions!

Client issues when upgrading to 802.11n

We recently had an issue with an 802.11n upgrade that I would like to share.  Setting the scene – Cisco controllers recently upgraded to 7.0.220.0, HT enabled, with a building full of Cisco Aironet 1130 AG series access points.

A conference area was then refreshed with Cisco 3502i series access points.  Reports started to come in that laptops were locking up when clients roaming to the conference area from other parts of the building where the 1130 series access points are located.  Laptops are company issued HP 6930p series.

Below you will find details on the laptop models, OSes, and driver versions that were tested and their results.  You will also see the different testing scenarios and their results below that.  However, to summarize:

The only laptop that was able to reproduce the lockup issue was a 6930p running Windows XP with a 5300 AGN wireless adapter using 12.0.0.82 driver.  6930p running 12.4.4.5 and 14.3.2.1 drivers worked without an issue. 

After updating  the drivers to 14.3.2.1 (driver install package reads 14.3.1.1 but after installing it reports the driver as 14.3.2.1).  Feedback from those laptop customers it appears to have resolved their lockup issues.

Please don’t stop reading now.  Scroll all the way to the bottom and take a look at the testing scenarios!

Models tested

• 6930p - Intel 5300 AGN - 12.0.0.82 - (XP) (14.3.2.1.)
• Device connected to 3502 AP worked fine for approximately 1.5 hours
• After roaming with laptop, it locked up and had to power cycle to recover
• With AP connected to 3502, shutting down 3502 which would force client to roam to another AP
1. Client wireless adapter locked up, but OS was still functioning  sluggishly.
2. Had to power cycle laptop to recover
• Updated driver to 14.3.2.1 and tested the same scenarios above and client worked in all cases.

• 6930p - Intel 5300 AGN - 12.4.4.5 – (XP)
• No issues, functioned properly
• 8460p - Intel 6205 advanced N - 14.0.2.2 - (Win7)
• No issues, functioned properly
• 8460p - Intel 6205 advanced N - 14.0.1.2 - (XP)
• No issues, functioned properly
• 6910p - Intel 4965 AGN - 12.2.0.11 - (XP)
• No issues, functioned properly
• 6930p - Intel 5300 AGN - 12.4.0.21 - (XP)
• No issues, functioned properly
• 8440p - Intel 6200 advanced AGN - 14.0.1.2 - (XP)
• No issues, functioned properly
• 8460p - Intel 6205 advanced N - 15.1.1.1 - (XP)
• No issues, functioned properly
• 6930p - Intel 5300 AGN - 12.4.1.4 - (Win7)
• No issues, functioned properly
• 6910p - Intel 4965 AG - 13.0.0.107 - (Win7)
• No issues, functioned properly

Testing scenarios

·         Client using 802.11g only

o    Unable to test this as the laptop that had the problem would not honor the adapter settings when disabling 802.11n mode and setting radio to 802.11g only (still connected at 802.11an)

o    This happened with the 12.0.0.82 and 14.3.2.1 drivers

o    Interesting thing is with the 6930p that has 12.4.4.5 drivers, it would properly honor the settings of disabling 802.11n and connecting at 802.11g only

·         Client using 802.11a only

o    Unable to test this as the laptop that had the problem would not honor the adapter settings when disabling 802.11n mode and setting radio to 802.11a only (still connected at 802.11an)

o    This happened with the 12.0.0.82 and 14.3.2.1 drivers

o    Again - interesting thing is with the 6930p that has 12.4.4.5 drivers, it would properly honor the settings of disabling 802.11n and connecting at 802.11a only

·         Client using 802.11an

o    Of all the laptop models and OSes tried, only the 6930p with 12.0.0.82 driver locked up.  All others worked fine.

o    6930p with 12.4.4.5 drivers worked just fine on 802.11an, no issues.

·         Roam between 1130 and 3502

o    The 6930p with 12.0.0.82 drivers locked up when roaming from 3502 to 1130 AP, issue was resolved when upgrading to 14.3.2.1 driver

o    The 6930p with 12.4.4.5 drivers worked just fine when roaming, no issues.

·         disable HT on wireless controller

o    all clients worked fine while connected at 80211a and 802.11g radios.  This, of course, is not the direction you want to go when you just upgraded your network to HT.

     

If you use AirMagnet Survey Pro to do site surveys, do you calibrate your card?

Quickly convert your Cisco 1131 autonomous AP to lightweight

I've always been a proponent of priming your APs on the bench before deployment.  It is much easier to iron out any issues while you have all your troubleshooting gear at your fingertips.

I recently found myself being handed a batch of  "lightweight" 1131s to install at a new site (at the last minute), where only the AP VLAN existed. 

After installing the APs and patching, I noticed the LED came up green when it booted, but that was all.  After calling someone and having them issue "show cdp neighbor" on the CLI of the switch, my theory ("AP" on all interfaces where APs were patched) that the APs I had been handed were autonomous was confirmed.

The new site didn't have Internet access, so off I went to find it. I knew if I could quickly get the right image on the APs, they would boot up just like the do out of the box, hit the controller and download the code from the controller.  It was either that, or drive several hours back to the main office and prime them like I normally do.

After spending an hour or so researching, I figured out the easiest way would be to simply tftp a later autonomous image to the AP directly from my laptop, reboot the AP, then tftp the lightweight image to it, install it back up on the ceiling and let the infrastructure do the rest.

Here are the steps to do the job quickly:

*download these two files from CCO first and place in your tftp root directory*

c1130-k9w7-tar.124-25d.JA1.tar
c1130-rcvk9w8-tar.124-21a.JA2.tar

1.  Set laptop wired interface to 192.168.0.1/24, connect AP to Laptop via ethernet ports

2.  Console into AP from laptop

3.  Hold mode button in and connect power brick, I held it for 30 seconds and released it.

4.  "Console in" -- default username and password is Cisco/Cisco

5.  Paste this into your AP:

interface BVI1
ip address 192.168.0.2 255.255.255.0
no ip route-cache
no shut

6.  Start your tftp server application on your laptop

7.  Paste this in:  archive download-sw /overwrite tftp://192.168.0.1//c1130-k9w7-tar.124-25d.JA1.tar

8.  Watch the console output...  when finished, reboot the AP

9.  Log back in to the AP, then paste this in: 
archive download-sw /overwrite /force-reload tftp://192.168.0.1//c1130-rcvk9w8-tar.124-21a.JA2.tar

Notice the spaces before the slashes this time.  For some reason the syntax changed slightly and required spaces.

10.  The AP will reboot and not find the controller because it is attached to your laptop.  Go install the AP and plug it in, and if the infrastructure is configured properly, it should get the download the same code the controller is running and then start broadcasting the WLANs in the default AP group.

Do not trunk a wired guest VLAN to multiple foreign controllers

This is an issue that recently plagued me for longer than I would care to admit. I hope it helps you!

I'm focusing on Cisco Bug CSCtw44999 "Do not trunk a wired guest VLAN to multiple foreign controllers. This is not supported, and will generate unpredictable results." It will also generate lots of trouble tickets.

Many sites have two 5508 series controllers, one being the primary and one being the secondary. The controllers are both configured the same for redundancy (with exception to the obvious hostnames, IP addresses, etc) and usually put all of a building's access points on one controller to avoid inter-controller roaming. The secondary exists in case the primary fails - it may host another building's AP.

Take a look at the drawing I have included...

The guest wireless network is a Cisco best practices configuration. The guest WLAN is configured on both the primary & secondary controllers and tunneled to an anchor controller in the DMZ.

Now we get to the guest wired solution.

The following document is pretty straightforward on how to configure wired guest networking, but does not address redundancy for the foreign (local)controllers:

http://www.cisco.com/image/gif/paws/99470/wired_guest_access.pdf
Redundancy is covered in this document:

http://www.cisco.com/en/US/docs/wireless/controller/7.0MR1/configuration/guide/cg_user_accts.html#wp1066125
It states: "Follow these guidelines before using wired guest access on your network:"

•Wired guest access is supported only on the following controllers: Cisco Flex 7500 and 5500 Series controllers, the Cisco WiSM2, and the Catalyst 3750G Integrated Wireless LAN Controller Switch.

•Do not trunk a wired guest VLAN to multiple foreign controllers. This is not supported and may generate unpredictable results.  A true statement, I assure you.
•A wired guest LAN can support multiple anchor controllers.


Redundancy is also covered in this document:
http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70users.htmlIt states: "Follow these guidelines before using wired guest access on your network:"

•Wired guest access is supported only on the following controllers: 5500 and 4400 series controllers, the Cisco WiSM, and the Catalyst 3750G Integrated Wireless LAN Controller Switch.

•Do not attempt to trunk a guest VLAN on the Catalyst 3750G Integrated Wireless LAN Controller Switch to multiple controllers. Redundancy cannot be achieved by doing this action.
That last bullet point is very important. It states "do not attempt to...", but that is rather confusing. It should read, "Do not trunk a wired guest VLAN to multiple foreign controllers."

Needless to say, that can easily be overlooked during configuration day, and you could introduce problems into your wired guest solution.

Redundancy cannot be achieved by trunking a wired guest VLAN to two or more foreign (local) controllers!
Here are the issues that you might see:
-DHCP problems
-Dissassociate/Deauthenticate (login through the splash page over and over again.)
-Timeouts - we saw 90 second long timeouts to the gateway in the DMZ from a wired guest

If you have multiple local controllers, then only one of the them should be configured (or at least active) for the Guest Wired network.

The fix: Trunk the guest wired VLAN to all your local controllers, but only one controller should have the wired guest WLAN active. If the controller with the active wired guest profile fails, then enable the wired guest profile on another controller. Looks like this is about as much redundancy as we can get at the moment. (Jan 2012)