Wired Stuff
WiFi Tablet Corner
My80211 White Papers (Coming Soon!)

Cisco Wireless Compatibility Matrix (Nov. 2011)

WiFi Training


 

Podcasts / Videos

My80211 Videos

Cisco: 802 11 frames with Cisco VIP George Stefanick

Fluke Networks: Minimize Wi Fi Network Downtime

Aruba: Packets never lie: An in-depth overview of 802.11 frames

ATM15 Ten Talk “Wifi drivers and devices”

Houston Methodist Innovates with Wireless Technology

Bruce Frederick Antennas (1/2)

 

Bruce Frederick dB,dBi,dBd (2/2)

Cisco AP Group Nugget

Social Links
Revolution WiFi Capacity Planner

Anchor / Office Extends Ports

 

Peek Inside Cisco's Gear

See inside Cisco's latest wireless gear!

2.4 GHz Channel Overlap

EXAMPLE 1  

EXAMPLE 2

EXAMPLE 3  

Interference Types

BLUETOOTH
 

Microwave Oven
 

Cordless Phone

JAMMER!
 

LWAPP QoS Packet Tagging

 

 

IEEE 802.11a/g/n Reference Sheet

 

CWSP RELEASE DATE 2/08/2010
  • CWSP Certified Wireless Security Professional Official Study Guide: Exam PW0-204
    CWSP Certified Wireless Security Professional Official Study Guide: Exam PW0-204
    by David D. Coleman, David A. Westcott, Bryan E. Harkins, Shawn M. Jackman

    Shawn Jackman (Jack) CWNE#54 is a personal friend and has been a mentor to me for many years.  I've had the pleasure and opportunity to work with Jack for 4 years. Jack is a great teacher who takes complex 802.11 standards and breaks them down so almost anyone can understand the concept at hand. I'm excited for you brother. Great job and job well done! Put another notch in the belt!

  

Tuesday
Aug062013

Mark Your Calendars - Wireless Field Day 5 (Aug 7th-9th, 2013) #WFD5

I’m headed to WFD5 being held in San Jose, August 7th-9th. The sponsor line up is one to get excited about! A total of 9 sponsors in all are presenting during this event. Of which, four sponsors are new to Wireless Field Day -  AirTight, 7signal, Xirrus and Meru. We also have the return of past sponsors Fluke, Aerohive, Wildpackets, MetaGeek and Motorola. 

 

Delegates 

As always the delegate gene pool is a who's who in wireless social blogging and subject matter experts in their own right. Each delegate brings their own level of experience to each event. This always makes for great conversation and sponsor interaction.

http://techfieldday.com/event/wfd5/ 

 

Sponsors 

MetaGeek - 

I’m particularly interested in hearing about MetaGeeks integration with Cisco. MetaGeek demoed their WiSpy integration with Cisco Clean Air access points at Cisco Live. Interested in learning about the backend mechanics and added flexibility this new offering will bring. Hanging with the MetaGeek guys is always a blast. Good group of folks. My kind of people. 

7Signal - 

Interested in hearing about their Sapphire solution and business model. They seem like an interesting company for network optimization. No prior experience with these folks so my ears are wide open! I want to hear about their healthcare optimization experience. Might be something I can leverage. 

AirTight -

I’ve had the opportunity to work with AirTights offerings in the past. I found them to be highly competent. Most WiFi vendors today offer similar security solutions already built into their products. I want to hear how AirTight is positioning their value ad to customers and their new cloud base offering. I’m not a big overlay guy myself. Keeping my ears open. 

Xirrus - 

I have no experience with Xirrus. Looking forward to meeting the Xirrus team and learning about their offerings. I’ve heard good things about their product line. Looking forward to some good take aways from the meeting.

Meru - 

Meru is the awkward kid on the bus. They do things differently and their solution is based around single channel architecture. I’m keeping an open mind and looking forward to meeting team Meru. 

Wildpackets -

Boy do I love me some Wildpackets. I can wrap up Jay and his team in one word, OUTSTANDING. When you meet a vendor that has equally or more passion about WiFi than you do that is a vendor I want to do business with. Looking forward to the 11ac update and any new announcements that may be coming our way during the meeting.

Aerohive -

Nothing but love for my friends at Aerohive. They’re knocking down doors and making their presence known. Rightfully so, they have solid offerings and as Devin likes to always mention their “controller LESS”.They have a WiFi team that is a who’s who. Collectivity outside of Aerohive their team is responsible for the majority of 802.11 published material feeding the minds of WiFi engineers around the world. Looking forward to their presentation. When I return from WFD I have a scheduled POC using Aerohive's Branch Office product.  Looking forward to it! 

Fluke -

Not sure what Fluke will be presenting. Interesting in learning about Airmagnet 11ac road map. BTW did anyone get the AirCheck from the Aussie ? 

Motorola - 

The Motorola team had a solid presentation last WFD. Looking forward to the same this go around. 

 

Schedule 

Wednesday, Aug 7

08:00-10:00

Fluke Networks Presents at Wireless Field Day 5 

Wednesday, Aug 7

11:00-13:00

Aerohive Networks Presents at Wireless Field Day 5 

Wednesday, Aug 7

14:30-16:30

WildPackets Presents at Wireless Field Day 5

Thursday, Aug 8

08:00-10:00

AirTight Networks Presents at Wireless Field Day 5

Thursday, Aug 8

10:30-12:30

MetaGeek Presents at Wireless Field Day 5

Thursday, Aug 8

14:30-16:30

Motorola Solutions Presents at Wireless Field Day 5

Friday, Aug 9

08:00-10:00

7signal Presents at Wireless Field Day 5

Friday, Aug 9

10:30-12:30

Xirrus Presents at Wireless Field Day 5

Friday, Aug 9

14:00-16:00

Meru Networks Presents at Wireless Field Day 5

 

Want to follow along on Twitter ? 

Simply follow Twitter hash tag #WFD5 or follow the delegates. 

 

Do you have a question for a sponsor ? 

Post your question via Twitter with hash tag #WFD5 and one of the delegates will ask for you! 

What if I miss the event ? 

Gestalt IT has you covered. Each live event is recorded and posted shortly after the event for your later consumption. 

 

Your feedback was heard loud and clear ..  

PrimeImage Media who does an unbelievable job capturing the live dynamics of each Field Day event will be using a new Delegate Microphone System (DMS).  Now you'll be able to hear each delegate better than ever before. 

 

Wednesday
Jun262013

End-of-Sale and End-of-Life Announcement for the Cisco Identity Services Engine

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5712/ps11640/eol_C51-728424.html

Cisco announces the end-of-sale and end-of life dates for the Cisco Identity Services Engine. The last day to order the affected product(s) is December 24, 2013. 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.

 

Table 1. End-of-Life Milestones and Dates for the Cisco Identity Services Engine

 

Milestone

Definition

Date

End-of-Life Announcement Date

The date the document that announces the end of sale and end of life of a product is distributed to the general public.

June 25, 2013

End-of-Sale Date

The last date to order the product through Cisco point-of-sale mechanisms. The product is no longer for sale after this date.

December 24, 2013

Last Ship Date:
HW

The last-possible ship date that can be requested of Cisco and/or its contract manufacturers. Actual ship date is dependent on lead time.

March 24, 2014

End of Routine Failure Analysis Date:
HW

The last-possible date a routine failure analysis may be performed to determine the cause of hardware product failure or defect.

December 24, 2014

End of New Service Attachment Date:
HW

For equipment and software that is not covered by a service-and-support contract, this is the last date to order a new service-and-support contract or add the equipment and/or software to an existing service-and-support contract.

December 24, 2014

End of Service Contract Renewal Date:
HW

The last date to extend or renew a service contract for the product.

March 21, 2018

Last Date of Support:
HW

The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete.

December 31, 2018

 

 

HW = Hardware OS SW = Operating System Software App. SW = Application Software

Table 2. Product Part Numbers Affected by This Announcement

End-of-Sale Product Part Number

Product Description

Replacement Product Part Number

Replacement Product Description

Additional Information

ISE-3315-K9

Cisco Identity Services Engine 3315 Hardware Appliance

SNS-3415-K9

Small Secure Network Server for ISE, NAC, & ACS Applications

-

ISE-3315-M-K9

Cisco Identity Services Engine 3315 Appliance Migration SKU

SNS-3415-M-ISE-K9

SNS 3415 Migration Server: Loaded with ISE Software

-

ISE-3355-K9

Cisco Identity Services Engine 3355 Hardware Appliance

SNS-3495-K9

Large Secure Server for ISE and NAC Applications

-

ISE-3355-M-K9

Cisco Identity Services Engine 3355 Appliance Migration SKU

SNS-3495-M-ISE-K9

SNS 3495 Migration Server: Loaded with ISE Software

-

ISE-3395-K9

Cisco Identity Services Engine 3395 Hardware Appliance

SNS-3495-K9

Large Secure Server for ISE and NAC Applications

-

ISE-3395-M-K9

Cisco Identity Services Engine 3395 Appliance Migration SKU

SNS-3495-M-ISE-K9

SNS 3495 Migration Server: Loaded with ISE Software

-

 

Friday
Jun212013

Cisco 802.11ac Certified by the Wi-Fi Alliance 

Cisco's 3602 and the RM3000 AC Module certified by the Wi-Fi Alliance! 

Read about it here ... 

 

