Nightmare with unprimed Access Points

[webquake_support]

In the middle of total boredome we spent hours with the new unprimed universal access points (AIR-AP3702I-UXK9) combined with some of the attractively priced mobility bundles...

SCENARIO:

If you just use the unprimed AP and connect it, it joins the controller, but flashes red and green. This means that only the 2,4GHz band is working. To get the 5GHz online, you need to prime it. After reading the almost 20 pages of documentation found at http://www.cisco.com/c/en/us/td/docs/wireless/access_point/ux-ap/guide/uxap-mobapp-g.html the honored reader will find out that the only way to do this is with the Smartphone and the Cisco AirProvision App.

But this App simply does not work in the current version. As soon as you access an AP the app crashes (Android, V1.7, Samsung Galaxy Note 4, but also tried 3 other makes). On some Smartphone OS Versions it is also not offered in the Google Play Store... (5.0.1) - by the way, getting only 1.x stars in the reviews is really hard to achive these days...

With a lot of approaches and celestial superpower we finally got it working with an old ICS based Galaxy S4 with Version 1.5 downloaded here: https://apkpure.com/cisco-airprovision/com.cisco.airprovision ; (we might offer this so configured device on eBay for a fortune...)

But beware - if you are in the datacenter, having no location service (GPS) and no cellular (but WLAN) you should not even try...

After you got the first AP working, the others got primed via NDP - this worked.

One more thing...

After you reset (boot with button pressed) one of these universal AP's that have been joined (primed or unprimed), they will not join any WLC again. When you attach to the console you get the following lines over and over again:

*Nov 17 20:49:58.463: %CAPWAP-5-SENDJOIN: sending Join Request to 10.x.x.x
*Nov 17 20:50:16.607: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to 10.x.x.x:5246

In this case use the console to login with the default user (cisco/Cisco) and enter:

APa89d.21xx.xxxx#clear capwap private-config 
APa89d.21xx.xxxx#
*Nov 17 20:52:59.235:  factory_reset_universal_ap(): Revert back universal AP in -UX domain during factory reset
*Nov 17 20:52:59.235:  **************************** UNIVERSAL AP PRIMING ***********************

Then reload the AP and it should join again. If it was primed before, it is unprimed after the reset.

SUMMARY:

Who the f**k designed that process, made that incomplete factory reset code and developed that crashing smartphone app? How about a CLI command like "ap prime [country]" or just a simple dropdown or checkbox on the WLC admin pages? What about reading the already set country out of the WLC?

HTH and best regards!

[hardreg]

Yes this is a VERY messed up system.  Imagine my horror when one of our staff configured a WLC and some of these new APs and then shipped them to Germany without any priming.  It would have been better to activate them in the US and then ship them over there even if that means losing access to a few channels.  What was worse is having to try and explain to non technical staff how to prime the first access point.

This is a REALLY messed up system.  I get that they don't want access points using channels that are not authorized in the region where they are located, but come on.  I can ship US fixed config access points to regions where they are illegal to use and nothing technical is going to stop me.

The simple fix for this is to have a sku for an access point with a GPS chip in it.  Another option would be connect to the cisco website from the AP itself (a phone home if you will).  The public IP used could be looked up and the registrar verified.  The EU pretty much all has the same regulations. Only China and Japan have much difference.

They need to come up with some way of getting this resolved.  Otherwise it is back to ordering fix regulatory zone APs and then just shipping them to wherever and worrying about turning off any illegal channels, reducing power, etc. once they arrive at their final destination.

[hakim.salleh]

I feel you.

The whole process is ridiculous. I don't need to mention since you already mention most it.

This will add more pain if you company support is centralized and most of the work need to work remotely

I hope Cisco design more solution instead of introducing more problem pain in the ass product 

[Terrence Koeman]

This is definitely ridiculous. We centrally configure all hardware in NL, even though it then gets sent to the US, UK and Asia. This makes it very hard to do this.

First time I shipped a few access points to the US they were stuck in ETSI domain, so that cost a whole lot of wasted time. Even when I went there I could still not prime the access point on account of my Dutch phone number (+31).

At that point we sold the lot on ebay and bought EnGenius access points.

Seriously, do something about this!

[Dariusz Synowiec]

Saying this is ridiculous is like saying nothing.

We run several projects a year some of them in areas of poor mobile coverage and the process is the nightmare. We tend to pre-stage the network in HQ but sometimes extra items are requested by the customer for example temp WAPs which has just happened to me. So I was lucky to have all WAPs with standard firmware except two which came later when all kit was already on site. There's barely GPRS if I walk around the site and the App on the iPhone will not work. I have connected to the WAP just as it says in the guide but App will not detect me being connected to UX WAP. 

Why for god sake this process can't be run from WLC? Why if I have distributed environment just like you guys, can't provision WAP from WLC with regulatory domain and adjust it based on destination? This could be only developed by someone leaving in the city with mobile aerial above the have not thinking the whole process through. 

Hey Cisco, get it sorted !!!! You charge way too much to give us rubbish solutions for simple tasks!!

[Tausif Gaddi]

Priming is the process where the regulatory domain and country configuration for the universal access point is set. The regulatory domain and country configuration for your access point define the valid set of channels and allowed power levels for the country where your AP is installed.

A universal access point can get primed in two ways:

    Manual Priming, using the Cisco AirProvision mobile application
    Automatic Priming, through Cisco Neighbor Discovery Protocol (NDP) message propagation

refer - http://www.cisco.com/c/en/us/td/docs/wireless/access_point/ux-ap/guide/uxap-mobapp-g.html#pgfId-105024

[esturao]

Everyone please note->>> Do not use the default password in the Cisco documentation:

https://www.cisco.com/c/en/us/td/docs/wireless/access_point/ux-ap/guide/uxap-mobapp-g.html

Cisco Aironet Universal AP Priming and Cisco AirProvision User Guide

Preparing an Autonomous AP for Manual Priming

Step 4 Says leave username blank and password Cisco

Change the username and password of AP on controller and try again. Don’t use username like default/cisco/tadmin/test etc.

 

[timothy.king]

Couldn't agree more.

[c-davies]

I have had a customer trying this and reported the androids failed but an iphone worked. Outrageous!

[Ken Cen]

This is a pretty old thread, hope this helps future googlers

The IOS AirProvision tool works!

In order to prime the unit, it is assume an SSID is configured and you are able to connect to it from your Jesus phone (iPhone).  Be sure to turn on location services for the AirProvision app.

Normally, when configuring the SSID, the below is NOT checked
 

Universal Admin Mode:

Universal Admin Mode

If the Universal Admin mode is "not checked", it will "not prime"

To prime the unit, simply check the universal admin mode, launch the AirProvision, and priming is instant.

-Ken

[Kevin_Henry]

Thanks Ken, I had the same problem and the Universal admin mode check box on the SSID solved it.

[Dirk-Jan Uittenbogaard]

Thank you for the Universal Admin mode tip.
In my setup with Mobility Express on an 1850 I was able to fix it by manually entering the following command through the CLI:

(Cisco Controller) show wlan summary
WLAN ID WLAN Profile Name / SSID Status Interface Name
------- ------------------------------------- -------- --------------------
        1 testlan1         / testlan1 Disabled management 
        2 testguest1       / testguest1 Disabled management 
       16 Universal        / Universal Enabled management

(Cisco Controller) config wlan universal-ap-admin enable 16  (16 = the WLAN ID from above)

 NOTE: (in blue) you see that the "Universal" SSID was enabled when I ran the config wlan command. That doesn't work. You have to disable the SSID first and then you can enable Universal Admin mode for that SSID.