Saturday
Jun012013

Aruba 802.11ac Announcement 

ClientMatch

Since the very beginning WiFi clients have been a challenge and they still are today. There is no standard for WiFi client vendors to follow. Vendors implement their own roaming algorithm (triggers), interpret their own signal, SNR and noise levels. Vendors almost never publish these triggers. In the industry we call this “vendor client secret sauce”. I blogged about this very subject on Aruba AirHeads forum. 

http://community.arubanetworks.com/t5/Technology-Blog/Client-Roaming-Triggers/ba-p/69902 

Aruba introduced ClientMatch an innovative way of managing clients. Aruba’s believes their approach to client management is unique. So unique that Aruba has filed a patent, US20130036188. Aruba takes an active approach steering clients to access points. 

Chris Lyttle @ WiFi Kiwi did an exceptional job outlining Aruba’s ClientMatch. Pay close attention the blog responses. 

http://www.wifikiwi.com/cwap/a-sticky-problem-wi-fi-clients-that-wont-roam/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+WifiKiwi+(WiFi+Kiwi's+Blog)

You can see more from Aruba about ClientMatch here

http://www.youtube.com/watch?feature=player_embedded&list=PL37Y-XxK6oakSZ-b9Hpr43gJxDTvOWckT&v=DMlTVlAtB2U 

http://www.arubanetworks.com/technology/clientmatch/ 

My take on ClientMatch. Client steering isn’t at all new. Typically vendors will direct clients with reason code 17 or by managing clients by ignoring probe request on a specific radio to trick the client to go where the WiFi network thinks its best. These are more active approaches. Meaning a client must interact - do THIS and the WiFi network will do THAT. Aruba’s systems appears to be more proactive in nature. 

Aruba Access Point Model - AP-220

I couldn’t believe my eyes and ears when I seen and heard that the new Aruba 802.11ac access point is VENT FREE. Finally, Aruba got the memo and environmental departments in healthcare systems around the world are rejoicing! You have no idea how many times the subject of  Aruba Access Points and open vents have come up in discussion in healthcare opportunities. Cleaning a vented access point presents challenges of course. 

The AP-220 packs a punch of sheer speed and throughput. It’s also the best looking access point in the Aruba access point stable. 

Another Interesting approach is the dual GIG NIC. Not sure how this will be accepted when its deployed. It’s not typical to pull 2 cables per access point. There will be obvious needs for extra wired side bandwidth options. Makes me wonder why they cant tap a 10 GIG port on the back of the ap ?

802.11ac Pros / Cons (Voodoo)

The next generation wireless is not without its challenges. These challenges are industry wide and every vendor will have the burden of educating customers on proper design and deployment. Expect to see design and deployment documents released or updated specific for 802.11ac best practices.  

Customers looking at 802.11ac need to have a firm understanding of the technology and how to properly deploy it. Customers who don't, 802.11ac could hinder their wireless network. 

80/160 Mhz channels 

The 802.11n standard introduced channel bonding for the first time. It allows us the ability to take (2) neighboring 20 MHz channels and by bonding them together to make a single 40 MHz channel.Thus allowing higher speed and throughput from improvements in the PHY, MAC and extra RF real estate.  802.11n also introduced a new level of troubleshooting. The frame structure is different and requires knowledge to interpret the traffic.  Analysis tools and hardware require updating to read 802.11n traffic. 

802.11ac will be no different. You will need to update your tool box, brush up on 802.11ac frame structure. Test, lab and practice.

The issue is 80/160 MHz bonding. Aruba hasn't addressed how to deploy this monster. For that matter, Cisco hasn't either. The 5 GHz medium is known for it’s 24 non overlapping channels. Some customers only deploy UNII1 and UNII3 to avoid DFS (802.11h). This could present challenges for these folks. 

Your deployment strategy of 802.11ac needs to be defined and deployed in areas to meet specific bandwidth, throughput, density, application or business needs. Proceed with caution and consult an expert before deploying 802.11ac. 

Wave1 / Wave 2 

Wave 1 will support SU-MIMO. (SU) stands for SINGLE USER. This simply means that wave 1 technology will support sending multiple streams of data from an access point with multiple antennas downstream to a client at a high rate of speed.

Wave 2 will support MU-MIMO. (MU) stands for MULTI USER. This simply means that wave 2 technology will support sending multiple streams of data from an access point with multiple antennas downstream to multiple clients at a high rate of speed to give a “full duplex” like experience.

Wave 1 hardware is not upgradeable to Wave 2. 

Client Support 

Like all previous 802.11 advancements client support seems to be spotty the first year or so till vendors iron out the bugs and settle in. 

Legacy Devices

Once 802.11ac is deployed, how will legacy devices react to the 802.11ac IE ? There could be a percentage of clients in your enterprise who may have issues. Know your network and bench mark your clients. Keep a close eye on your legacy clients.

802.11ac Frame Analysis

Get up to speed on capturing 802.11ac frames

http://blog.wildpackets.com/2013/05/02/best-practices-for-capturing-802-11ac-traffic-for-analysis.html

Did you miss the announcement?

No worries. Tech Field Day covered the event live. Check out the link below

http://techfieldday.com/appearance/aruba-802-11ac-announcement/ 

Tech Field Day Delegates Blog Post 

Daniel Raaaaaaar! Cybulskie 

http://www.simplywifi.co/blog/2013/5/23/an-access-point-is-just-one-piece-of-the-80211ac-puzzle.html 

 

Jennifer huber - 

http://jenniferhuber.blogspot.com/2013/05/aruba-model-220-access-point-new-with.html 

 

Chris Lyttle - 

http://www.wifikiwi.com/cwap/a-sticky-problem-wi-fi-clients-that-wont-roam/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+WifiKiwi+(WiFi+Kiwi's+Blog)

 

 

Monday
May202013

Cisco client debug - 802.11 Association Status Code 

When you enable client debug you can be hit with a ton of information. One of the things I look at is the 802.11 association status code. The status code is very telling. It can provide information about your client and if there is a connection issue. Another tool to add to your bag of tricks. 

Lets take a peek at a debug log

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a 0.0.0.0 8021X_REQD (3) DHCP Not required on AP 08:1f:f3:e1:8f:c0 vapId 4 apVapId 4for this client

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Not Using WMM Compliance code qosCap 00

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a 0.0.0.0 8021X_REQD (3) Plumbed mobile LWAPP rule on AP 08:1f:f3:e1:8f:c0 vapId 4 apVapId 4

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfMsAssoStateInc

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfPemAddUser2 (apf_policy.c:223) Changing state for mobile b4:f0:ab:e3:19:6a on AP 08:1f:f3:e1:8f:c0 from Idle to Associated

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Stopping deletion of Mobile Station: (callerId: 48)

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a Sending Assoc Response to station on BSSID 08:1f:f3:e1:8f:c0 (status 0) ApVapId 4 Slot 0

*apfMsConnTask_0: May 11 23:31:21.186: b4:f0:ab:e3:19:6a apfProcessAssocReq (apf_80211.c:5272) Changing state for mobile b4:f0:ab:e3:19:6a on AP 08:1f:f3:e1:8f:c0 from Associated to Associated

 

Our debug shows a status code of 0. Referencing our chart below we will find our association was a success. 

802.11 Association Status Codes

https://supportforums.cisco.com/docs/DOC-33185

 

Code 802.11 definition Explanation
0 Successful
1 Unspecified failure For example : when there is no ssid specified in an association request
10 Cannot support all requested capabilities in the Capability Information field Example Test: Reject when privacy bit is set for WLAN not requiring security
11 Reassociation denied due to inability to confirm that association exists NOT SUPPORTED
12 Association denied due to reason outside the scope of this standard Example : When controller receives assoc from an unknown or disabled SSID
13 Responding station does not support the specified authentication algorithm For example, MFP is disabled but was requested by the client.
14 Received an Authentication frame with authentication transaction sequence number
out of expected sequence
If the authentication sequence number is not correct.

 

15
Authentication rejected because of challenge failure
16 Authentication rejected due to timeout waiting for next frame in sequence
17 Association denied because AP is unable to handle additional associated stations Will happen if you run out of AIDs on the AP; so try associating a large number of stations.
18 Association denied due to requesting station not supporting all of the data rates in the
BSSBasicRateSet parameter
Will happen if the rates in the assoc request are not in the BasicRateSet in the beacon.
19 Association denied due to requesting station not supporting the short preamble
option
NOT SUPPORTED
20 Association denied due to requesting station not supporting the PBCC modulation
option
NOT SUPPORTED
21 Association denied due to requesting station not supporting the Channel Agility
option
NOT SUPPORTED
22 Association request rejected because Spectrum Management capability is required NOT SUPPORTED
23 Association request rejected because the information in the Power Capability
element is unacceptable
NOT SUPPORTED
24 Association request rejected because the information in the Supported Channels
element is unacceptable
NOT SUPPORTED
25 Association denied due to requesting station not supporting the Short Slot Time
option
NOT SUPPORTED
26 Association denied due to requesting station not supporting the DSSS-OFDM option NOT SUPPORTED
27-31 Reserved NOT SUPPORTED
32 Unspecified, QoS-related failure NOT SUPPORTED
33 Association denied because QAP has insufficient bandwidth to handle another
QSTA
NOT SUPPORTED
34 Association denied due to excessive frame loss rates and/or poor conditions on current
operating channel
NOT SUPPORTED
35 Association (with QBSS) denied because the requesting STA does not support the
QoS facility
If the WMM is required by the WLAN and the client is not capable of it, the association will get rejected.
36 Reserved in 802.11 This is used in our code ! There is no blackbox test for this status code.
37 The request has been declined This is not used in assoc response; ignore
38 The request has not been successful as one or more parameters have invalid values NOT SUPPORTED
39 The TS has not been created because the request cannot be honored; however, a suggested
TSPEC is provided so that the initiating QSTA may attempt to set another TS
with the suggested changes to the TSPEC
NOT SUPPORTED
40 Invalid information element, i.e., an information element defined in this standard for
which the content does not meet the specifications in Clause 7
Sent when Aironet IE is not present for a CKIP WLAN
41 Invalid group cipher Used when received unsupported Multicast 802.11i OUI Code
42 Invalid pairwise cipher
43 Invalid AKMP
44 Unsupported RSN information element version If you put anything but version value of 1, you will see this code.
45 Invalid RSN information element capabilities If WPA/RSN IE is malformed, such as incorrect length etc, you will see this code.
46 Cipher suite rejected because of security policy NOT SUPPORTED
47 The TS has not been created; however, the HC may be capable of creating a TS, in
response to a request, after the time indicated in the TS Delay element
NOT SUPPORTED
48 Direct link is not allowed in the BSS by policy NOT SUPPORTED
49 Destination STA is not present within this QBSS NOT SUPPORTED
50 The Destination STA is not a QSTA NOT SUPPORTED
51 Association denied because the ListenInterval is too large NOT SUPPORTED
200
(0xC8)

 

Unspecified, QoS-related failure.
Not defined in IEEE, defined in CCXv4
Unspecified QoS Failure. This will happen if the Assoc request contains more than one TSPEC for the same AC.
201
(0xC9)
TSPEC request refused due to AP’s policy configuration (e.g., AP is configured to deny all TSPEC requests on this SSID). A TSPEC will not be suggested by the AP for this reason code.
Not defined in IEEE, defined in CCXv4
This will happen if a TSPEC comes to a WLAN which has lower priority than the WLAN priority settings. For example a Voice TSPEC coming to a Silver WLAN. Only applies to CCXv4 clients.
202
(0xCA)
Association Denied due to AP having insufficient bandwidth to handle a new TS. This cause code will be useful while roaming only.
Not defined in IEEE, defined in CCXv4

203
(0xCB)
Invalid Parameters. The request has not been successful as one or more TSPEC parameters in the request have invalid values. A TSPEC SHALL be present in the response as a suggestion.

 

Not defined in IEEE, defined in CCXv4

 

 

This happens in cases such as PHY rate mismatch. If the TSRS IE contains a phy rate not supported by the controller, for example. Other examples include sending a TSPEC with bad parameters, such as sending a date rate of 85K for a narrowband TSPEC.
Monday
May202013

Aruba 802.11ac coverage tomorrow @ 10:00 PDT! Follow on Twitter #11ac

Aruba Networks will be announcing their 802.11ac (wave 1) offering next week 5.21.2013 @ 10:00 PDT.

This is an exciting time for Aruba Networks. Aruba's been pretty tight lipped about their 802.11ac access point up to this point. At the last Tech Field Day the delegates, myself included, received a sneak peek of Aruba's new flag ship offering.  I am looking forward to this live event to hear exactly Aruba's deployment strategy, marketing approach and more importantly how Aruba's 802.11ac will operate in the enterprise. 

LIVE COVERAGE 


TWITTER 


Join us for an in-depth 802.11ac discussion live on Twitter hash tag #11ac


Questions that will be covered #11ac 

1.            Higher data rates, better access point reliability: How important are these and other 802.11ac Features to your organization?

2.            What are the use cases for 802.11ac in your organization - eg. video over Wi-Fi?

3.            In your organization, what issues will be solved, or addressed by the 802.11ac standard?

4.            When are you planning to invest in the 802.11ac technology?

5.            What's your WLAN deployment strategy with 802.11ac - eg. only deploy in high density areas?

Tech Field Day event schedule

Agenda


10:00 am PDT Aruba 802.11ac Announcement with Keerti Melkote, Aruba CTO and Founder

10:45 am Microsoft Lync over 802.11ac Wi-Fi with Pascal Menezes, Sr. Program Manager at Microsoft

11:45 am Tech Field Day 802.11ac Roundtable

2:00 pm Designing Wi-Fi for Voice & Video with Mike Kail, Netflix VP of IT

3:00 pm Next-gen Access Network Design with Arun Kanchi, Exafort CEO




ARUBA AIRHEADS FOURM 





Friday
Apr262013

WLC: AP Managers Are Pingable - 7.x onwards

Since the very beginning the AP manager on a Cisco WLC would never respond to pings. Well that has all changed if you use LAG and an AP manager with 7.x code!

I like how Cisco hides little nuggets in their documentation. It states, in LAG mode, the management and AP manager uses the same base LAG MAC address.

 


Note With the 7.0 release onwards, the MAC address of the management interface and the AP-manager interface is the same as the base LAG MAC address.

LAB

A show ARP on the distribution switch you can see the MAC is identical for both the manager and AP manager.

NOTE --

This was tested on 4402,4404 and 5508 model controllers.

AP manager(s) aren't needed with a 5508.

This only applies to a WLC in LAG mode w/ AP Manager

Additional Reading Material:

http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70mint.html#wp1117168

Tuesday
Apr092013

End-of-Sale and End-of-Life Announcement for the Cisco Aironet 1260 Series

 

http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps10980/end_of_life_notice_c51-727739.html

Cisco announces the end-of-sale and end-of-life dates for the Cisco Aironet 1260 Series. The last day to order the affected product(s) is October 7, 2013. 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.

Table 1. End-of-Life Milestones and Dates for the Cisco Aironet 1260 Series

 

Milestone

Definition

Date

End-of-Life Announcement Date

The date the document that announces the end-of-sale and end-of-life of a product is distributed to the general public.

April 8, 2013

End-of-Sale Date

The last date to order the product through Cisco point-of-sale mechanisms. The product is no longer for sale after this date.

October 7, 2013

Last Ship Date:
HW

The last-possible ship date that can be requested of Cisco and/or its contract manufacturers. Actual ship date is dependent on lead time.

January 5, 2014

End of SW Maintenance Releases Date:
HW

The last date that Cisco Engineering may release any final software maintenance releases or bug fixes. After this date, Cisco Engineering will no longer develop, repair, maintain, or test the product software.

October 7, 2014

End of Routine Failure Analysis Date:
HW

The last-possible date a routine failure analysis may be performed to determine the cause of hardware product failure or defect.

October 7, 2014

End of New Service Attachment Date:
HW

For equipment and software that is not covered by a service-and-support contract, this is the last date to order a new service-and-support contract or add the equipment and/or software to an existing service-and-support contract.

October 7, 2014

End of Service Contract Renewal Date:
HW

The last date to extend or renew a service contract for the product.

January 2, 2018

Last Date of Support:
HW

The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete.

October 31, 2018

 

Wednesday
Apr032013

End-of-Sale and End-of-Life Announcement for the Cisco Aironet 1140 Series

The 1140 series served me well. 

http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps10092/end_of_life_notice_c51-727649.html

Cisco announces the end-of-sale and end-of-life dates for the Cisco Aironet 1140 Series. The last day to order the affected product(s) is October 1, 2013. 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.

 

Table 1. End-of-Life Milestones and Dates for the Cisco Aironet 1140 Series

 

Milestone

Definition

Date

End-of-Life Announcement Date

The date the document that announces the end-of-sale and end-of-life of a product is distributed to the general public.

April 2, 2013

End-of-Sale Date

The last date to order the product through Cisco point-of-sale mechanisms. The product is no longer for sale after this date.

October 1, 2013

Last Ship Date:
HW

The last-possible ship date that can be requested of Cisco and/or its contract manufacturers. Actual ship date is dependent on lead time.

December 30, 2013

End of SW Maintenance Releases Date:
HW

The last date that Cisco Engineering may release any final software maintenance releases or bug fixes. After this date, Cisco Engineering will no longer develop, repair, maintain, or test the product software.

October 1, 2014

End of Routine Failure Analysis Date:
HW

The last-possible date a routine failure analysis may be performed to determine the cause of hardware product failure or defect.

October 1, 2014

End of New Service Attachment Date:
HW

For equipment and software that is not covered by a service-and-support contract, this is the last date to order a new service-and-support contract or add the equipment and/or software to an existing service-and-support contract.

October 1, 2014

End of Service Contract Renewal Date:
HW

The last date to extend or renew a service contract for the product.

December 27, 2017

Last Date of Support:
HW

The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete.

September 30, 2018

 

HW = Hardware OS SW = Operating System Software App. SW = Application Software

Table 2. Product Part Numbers Affected by This Announcement

End-of-Sale Product Part Number

Product Description

Replacement Product Part Number

Replacement Product Description

Additional Information

AIR-AP1141N-A-K9

802.11g/n Fixed Auto AP; Int Ant; A Reg Domain

AIR-SAP2602I-A-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; A Reg Domain

-

AIR-AP1141N-E-K9

802.11g/n Fixed Auto AP; Int Ant; E Reg Domain

AIR-SAP2602I-E-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; E Reg Domain

-

AIR-AP1141N-P-K9

802.11g/n Fixed Auto AP; Int Ant; P Reg Domain

AIR-SAP2602I-Q-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; Q Reg Domain

-

AIR-AP1142-AK9-5

802.11a/g/n Fixed IOS AP; Int Ant; A Reg Domain, Qty. 5 Aps

AIR-SAP2602I-AK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; A RegDomain

-

AIR-AP1142-CK9-5

802.11a/g/n Fixed IOS AP; Int Ant; C Reg Domain, Qty. 5 Aps

AIR-SAP2602I-CK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; C RegDomain

-

AIR-AP1142-IK9-5

802.11a/g/n Fixed IOS AP; Int Ant; I Reg Domain, Qty. 5 Aps

AIR-SAP2602I-IK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; I RegDomain

-

AIR-AP1142-KK9-5

802.11a/g/n Fixed IOS AP; Int Ant; K Reg Domain, Qty. 5 Aps

AIR-SAP2602I-KK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; K RegDomain

-

AIR-AP1142-NK9-5

802.11a/g/n Fixed IOS AP; Int Ant; N Reg Domain, Qty. 5 Aps

AIR-SAP2602I-NK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; N RegDomain

-

AIR-AP1142-PK9-5

802.11a/g/n Fixed IOS AP; Int Ant; P Reg Domain, Qty. 5 Aps

AIR-SAP2602I-QK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; Q RegDomain

-

AIR-AP1142-RK9-5

802.11a/g/n Fixed IOS AP; Int Ant; R Reg Domain, Qty. 5 Aps

AIR-SAP2602I-RK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; R RegDomain

-

AIR-AP1142-SK9-5

802.11a/g/n Fixed IOS AP; Int Ant; S Reg Domain, Qty. 5 Aps

AIR-SAP2602I-SK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; S RegDomain

-

AIR-AP1142-TK9-5

802.11a/g/n Fixed IOS AP; Int Ant; T Reg Domain, Qty. 5 Aps

AIR-SAP2602I-TK9-5

802.11n Auto 5APs; 3x4:3SS; Mod; Int Ant; T RegDomain

-

AIR-AP1142N-A-K9

802.11a/g/n Fixed Auto AP; Int Ant; A Reg Domain

AIR-SAP2602I-A-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; A Reg Domain

-

AIR-AP1142N-C-K9

802.11a/g/n Fixed Auto AP; Int Ant; C Reg Domain

AIR-SAP2602I-C-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; C Reg Domain

-

AIR-AP1142N-I-K9

802.11a/g/n Fixed Auto AP; Int Ant; I Reg Domain

AIR-SAP2602I-I-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; I Reg Domain

-

AIR-AP1142N-K-K9

802.11a/g/n Fixed Auto AP; Int Ant; K Reg Domain

AIR-SAP2602I-K-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; K Reg Domain

-

AIR-AP1142N-N-K9

802.11a/g/n Fixed Auto AP; Int Ant; N Reg Domain

AIR-SAP2602I-N-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; N Reg Domain

-

AIR-AP1142N-P-K9

802.11a/g/n Fixed Auto AP; Int Ant; P Reg Domain

AIR-SAP2602I-Q-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; Q Reg Domain

-

AIR-AP1142N-R-K9

802.11a/g/n Fixed Auto AP; Int Ant; R Reg Domain

AIR-SAP2602I-R-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; R Reg Domain

-

AIR-AP1142N-S-K9

802.11a/g/n Fixed Auto AP; Int Ant; S Reg Domain

AIR-SAP2602I-S-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; S Reg Domain

-

AIR-AP1142N-T-K9

802.11a/g/n Fixed Auto AP; Int Ant; T Reg Domain

AIR-SAP2602I-T-K9

802.11n Auto; 3x4:3SS; Mod; Int Ant; T Reg Domain

-

AIR-LAP1141N-A-K9

802.11g/n Fixed Unified AP; Int Ant; A Reg Domain

AIR-CAP2602I-A-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; A Reg Domain

-

AIR-LAP1141N-E-K9

802.11g/n Fixed Unified AP; Int Ant; E Reg Domain

AIR-CAP2602I-E-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; E Reg Domain

-

AIR-LAP1141N-P-K9

802.11g/n Fixed Unified AP; Int Ant; P Reg Domain

AIR-CAP2602I-Q-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; Q Reg Domain

-

AIR-LAP1142-AK9-10

802.11a/g/n LWAPP AP Integrated Antennas A Reg Domain, 10 APs

AIR-CAP2602I-AK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; A RegDomain

-

AIR-LAP1142-CK9-10

802.11a/g/n LWAPP AP Integrated Antennas C Reg Domain, 10 APs

AIR-CAP2602I-CK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; C RegDomain

-

AIR-LAP1142-IK9-10

802.11a/g/n LWAPP AP Integrated Antennas I Reg Domain, 10 APs

AIR-CAP2602I-IK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; I RegDomain

-

AIR-LAP1142-KK9-10

802.11a/g/n LWAPP AP Integrated Antennas K Reg Domain, 10 APs

AIR-CAP2602I-KK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; K RegDomain

-

AIR-LAP1142-NK9-10

802.11a/g/n LWAPP AP Integrated Antennas N Reg Domain, 10 APs

AIR-CAP2602I-NK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; N RegDomain

-

AIR-LAP1142-PK9-10

802.11a/g/n LWAPP AP Integrated Antennas P Reg Domain, 10 APs

AIR-CAP2602I-QK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; Q RegDomain

-

AIR-LAP1142-RK9-10

802.11a/g/n LWAPP AP Integrated Antennas R Reg Domain, 10 APs

AIR-CAP2602I-RK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; R RegDomain

-

AIR-LAP1142-SK9-10

802.11a/g/n LWAPP AP Integrated Antennas S Reg Domain, 10 APs

AIR-CAP2602I-SK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; S RegDomain

-

AIR-LAP1142-TK9-10

802.11a/g/n LWAPP AP Integrated Antennas T Reg Domain, 10 Aps

AIR-CAP2602I-TK910

802.11n CAP 10APs w/CleanAir; 3x4:3SS; Mod; Int; T RegDomain

-

AIR-LAP1142N-A-K9

802.11a/g/n Fixed Unified AP; Int Ant; A Reg Domain

AIR-CAP2602I-A-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; A Reg Domain

-

AIR-LAP1142N-C-K9

802.11a/g/n Fixed Unified AP; Int Ant; C Reg Domain

AIR-CAP2602I-C-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; C Reg Domain

-

AIR-LAP1142N-I-K9

802.11a/g/n Fixed Unified AP; Int Ant; I Reg Domain

AIR-CAP2602I-I-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; I Reg Domain

-

AIR-LAP1142N-K-K9

802.11a/g/n Fixed Unified AP; Int Ant; K Reg Domain

AIR-CAP2602I-K-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; K Reg Domain

-

AIR-LAP1142N-N-K9

802.11a/g/n Fixed Unified AP; Int Ant; N Reg Domain

AIR-CAP2602I-N-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; N Reg Domain

-

AIR-LAP1142N-P-K9

802.11a/g/n Fixed Unified AP; Int Ant; P Reg Domain

AIR-CAP2602I-Q-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; Q Reg Domain

-

AIR-LAP1142N-R-K9

802.11a/g/n Fixed Unified AP; Int Ant; R Reg Domain

AIR-CAP2602I-R-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; R Reg Domain

-

AIR-LAP1142N-S-K9

802.11a/g/n Fixed Unified AP; Int Ant; S Reg Domain

AIR-CAP2602I-S-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; S Reg Domain

-

AIR-LAP1142N-T-K9

802.11a/g/n Fixed Unified AP; Int Ant; T Reg Domain

AIR-CAP2602I-T-K9

802.11n CAP w/CleanAir; 3x4:3SS; Mod; Int Ant; T Reg Domain

-

 

 

Friday
Mar082013

Cisco: Enterprise Best Practices for Apple Mobile Devices on Cisco Wireless LANs #BYOD

BOOKMARK ! Another good reference for Apple iDevices on a Cisco Wireless LAN. There are a few mentions that need further clarification. Overall good read and reference. 

 

http://www.cisco.com/en/US/docs/wireless/technology/vowlan/bestpractices/EntBP-AppMobDevs-on-Wlans.pdf

 

  • Purpose of this Document, page 2

  • Introduction, page 2

  • Wi-Fi Channel Coverage, page 2

  • Roaming, page 7

  • Fast Roaming, page 9

  • Data Rates, page 12

  • WebAuth for iOS Devices, page 16

  • Troubleshooting, page 22

  • Summary of Recommendations, page 31

  • Addendum A: IEEE IP DSCP - AVVID Values & 802.11e WMM, page 33

  • Addendum B: Summary Matrix, page 34

  • Addendum C: Acronyms, page 35 

Thursday
Mar072013

iOS 6: Wi-Fi network roaming with 802.11k and 802.11r #BYOD

Is it me or is it hard to keep up with all the little details. Add this to your bookmarks, could come in handy!  ~~ Thanks Scott for referencing this ..


Summary

Learn how iOS 6 improves client roaming using the 802.11k and 802.11r Wi-Fi network standards.

Products Affected

iPad, iPhone, iPod touch

iOS 6 introduces support for optimized client roaming on enterprise Wi-Fi networks. The 802.11 Working Group standards k and r were conceived to give wireless clients the ability to more seamlessly roam from access point (AP) to access point within the same network.

802.11k

802.11k allows an iOS 6 device to quickly identify nearby APs that are available for roaming. When the signal strength of the current AP weakens and the iOS device needs to roam to a new AP, it will already know the best candidate AP with which to connect.

802.11r

When an iOS 6 device roams from one AP to another on the same network, 802.11r streamlines the authentication process using a feature called Fast Basic Service Set Transition (FT). FT allows iOS 6 devices to associate with APs more quickly. Depending on your Wi-Fi hardware vendor, FT can work with both preshared key (PSK) and 802.1X authentication methods.

Coupled with 802.11k's ability to quickly identify the target AP, FT's faster association method may enhance application performance and aims to provide a better Wi-Fi experience in iOS.

Additional Information

Not every Wi-Fi network hardware vendor currently supports 802.11k and 802.11r. Check with the manufacturer of your Wi-Fi hardware (controllers and APs) to determine if support is available. Once support for both standards is verified, 802.11k and FT functionality must be enabled. Setup methods vary; please consult the current configuration documentation for your Wi-Fi hardware for details.

The table below indicates which iOS devices can support 802.11k and 802.11r with iOS 6. Even if an iOS device does not support 802.11r, iOS 5.1 added support for "pairwise master key identifier caching" (PMKID caching) which can be used with some Cisco equipment to improve roaming between APs. Additional SSIDs may be necessary to support both FT-capable iOS 6 devices and iOS 5.1 devices.

The following table shows which iOS combinations of version and device will support which AP roaming methods.

  • Prior to iOS 5.1, no method for optimized AP roaming existed in iOS.
  • "Sticky key caching" (SKC) is a form of PMKID caching. SKC is not equivalent to, nor compatible with, opportunistic key caching (OKC).
Wednesday
Mar062013

iOS 5 and iOS 6: List of available trusted root certificates #BYOD

Ever wonder what your iDevice root store looks like from Apple? Wonder no more ... 

 

http://support.apple.com/kb/ht5012

 

Here is a short list:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=JP, O=JPKI, OU=Prefectural Association For JPKI, OU=BridgeCA
        Validity
            Not Before: Dec 27 05:08:15 2003 GMT
            Not After : Dec 26 14:59:59 2013 GMT
        Subject: C=JP, O=JPKI, OU=Prefectural Association For JPKI, OU=BridgeCA
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 946059622 (0x3863b966)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
        Validity
            Not Before: Dec 24 17:50:51 1999 GMT
            Not After : Dec 24 18:20:51 2019 GMT
        Subject: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
Certificate:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 57928 (0xe248)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-Qual-02, CN=A-Trust-Qual-02
        Validity
            Not Before: Dec  2 23:00:00 2004 GMT
            Not After : Dec  2 23:00:00 2014 GMT
        Subject: C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-Qual-02, CN=A-Trust-Qual-02
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 57922 (0xe242)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AT, O=A-Trust, OU=A-Trust-nQual-01, CN=A-Trust-nQual-01
        Validity
            Not Before: Nov 30 23:00:00 2004 GMT
            Not After : Nov 30 23:00:00 2014 GMT
        Subject: C=AT, O=A-Trust, OU=A-Trust-nQual-01, CN=A-Trust-nQual-01
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 93214 (0x16c1e)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-nQual-03, CN=A-Trust-nQual-03
        Validity
            Not Before: Aug 17 22:00:00 2005 GMT
            Not After : Aug 17 22:00:00 2015 GMT
        Subject: C=AT, O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH, OU=A-Trust-nQual-03, CN=A-Trust-nQual-03
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=AOL Time Warner Inc., OU=America Online Inc., CN=AOL Time Warner Root Certification Authority 1
        Validity
            Not Before: May 29 06:00:00 2002 GMT
            Not After : Nov 20 15:03:00 2037 GMT
        Subject: C=US, O=AOL Time Warner Inc., OU=America Online Inc., CN=AOL Time Warner Root Certification Authority 1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=AOL Time Warner Inc., OU=America Online Inc., CN=AOL Time Warner Root Certification Authority 2
        Validity
            Not Before: May 29 06:00:00 2002 GMT
            Not After : Sep 28 23:43:00 2037 GMT
        Subject: C=US, O=AOL Time Warner Inc., OU=America Online Inc., CN=AOL Time Warner Root Certification Authority 2
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 49 (0x31)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=JP, O=Japanese Government, OU=ApplicationCA
        Validity
            Not Before: Dec 12 15:00:00 2007 GMT
            Not After : Dec 12 15:00:00 2017 GMT
        Subject: C=JP, O=Japanese Government, OU=ApplicationCA
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust TTP Network, CN=AddTrust Class 1 CA Root
        Validity
            Not Before: May 30 10:38:31 2000 GMT
            Not After : May 30 10:38:31 2020 GMT
        Subject: C=SE, O=AddTrust AB, OU=AddTrust TTP Network, CN=AddTrust Class 1 CA Root
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust TTP Network, CN=AddTrust Public CA Root
        Validity
            Not Before: May 30 10:41:50 2000 GMT
            Not After : May 30 10:41:50 2020 GMT
        Subject: C=SE, O=AddTrust AB, OU=AddTrust TTP Network, CN=AddTrust Public CA Root
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=SE, O=AddTrust AB, OU=AddTrust TTP Network, CN=AddTrust Qualified CA Root
        Validity
            Not Before: May 30 10:44:50 2000 GMT
            Not After : May 30 10:44:50 2020 GMT
        Subject: C=SE, O=AddTrust AB, OU=AddTrust TTP Network, CN=AddTrust Qualified CA Root
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            74:97:25:8a:c7:3f:7a:54
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC
        Validity
            Not Before: Jan 29 14:20:24 2010 GMT
            Not After : Dec 31 14:20:24 2040 GMT
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6d:8c:14:46:b1:a6:0a:ee
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C=US, O=AffirmTrust, CN=AffirmTrust Premium
        Validity
            Not Before: Jan 29 14:10:36 2010 GMT
            Not After : Dec 31 14:10:36 2040 GMT
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7c:4f:04:39:1c:d4:99:2d
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=AffirmTrust, CN=AffirmTrust Networking
        Validity
            Not Before: Jan 29 14:08:24 2010 GMT
            Not After : Dec 31 14:08:24 2030 GMT
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            77:77:06:27:26:a9:b1:7c
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=AffirmTrust, CN=AffirmTrust Commercial
        Validity
            Not Before: Jan 29 14:06:06 2010 GMT
            Not After : Dec 31 14:06:06 2030 GMT
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=America Online Inc., CN=America Online Root Certification Authority 1
        Validity
            Not Before: May 28 06:00:00 2002 GMT
            Not After : Nov 19 20:43:00 2037 GMT
        Subject: C=US, O=America Online Inc., CN=America Online Root Certification Authority 1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=America Online Inc., CN=America Online Root Certification Authority 2
        Validity
            Not Before: May 28 06:00:00 2002 GMT
            Not After : Sep 29 14:08:00 2037 GMT
        Subject: C=US, O=America Online Inc., CN=America Online Root Certification Authority 2
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 49 (0x31)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=JP, O=LGPKI, OU=Application CA G2
        Validity
            Not Before: Mar 31 15:00:00 2006 GMT
            Not After : Mar 31 14:59:59 2016 GMT
        Subject: C=JP, O=LGPKI, OU=Application CA G2
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA
        Validity
            Not Before: Apr 25 21:40:36 2006 GMT
            Not After : Feb  9 21:40:36 2035 GMT
        Subject: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Apple Computer, Inc., OU=Apple Computer Certificate Authority, CN=Apple Root Certificate Authority
        Validity
            Not Before: Feb 10 00:18:14 2005 GMT
            Not After : Feb 10 00:18:14 2025 GMT
        Subject: C=US, O=Apple Computer, Inc., OU=Apple Computer Certificate Authority, CN=Apple Root Certificate Authority
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1005814224 (0x3bf381d0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=ch, O=admin, OU=Services, OU=Certification Authorities, CN=Admin-Root-CA
        Validity
            Not Before: Nov 15 08:51:07 2001 GMT
            Not After : Nov 10 07:51:07 2021 GMT
        Subject: C=ch, O=admin, OU=Services, OU=Certification Authorities, CN=Admin-Root-CA
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CH, O=admin, OU=Services, OU=Certification Authorities, CN=AdminCA-CD-T01
        Validity
            Not Before: Jan 25 13:36:19 2006 GMT
            Not After : Jan 25 12:36:19 2016 GMT
        Subject: C=CH, O=admin, OU=Services, OU=Certification Authorities, CN=AdminCA-CD-T01
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 33554617 (0x20000b9)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root
        Validity
            Not Before: May 12 18:46:00 2000 GMT
            Not After : May 12 23:59:00 2025 GMT
        Subject: C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root


Tuesday
Mar052013

how To - WISM1 to WISM2 Migration

I recently migrated our WISM1 solution to WISM2s.  I want to share my experience and project gotcha list to help you with your installation.


SUP 720 Firmware

A few things need to be addressed prior to your WISM 2 migration. 

  1. You will need to make sure your SUPS are at 12.2(33)SXJ. This is a requirement for WISM2. Otherwise your SUPs wont recognize the WISM2s.
  2. If your SUP was configured manually to support the WISM1, meaning not configured with the “auto” WISM commands you will need to redo the WISM commands after you upgrade the SUP. 
  3. If you did the auto wism commands during your initial WISM1 installation and installed the WISM2. Your old port channels may still be present. You can check this with a #SHOW (WLAN-DIST-A#show etherchannel summary)
  4. Each WISM2 blade will map to a single port channel. If you see more portchannels. You can simply “no” the auto WISM commands, reboot and the reapply the auto WISM commands. This should clean up your excess port channels. It did for me.

Config Transfer - WISM1 to WISM2 

There has been discussion in the past whether or not you can transfer WLC config from a WISM1 to a WISM2. You can but you should note the below. 

Follow the below guidelines: 

  1. Make sure both controllers are on the same code prior to any code transfer
  2. Pull the config from WISM1 by doing a TFTP transfer
  3. Upload the config to WISM2 by doing a TFTP transfer 
  4. Update the mobility group IP address on all controllers in mobility group adding new WISM2 and removing old WISM1
  5. Remember to anchor your GUEST WLAN. 

 

Prerequisites

Requirements

This is a list of components that are required when deploying WiSM2 in the Catalyst chassis:

Device/Application

SW Versions

Catalyst 650X with 720 Sup*

12.2(33)SXJ or Higher

Ethernet Line-Cards - Tested and Compatible with WiSM2

6148, 6516, 6548, 6704-10Gb, 6708-10Gb, 6716-10Gb, 6748 and 6724

WiSM2 Controllers

7.0 MR1 ver 7.0.116.0

WCS

7.0 MR1 ver 7.0.172.0

* The Catalyst chassis on which the Cisco WiSM2 is installed needs a Supervisor 720 module.

Mobility Compatibility Matrix 

http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html#wp102554

 

WISM2 Deployment Guide

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_tech_note09186a0080b7c904.shtml  

Thanks Scott, Leo and Steve for the edit ..

Wednesday
Feb202013

BUG CSCtn75346: 7925 phone loses 5 GHz connection intermittently with OEAP600

My 2 second sales pitch

Cisco Office Extends is a very powerful enterprise tool to have in your arsenal. It is changing the way we look at remote workers enterprise wide. The ease of installation and seamless mobility from enterprise to home is changing the way we do business.  It helps with users who are technically challenged and at times have issues with the simplest of VPN clients. Most notable in healthcare remote coders. 

On a recent trip to South America I packed my AP600 and Cisco 7925 and conducted long distance testing from Chile to Houston. The calls where remarkably good and my connection was better then some hotel connections with VPN. 

Cisco Office Extends AP600 Bug -

After completing our Office Extends design I had issues connecting my Cisco 7925 Wireless Phone to my Office Extends access point (AP600). The 7925 would cycle on and off the wireless network while constantly displaying the “locating network services” on the handset. 

 


After a packet capture, it was very apparent the issue was the NAV timer. The phone would regularly send a CTS-SELF with a NAV timer set at 18,800us. Normally you might see a NAV at a value of 44us or there around.  

By triggering a frame with a NAV timer set to 18,800us, the Cisco phone was telling everyone on the channel not to communicate because the phone had data to send and it would take 18,800us. Clearly the payload didnt warrent that amount of time.

 

For the non 802.11 readers -- What does this all mean ?

802.11 wireless networks are a half duplex medium, meaning only 1 device can transmit a frame on the medium at a time. In this case, the medium is a channel for example <1, 6 or 11>. 

802.11 use Carrier Sense Multiple Access - Collision Avoidance (CSMA-CA). The Collision Avoidance is particularly interesting. 802.11 uses protocols to sense the wireless medium to determine if the medium is busy or idle. It does this with CSMA-CA. CSMA-CA uses 2 protocols. 

They are Physical Carrier Sense (CCA) and Virtual Carrier Sense (NAV). 

Physical Carrier Senses uses Clear Channel Assessment (CCA). Think of CCA like a pair of ears attached to your head.  Always listening to the medium to determine if other device(s) are on channel trigger frame transmissions. If it senses frame transmissions or elevated levels of non 802.11 interference it will determine the medium as busy. 

Virtual Carrier Sense uses Network Allocation Vector (NAV). When a frame marks the duration with a specific value, in our case 18,800us. Other devices within range of this frame will read this duration value. These devices will then BACKOFF for this set amount of time. This includes access points.

You can see, the Cisco phone was telling all other devices on the channel not to communicate for 18,800us. Normally, most client reserve the medium for 60 - 200us to send traffic. This is why I think the phone would go into locating network services. The access point read the NAV and wasn't allowed to trigger a beacon. No beacon no network. Phone drops and then tries to find the network again.

Upgrade to 1.4.3SR1 fixed the issue

CSCtn75346 Bug Details

7925 phone loses 5 GHz connection intermittently with OEAP600
Symptom:
7925 phone loses 5 GHz connection intermittently with OEAP600.
No connectivity issues when using 2.4 GHz.

Conditions:
Using an OEAP600, or certain third-party 802.11n APs, and 7925 on 5 GHz.

Workaround:
Use 2.4 GHz or an alternate AP platform.
Status Status 
Fixed 

Severity Severity 
3 - moderate 

Last Modified Last Modified 
In Last Year 

Product Product 
Cisco Unified IP Phone 7900 Series 

Technology Technology 
Wireless, Mobile 

1st Found-In 1st Found-in 
1.4(1)
1.4(2) 

Fixed-In Fixed-in 
1.4(3)
1.4(2)ES3

 

“While others may cringe at complex issues. I look at it from a different pair of glasses. The glasses called opportunity to learn something new”.  ~ George Stefanick

Wednesday
Feb132013

Cisco Bridge Alignment ~ Real World Example Using RSSI Voltage

WiFi engineer Timothy Dennehy, a friend of this blog recently blogged about Cisco Bridge alignment using RSSI voltage. Coincidently, I was working on a bridge project at the same time. With Tim's permission, I've reposted. You can visit Tims blog @ http://justdowifi.blogspot.com. On my project, I was able to increase dBm by -33 using this alignment technique.

I was recently called out to investigate a Wi-Fi bridge link that was being accused of being the culprit of a myriad of network problems.

Upon arrival on site, I noticed that the main site’s Wi-Fi bridge was sitting on channel 161, and that channel was overpopulated since there were two access points in the building, both on channel 161.  I moved the building’s access points to the UNII-1 band, and changed the bridge’s channel  to help alleviate some of the congestion since there was another access point on that channel across the street.  These three screen shots are  before I made any changes:

Note that the bridge is capable of achieving a 54 mb/s data rate, however only 3% of all the packets are traveling at that rate – and 92% of them are data packets.  The busiest data rate is the lowest data rate – with 72% of the traffic at that rate.  Hmmm….

Also, a quick screenshot as a baseline..

After coming up with a channel/power plan, I made the necessary changes.  The following three screenshots are post channel plan change.  I saw immediate improvement after my change.  The first screenshot is of the devices now on their newly assigned channels.

With the bridge’s new channel assignment, there is far less noise in the environment and the SNR increases.  This allows the bridge to negotiate a higher data rate.  On channel 153, the bridges are now able to send 78% of the data at 18 mb/s.  A dramatic increase over what I saw when sharing the same channel with other 802.11 devices.

Now that we have some of the low hanging fruit taken care of, it is time to check the out the line of site between the two dish antennas that are making this 2.79 mile Wi-Fi link.

When I did the calculations for this link, I discovered this link should easily handle 54 mb/s since it is less than three miles and it is using high gain antennas.   But it wasn’t, and here I am… (onsite)

I went up on the roof to take a look and here is what I found:

Physically, everything looked good.  But distance from the ground was only 16 feet.  The calculations from two online calculators both agreed these antennas should be ~35 feet above the ground.  Now to take a look at what the antenna sees:

I have centered the antenna’s “target” in this picture.  There is a “V” between those two trees you see in the middle, and a little white speck centered in the V.  That’s our target!  As you can see, we don’t have a clear line of site, which means the antenna does not either.

Fortunately the Electricians came to the rescue with an extension of ten feet.  After the extension had been fabricated, a bucket truck was used to move the antenna up ten feet.

Here’s the antenna’s new view:

Now that’s more like it.  The target is the white blur you see in the middle of this view.  There’s nothing we can do about the metal electrical pole in the middle, which I am told was not there when the link was initially designed.

Now what?  Well, we moved it up, but dishes are not easy to align because they don’t come with any type of sight, and when you are standing behind one (or sitting in the bucket of a bucket truck 30 feet above the ground) you can’t really see what you are doing.

We decided to use the RSSI port on the Cisco bridge to align it.  The first thing you need to do is identify the BNC connector on the unit, which is #2 on the graphic below.

And in “real life”…

Next, you’ll need a length of RG-6 or other 75 ohm coaxial cable with a BNC connector on it.  I bought my raw cable at Home Depot and the BNC cable at Radio Shack.  I stripped both ends with my coaxial cable stripper (I just happen to have one of those) and screwed one end into the BNC connector.  The other end I left raw – that’s the end I connected to my multimeter.  When I was at Radio Shack, I also bought a pair of alligator clips for my test leads – see photo of meter below.  These little gems allow you to clip the meter’s probes to the coaxial wire – connect the red to the center conductor, and the black to the shield.  It is a lot easier than trying to hold the test lead directly to the conductor – especially if you are by yourself.  For a myriad of reasons, I do not recommend doing this alone. 

Connect the BNC cable to the port and measure the voltage with a multimeter.  I snagged this little multimeter at Home Depot for twenty bucks on the same trip when hunting the RG-6.  The other things are in my toolkit – a pair of radios for communicating with someone at the other end of the link, a flexible mirror, and some rubber tape.  The rubber tape is used for weatherproofing cables and connectors, and the mirror for reflecting light.  It sometimes works, sometimes doesn’t.  Don’t try  it at night… it won’t work.  A road flare, on the other hand…

With the connector on the bridge, simply connect the meter and read the voltage using the vdc scale.   I measured the voltage before we raised the antenna so we would have a baseline, and it was .78 vdc.

With the antenna now raised, we simply moved the antenna back and forth, from left to right and then up and down until we reached the highest voltage we could achieve.  We did read 1.43 vdc once, and then tried to find that again but could not and finally settled with 1.35 vdc.  I was happy with that and we decided that we should lock it down and be done with it.

I am also going to mention the length of the coaxial cable.  You may be tempted to use/purchase a short piece of cable.  If you are up in a bucket truck and someone else is there, it is nice to be able to have someone call out the voltage levels to you while you do the antenna adjustment.  A long cable is your friend sometimes.  It isn’t expensive or heavy, so why not get 10 feet or more.  You’ll thank me later.

For those of you who are curious, here’s what the scale looks like when trying to align a Wi-Fi link:

We went from somewhere around -70 dBm (we were at .78 vdc) to approximate -55 dBm.  In my book, that is phenomenal.  We gained at least 10 dB – those of you who are knowledgeable in RF math know what that means!

I will also mention there is another way to align the antennas if you don’t have a meter, etc.  I have not done it this way, however I will include the directions here anyway.  I clipped this information from the hardware installation guide.

“Aligning the Antenna Using LED Indications” (from the Cisco manual)

 

You can align the integrated antenna using LEDs after the bridge successfully associates with a remote  bridge. In the installation mode before association to another bridge, the Install LED blinks amber. If the bridge associates to a root bridge, the Install LED turns continuous amber. If the bridge does not associate to a root bridge in the first 60 seconds, the Install LED blinks green to indicate beacons are being transmitted and the bridge is waiting for another non-root bridge to associate. After association, the Install LED turns into continuous green and the Ethernet, status, and radio LEDs then display signal strength as shown below.  When using LEDs to maximize the signal, adjust the antenna until as many LEDs as possible are turned on and the rest are blinking as fast as possible.

 Here’s the equivalent scale to the RSSI voltage method.

This is a real world example of what the LEDs look like on the back of the bridge.  As you can probably guess,  trying to watch these LEDs and aim an external antenna might be a challenge in the afternoon sun.

Now the antenna has been raised and aligned, I want to see what the traffic looks like with a protocol analyzer.  Looks 98% of the traffic is traversing the Wi-Fi link at 54 mb/s.


I confirmed with a console connection to each bridge that the signal is now in the -55 dBm range, just as the bridge RSSI voltage table depicted.  The SNR was now in the 35-40 dB, much higher than earlier reports of it being in the 10-15 dB range.

  

What a difference ten feet makes!  Mission successful…

One of my lessons learned on this expedition was the fact that I forgot to grab some screenshots of the console output BEFORE I did my work.  I have a protocol analysis of what it looked like before I started, however I don’t have any CLI.  I would love to have a “before and after” – I’ll just have to settle for that screenshot above.  Next time I won’t forget.

BTW, thanks to all who helped me out with blogging.  I appreciate all the input.  You know who you are.

 

 

Tuesday
Feb122013

WFD#4 February 13-15th, 2013 ~ NEXT STOP SAN JOSE!

Once again I received the privilege of attending WFD! This is my 4th Wireless Field Day event. Many thanks to Stephen, Claire and to the other delegates! 

WHAT SHOULD YOU KNOW ABOUT WFD#4?

Field Day events bring together innovative IT product vendors and independent thought leaders to share information and opinions in a presentation and discussion format. Independent bloggers, freelance writers, and podcasters have a public presence that has immense influence on the ways that products and companies are perceived and by the general public.

DO YOU HAVE A QUESTION FOR A PARTICIPATING VENDOR? 

Feel free to tweet your question to any one of the delegates and we will ask on your behalf!

WHAT WFD MEANS TO ME

WFD is an awesome experience to collaborate with other like minded individuals. Share ideas, individual experience, and subject matter expertise. Each delegate brings a unique perspective to the WFD group.

Visiting the shakers and movers in the WiFi industry and getting their undivided attention is a great experience. Often times getting a behind the curtain look at their product road maps and new features.  Getting this exposure helps me understand the direction of WiFi, new products and whats coming out. This allows me to be a better decision maker and a more informed engineer.

Exposure received during these events is massive. Expect hundreds of tweets passing the word. You can also view via live streaming. Check the schedule below!

Social networking is an important aspect in todays networking. Gestalt IT brings it to life in this social media event! 

WFD SPONSORS

I would like to personally thank the below sponsors for participating in WFD4! cant wait to meet you foks!

pastedGraphic.pdf

pastedGraphic_1.pdf

pastedGraphic_2.pdf

pastedGraphic_3.pdf

pastedGraphic_4.pdf

 

 

Delegates

Delegates are selected by the Field Day Delegate community. For more information on our selection process, please see our page about becoming a Field Day Delegate.

 

pastedGraphic_5.pdf

Blake Krone

@BlakeKrone

Blake Krone is Cisco CCIE Wireless and CWNA certified Wireless Network Architect with experience designing and deploying enterprise class networks supporting hundreds of APs and multiple controllers for Voice, Data, and RTLS.

pastedGraphic_6.pdf

Chris Lyttle

@WiFiKiwi

 

pastedGraphic_7.pdf

Daniel Cybulskie

@SimplyWiFi

Daniel Cybulskie is a Senior Security Consultant out of the Toronto, Ontario, Canada area.

pastedGraphic_8.pdf

George Stefanick

@WirelesssGuru

George Stefanick is a Wireless Architect employed by a large healthcare system in the Texas Medical Center.

pastedGraphic_9.pdf

Jennifer Huber

@JenniferLucille

Jennifer has over 10 years of experience in the networking and wireless engineering industry.

pastedGraphic_10.pdf

Keith R. Parsons

@KeithRParsons

Keith Parsons is Managing Director of the Institute for Network Professionals.

pastedGraphic_11.pdf

Lee Badman

@WiredNot

Lee Badman currently writes for Network Computing Magazine as Wireless and Mobility blogger, and has over twelve years of professional industry analysis under his belt.

pastedGraphic_12.pdf

Mark Julier

@MarkJulier

Mark Julier is CEO and founder of DigitalAir Wireless Networks which was established nearly 10 years ago.

pastedGraphic_13.pdf

Peter Paul Engelen

@PPJM_Engelen

Peter-Paul Engelen is a technical consultant with advanced (pre) sales experience and business development skills in multi-vendor Cloud-based (W)LAN and Wholesale ISP/Carriers.

pastedGraphic_14.pdf

Sam Clements

@Samuel_Clements

Sam Clements is an avid wireless technologist with a passion for all things mobility.

pastedGraphic_15.pdf

Scott Stapleton

@ScottPStapleton

Scott started out in Wi-Fi with nothing more than a soldering iron and N-type connector in hand, scouring roof tops for ex-pay-TV antennas as part of the community Wi-Fi movement of the early 2000s.

pastedGraphic_16.pdf

Steve Williams

@SWilliams_Group

Although Steve has a strong routing and switching background, today he focuses mainly on WiFi, Firewalls and Identity Management.

 

Presentation Calendar

Most presentations are streamed live on this page, at TechFieldDay.com, and at some delegate and presenter web sites. After the event, the following pages contain video recordings of these presentations.

 

Wednesday, Feb 13

14:00-16:00

Motorola Solutions Presents at Wireless Field Day 4

Wednesday, Feb 13

16:00-18:00

Wi-Fi Stress Tests with Keith Parsons

Thursday, Feb 14

08:00-10:00

Juniper Presents at Wireless Field Day 4

Thursday, Feb 14

13:00-17:00

Aruba Networks Presents at Wireless Field Day 4

Friday, Feb 15

9:00-10:00

Meraki Presents at Wireless Field Day 4

Friday, Feb 15

10:30-12:30

Cisco Presents at Wireless Field Day 4

 
Thursday
Jan312013

Cisco Wireless LAN Controllers and Lightweight Access Points Code Release 7.0.240.0

Cisco releases code 7.0.240.0

Resolved Caveats

Table 1-7 lists caveats resolved in controller software release 7.0.240.0.

 

Table 1-7 Resolved Caveats 

ID Number
Description

CSCtk13612

Unable to get the order of WLANs in an AP group configuration. When AP Group templates are discovered in WCS, the WLAN order does not match the configuration on the controller.

CSCuc78713

Wireless client do not receive broadcast packets after broadcast key rotation.

CSCty75270

Controller does not keep max RSSI used when classifying rogue AP.

CSCtn78269

Brand new LAPs come up on unexpected channels.

CSCtq97915

1120 and 1130 Lightweight Access Points associated to a controller log memory allocation errors, and can crash or loose configuration.

CSCtr21759

Incorrect transmission of AMSDU within the active block ACK agreement.

CSCts05391

H-REAP client IP address does not appear in the client details on the controller.

CSCts13482

Controller does not update the shared secret.

CSCtt20493

Guest clients stay in Web-Auth Required state without getting redirected.

CSCtt96265

Controller fails to transfer or save configuration and eventually crashes. No crash log available.

CSCtu19860

Controller does not set 802.1p marking for downstream CAPWAP packets.

CSCtw69785

DCA list corrupt with 16 or more configured country codes.

CSCtw94633

Intermittent DHCP packet drop per VLAN for anchor scenario.

CSCtx00942

Webauth stops redirecting after some time.

CSCtx03556

TACACS user login failure on Cisco 5508 Controller running 7.0.116.0.

CSCtx08257

DHCP required configuration enabled on a WLAN is not retained after the controller reboots.

CSCtx17062

Controller client statistics appear blank.

CSCtx42747

AP 3500 radio core dump.

CSCtx17650

Controller may experience a partial denial of service condition when receiving certain malformed HTTP/HTTPS packets.

CSCtx43418

AP manager interface replies to ping using the wrong port.

CSCtx43436

1522CM RAP blacklists the Ethernet/Cable interface.

CSCtx49189

Preauthentication ACL gets removed from Web Auth WLAN.

CSCtx56334

HREAP client does not successfully roam between two controllers.

CSCtx61016

Incorrect BSSID client count on the AP.

CSCtx92465

Monitor mode AP interference measurements not accurate.

CSCty05792

Wireless clients receive GARP from different VLAN.

CSCty07036

CCKM EAPOL broadcast key rotation breaks during M5 exchange.

CSCty15308

CAP3502P-Q reboots every 15 minutes with 7.0.230.0 controller image.

CSCty38823

Memory leak may occur for EAP Framework task.

CSCty45960

TFTP backup config does not show correct setting for exclusion list timer.

CSCty47582

Controller crashes while running show ap eventlog <AP Name> command.

CSCty68030

For AP 3500/1260, upgrade bootloader automatically from IOS.

CSCty82919

AP 1130 in HREAP mode does not send deauthenticate non-associated client.

CSCty96959

Spaces are not allowed in SSID after migration from autonomous, or upgrade from 6.0/7.x releases.

CSCtz05201

5508 controller crashes on LDAP DP Task 1 and 2.

CSCtz20766

Controller crash: software failed on instruction ewaFormSubmit_blacklistclient.

CSCtz23878

802.1x authentications stop happening on specific WLANs.

CSCtz24594

Controller deauthenticates EAP client when credentials change.

CSCtz31572

Wireless clients associated to a Flexconnect locally switched WLAN may not be able to receive broadcast traffic like ARP.

CSCtz43631

Controller keeps ghost client entry if the network between controller and HREAP is unstable.

CSCtz50719

WISM out of memory crash on 7.0.220.0 controller image.

CSCtz55502

Multicast packets may stop or be sent out of order for power-save clients.

CSCtz89535

Motorola MC75 gives inconsistent linktest results.

CSCua29504

802.11w-capable client fails pairwise key handshake with AES.

CSCua39538

Controller with media snooping crashes due to memory corruption.

CSCua59722

Controller crashes with sig11, null pointer exception. Crash file shows sshpmDeleteLeakedWebauthRule.

CSCua60653

Following multiple vulnerabilities in controllers:

Wireless Intrusion Prevention System (wIPS) Denial of Service Vulnerability

Session Initiation Protocol Denial of Service Vulnerability

HTTP Profiling Remote Code Execution Vulnerability

SNMP Unauthorized Access Vulnerability

CSCua74143

WISM with 7.0.230.0 has low buffer length for the packet sent by Catalyst 6K.

CSCua93936

Broadcast Key rotation does not use rotated index 1 and 2.

CSCub07426

SP800-90A DRBG, entropy source updation.

CSCub46092

HREAP-AP is central switch when the WLAN is set for local switch.

CSCub49367

When client roams in a quarantine VLAN, with Authentication enabled, controller cannot change VLAN successfully.

CSCub57982

CT5508 crashes at capwapSocketTask due to malloc corruption.

CSCub65575

WiSM forwards broadcast ARP requests to APs in local mode or H-REAP advertises centrally switched WLANs.

CSCub82353

Controllers configured as mobility anchors may not properly block injected traffic from the network.

CSCub97882

For H-REAP local switching, the WLAN-VLAN mapping changes.

CSCuc06422

World Mode is enabled automatically for the controller.

CSCuc33930

Controller crash in ewaFormSubmit_guestuser_list.

CSCuc68648

5508 controller with 7.0.230.0 image crashes every week due to a memory leak in SNMP.

CSCuc74769

At random intervals, a controller crashes on a WISM1 blade running 7.0.235.0 image.

CSCud05299

WGB client entry leak at radio driver level.

CSCud47994

Continuous RNG test for SP800-90 DRBG seed.

CSCud90781

Controller crashes after loading test image.

CSCue13451

A new 7500 series controller fails to boot a 7.0 image.

CSCud65237

Voice disruption after roaming when a wrong TID is sent on the block ACK sent by the client.

CSCto02968

Memory leak issue.

http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn7_0_240_0.html

Tuesday
Jan292013

What does the RTD-1-ADDR_FLAP system message mean?

I ran into this very issue many moons ago. Good post by Vinay! 

By: Vinay Sharma - Cisco 
  

Introduction

What does the RTD-1-ADDR_FLAP system message mean?

Resolution

The RTD-1-ADDR_FLAP error message indicates that a MAC address is moving consistently between different ports. This error message is only applicable on the Catalyst 2900XL and 3500XL switches. 

If users move from one Access Point (AP) to another and the MAC address shows up on a  different switch port, the error messages are displayed. These messages do not necessarily mean that there is a problem. They are displayed for informational purposes only.

It is part of normal operation for a  switch to re-learn the MAC address every time it is seen on a different port. This action always generates this message. The RTD-1-ADDR_FLAP system status messages should not necessarily be considered errors,  particularly on ports where there are APs attached.

For example, if there are APs attached to ports 3/4 and 3/5, and clients associated to those APs are roaming back and forth between the two APs, the MAC addresses of the clients are truly moving back and forth between those two switch ports. The status messages are accurate, and there is no cause for alarm.

Additional Information

Error Message

RTD-1-ADDR_FLAP [chars] relearning [dec] addrs per min

Explanation

Normally, MAC addresses are learned once on a port. Occasionally, when a switched network reconfigures, due to either manual or STP reconfiguration, addresses learned on one port are relearned on a different port. However, if there is a port anywhere in the switched domain that is looped back to itself, addresses will jump back and forth between the real port and the port that is in the path to the looped back port. In this message, [chars] is the interface, and [dec] is the number of addresses being learnt.

Recommended Action

Determine the real path (port) to the MAC address. Use the debug ethernet-controller addr command to see the alternate path-port on which the address is being learned. Go to the switch attached to that port. Note that the show cdp neighbors command is useful in determining the next switch. Repeat this procedure until the port is found that is receiving what it is transmitting, and remove that port from the network.

Problem Type

Error message

Products

Access point

Reference

Runtime diagnostic error messages

 

Sunday
Jan132013

End-of-Sale and End-of-Life Announcement for the Cisco Secure Access Control System 5.2 (CSACS-5.2) Software

Cisco announces the end-of-sale and end-of life dates for the Cisco Secure Access Control System 5.2 (CSACS-5.2) Software. The last day to order the affected product(s) is July 12, 2013. 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/en/US/prod/collateral/netmgtsw/ps5698/ps6767/ps9911/eol_C51-726115.html 

Table 1. End-of-Life Milestones and Dates for the Cisco Secure Access Control System 5.2 (CSACS-5.2) Software

 

Milestone

Definition

Date

End-of-Life Announcement Date

The date the document that announces the end of sale and end of life of a product is distributed to the general public.

January 11, 2013

End-of-Sale Date

The last date to order the product through Cisco point-of-sale mechanisms. The product is no longer for sale after this date.

July 12, 2013

Last Ship Date:
App. SW

The last-possible ship date that can be requested of Cisco and/or its contract manufacturers. Actual ship date is dependent on lead time.

October 10, 2013

End of SW Maintenance Releases Date:
App. SW

The last date that Cisco Engineering may release any final software maintenance releases or bug fixes. After this date, Cisco Engineering will no longer develop, repair, maintain, or test the product software.

July 12, 2014

End of New Service Attachment Date:
App. SW

For equipment and software that is not covered by a service-and-support contract, this is the last date to order a new service-and-support contract or add the equipment and/or software to an existing service-and-support contract.

July 12, 2014

End of Service Contract Renewal Date:
App. SW

The last date to extend or renew a service contract for the product.

October 8, 2015

Last Date of Support:
App. SW

The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete.

July 31, 2016

 

Wednesday
Jan022013

Cisco WLC Code 7.0.98.0 Deferred Status

It has come to my attention that code 7.0.98.0 was moved to "deferred status".

 

This is pretty relevant information as customers are still on this revision. Perhaps it may be because of the number of related bugs in this release ? Please comment if you have any details .. Thanks

 

 

http://software.cisco.com/download/release.html?mdfid=282600534&flowid=7012&softwareid=280926587&release=7.4.100.0&relind=AVAILABLE&rellifecycle=ED&reltype=latest