Firefox collects certificates and will compare incoming certificates. If these certificates match but come from different sources Firefoxs throws the annoying certificate conflict message.

The HTTPS certificate on the WLC lives at MANAGEMENT-->HTTP-->CURRENT CERTIFICATE

Where the problem arrives, controllers shipped in batches appear to have the same identical certificates. This could be because they “blast” the firmware on the boxes in the manufacturing process.

An example of a factory provided certificate is below. First noticed there is no CN information and the validation date is way off.  This same certificate was on all the controllers in the batch.

The first controller you log into Firefox would accept and store this certificate. However, any controller you attempted to log into afterward would receive a certificate conflict.

So, how do we fix this issue? It's very simple …

After you configure your WLC with an IP address. Simply go to MANAGEMENT-->HTTP and click on regenerate certificate.  It will fill in a proper validation date and more specific CN information giving the certificate its true identity. However, this does require a controller reboot. So schedule accordingly. Below is a regenerated certificate.



Thats it! It should work now! Enjoy ....

  

I came across an oldie but goodie document. You can modify the driver behavior of the CB21 and PI21 AG cards.  

http://www.cisco.com/en/US/products/hw/wireless/ps4555/products_tech_note09186a008074fed9.shtml

Complete these steps in order to minimize delays when roaming from access point to access point when you use the CB21AG/PI21AG (802.11a/b/g wireless client adapter).

Note: These steps optimize roaming delays at the driver layer and are applicable to all authentication types. If 802.1x authentication is used, there might be additional optimizations possible, which are outside the scope of this document.

Note: Optimizing for faster roaming can potentially contribute to increased battery use and to reduced throughput.

1. Use ADU client software version 4.4 or later.

2. Set the BSS Aging Interval to 30, and set the Scan Valid Interval to 20.

   Complete these steps in order to set these two parameters via the Windows control panel:

   1. Go to Windows Explorer.

   2. Right-click My Network Places.

   3. Choose Properties from the drop-down list.

   4. Right-click Wireless Network Connection#, where # is the instance number of the Cisco CB21AG Wireless LAN adapter.

   5. Choose Properties from the drop-down list. The Wireless Network Connection Properties dialog box appears.

   6. Click Configure.

   7. Click the Advanced tab.

   8. Set the BSS Aging Interval to 30, and set the Scan Valid Interval to 20.

   These parameter values are the absolute lowest permitted values and should not be set any lower. The default values are 120 for BSS Aging Interval and 60 for Scan Valid Interval.

3. If your access point coverage permits it, configure the client profile in the ADU only to use the 5 GHz (802.11a) or 2.4 GHz (802.11b/g) band, not both. In order to configure the client profile, complete these steps:

   1. Launch the ADU client software.

   2. Click the Profile Management tab, highlight the profile of interest, and click Modify.

   3. Click the Advanced tab.

   4. Under Wireless Mode, uncheck the rates that you do not intend to use.

   5. If you do not use the ADU to manage the CB21AG, you must use registry settings in order to select the rates. Complete these steps:

      1. Choose Start > Run, and type regedit in order to launch the Registry Editor.

      2. Navigate to HKEY_LOCAL_MACHINE > System > CurrentControlSet > Control > Class > {4D36E972-E325-11CE-BFC1-08002bE10318}.

      3. Right-click the 4D36E972-E325-11CE-BFC1-08002bE10318 folder, and choose Find.

      4. Type NetBand in the search field in order to locate the NetBand variable. This is under an [instance] four-digit subkey that has a DriverDesc value of Cisco Aironet 802.11a/b/g Wireless Adapter.

         The NetBand REG_SZ variable is a bitmask of supported rates. By default this is 15. The values are:

         802.11a    0x01
         (not used) 0x02
         802.11b    0x04
         802.11g    0x08
         (not used) 0x10

         For example, in order to support only 11b and 11g rates, this is 0x04 + 0x08 = 0x0C = 12 decimal.

  

I want to take this opportunity to compare the obvious comparison of Apple’s antenna issue with the iPhone4 with a typical WiFi client analogy.

Apple released the iPhone 4 this week. There are early reports of antenna issues. Apparently the antenna design is flawed. Depending on how you hold the phone it could attenuate the signal. Steve Job’s  responded to emails , “just don’t hold it like that.” Way to go Jobs! This reminds me of the old analogy “A man goes to the doctor and says, Doc when I do this it really hurts. The Doc responds then don’t do that”.

Here is a classic example of a client issue. Customers reported issues almost immediately with cell reception with the new iPhone4. So what gives!? … They didn’t change the cell towers over night (access points)! Their phones changed (clients)!

If you read the reports they are using terms you as wireless engineer should be very familiar with, “attenuation, signal degradation, poor reception”. These are general terms we hear or use ourselves. Wireless is a 2-way communication. Often non wireless educated folks assume when there are issues it is the network and by this I mean the wireless access point or wireless infrastructure. They often don’t consider the wireless client.

I can think back to 2003’ish (or there around) when Intel released the Intel 2200b/g clients. This was around the time Cisco purchased Airespace. If you were in WiFi you surly remember this issue.

For those of you who weren’t, here is a quick recap. The Intel 2200 clients were flawed and were flawed for well over 2 months before Intel released a driver fix. The 2200 driver had big issues! When authenticated and in OFDM rates, Intel 2200 clients would not rate shift down to DSSS. As clients moved away from the access point the rate shifting stopped and the client would drop off the wireless. Of course back then customers always looked at the network. “Its got to be the AP”.  Especially the early adopters of the new Cisco/Airespace solution. Immediately people pointed blame at Cisco thinking there was an issue with the new controller solution they purchased from Airespace, which wasn’t the case.

Rumor has it Cisco did an assist with Intel with the replacement driver.

Fast forward to today…

WiFi engineers have more tools, training and hands on experience to quickly troubleshoot these issues. In fact, a good wireless engineer can determine if it’s a potential client issue with a quick wireless client capture and debug at the controller or AP. Manufactures of Wireless clients have also improved, especially Intel since they work closely with Cisco. You will find troubleshooting and diagnostics tools on the client side more today then ever before.

You have to remember wireless clients aren’t created equal. They all hear differently  (receive sensitivity) and have different transmit power levels and they all have their own operating behavior (when to roam, how they interpret signal strength, etc). Lets face it, some wireless clients are just crap.

Conclusion

If you are new to WiFi. Wireless clients have an equal part in the communication efforts and should be factored in when troubleshooting. In the case of the iPhone4 issue. The didn’t move the cell towers over night. The client changed!

Did you know Cisco and Intel have a joint program called E2E which enhances roaming !? Its called E2E, End-2-End.

Enhanced neighbor list request (E2E)—The End-2-End (E2E) specification is a Cisco and Intel joint program that defines new protocols and interfaces to improve the overall voice and roaming experience. It applies only to Intel clients in a Cisco Compatible Extensions environment. Specifically, it enables Intel clients to request a neighbor list at will. When this occurs, the AP forwards the request to the WLC. The WLC receives the request and replies with the current Cisco Compatible Extensions roaming sublist of neighbors for the AP to which the client is associated.

 You can also view this in the gui. 

WIRLESS-->CLIENTS-->DETAIL

Something you need to know if you plan to take any level of Cisco wireless certifications and more importantly in the field is the status LEDs on the Cisco Wireless CB21.

Easy way to remember:

Alternate blinking; think of SCANNING back and forth looking for a network

Both LEDs blinking slowly; means connected. Think of a pulse 

Both LEDs blinking fast; transfer data

The 2 other status LEDs you need to worry about are the POWER SAVE indications. Only the GREEN indicator is used.  

It is important to understand the difference between active and passive client scanning. Here is an overview ~ Wireless clients learn about available APs by scanning other IEEE 802.11 channels for available APs on the same WLAN/SSID. Scanning other IEEE 802.11 channels can be performed actively or passively as follows: 

Active scan—Active scanning occurs when the client changes its IEEE 802.11 radio to the channel being scanned, broadcasts a probe request, and then waits to hear any probe responses (or periodic beacons) from APs on that channel (with a matching SSID). The IEEE 802.11 standards do not specify how long the client should wait, but 10 ms is a representative period. The probe request frames used in an active scan are one of two types:

Directed probe—The client sends a probe request with a specific destination SSID; only APs with a matching SSID will reply with a probe response 

Broadcast probe—The client sends a broadcast SSID (actually a null SSID) in the probe request; all APs receiving the probe-request will respond, with a probe-response for each SSID they support.

During a channel scan, the client is unable to transmit or receive client data traffic. There are a number of approaches clients take to minimize this impact to client data traffic:

•Background scanning—Clients may scan available channels before they need to roam. This allows them to build-up knowledge of the RF environment and available APs so they may roam faster if it becomes necessary. Impact to client traffic can be minimized by only scanning when the client is not actively transmitting data, or by periodically scanning only a single alternate channel at a time (scanning a single channel incurs minimal data loss)

•On-roam scanning—In contrast with background, on-roam scanning occurs after a roam has been determined necessary. Each vendor/device may implement its own algorithms to minimize the roam latency and the impact to data traffic. For example, some clients might only scan the non-overlapping channels.

Typical Scanning Behavior

Although most client roaming algorithms are proprietary, it is possible to generalize the typical behavior.

Typical wireless client roam behavior consists of the following activities:

•On-roam scanning—This ensures clients have the most up-to-date information at the time of the roam.

•Active scan—An active scan is preferred over a passive scan, due to lower latency when roaming.
There are some informational attributes that may be used to dynamically alter the roam algorithm:

•Client data type—For example, voice call in progress

•Background scan information—Obtained during routine periodic background scans

Ways in which attributes can be used to alter the scan algorithm include: •Scan a subset of channels—For example, information from the background scan can be used to determine which channels are being used by APs in the vicinity. •Terminate the scan early—For example, if a voice call is in progress, the first acceptable AP might be used instead of waiting to discover all APs on all channels. •Change scan timers—For example, if a voice call is in progress, the time spent waiting for probe responses might be shortened during an active scan.

A wireless connection is a two way street. All to often Admins will ONLY look at what the Client reports from the AP (how well it hears the AP - client radio receive sensitivity). But have you considered how well the AP hears your client ??

We call this "client to access point". For a better understanding, think back when you were a kid and your dad yelled at you for not taking out the trash the night before trash day. Your dad is very loud -- to get his point across and everyone in the house (or neighborhood) can hear him! Perhaps, you answer back to your dad with a low, soft," I’m sorry, I forgot"... Your dad heard your response as a whisper .

In this example your dad is the access point @ 100mW  power (loud) and you are the wireless client @ 5mW power (low). You as the wireless client heard your dad loud and clear, but your dad didn't hear you so well. 

When you check your wireless supplicant and it registers -75dB, this is how loud you hear the AP (or your Dad in my example) - Again this is "access point-to-client".

But you want to see how well the AP (or your Dad in my example) hears you,  "client to-access point". . With a Cisco WLC you can perform a LINKTEST. This can be done in the GUI, WCS or CLI. Here is the command in the CLI. 

(Cisco Controller) >linktest 00:02:10:11:02:68 <-- Wireless NIC MAC Address

The beauty of Cisco CCX is that when enabled on both the client and controller it will report back both access point-to-client and client to-access point readings. 

When CCX v4 is enabled on both the controller and the client being tested, information similar to the following appears: 

CCX Link Test to 00:02:10:11:02:68.

     Link Test Packets Sent...................................... 20

     Link Test Packets Received................................. 10

     Link Test Packets Lost (Total/AP to Client/Client to AP).... 10/5/5

     Link Test Packets round trip time (min/max/average)......... 5ms/20ms/15ms

     RSSI at AP (min/max/average)................................ -60dBm/-50dBm/-55dBm

     RSSI at Client (min/max/average)............................ -50dBm/-40dBm/-45dBm

     SNR at AP (min/max/average)................................. 40dB/30dB/35dB

     SNR at Client (min/max/average)............................. 40dB/30dB/35dB

     Transmit Retries at AP (Total/Maximum)...................... 5/3

     Transmit Retries at Client (Total/Maximum).................. 4/2

     Transmit rate:  1M   2M   5.5M   6M   9M  11M 12M 18M   24M   36M  48M  54M  108M

     Packet Count:   0     0     0    0    0    0   0   0     0     2    0   18     0

     Transmit rate:  1M   2M   5.5M   6M   9M  11M 12M 18M   24M   36M  48M  54M  108M

     Packet Count:   0     0     0    0    0    0   0   0     0     2    0    8     0

When CCX v4 is not enabled on either the controller or the client being tested, fewer details appear:

Ping Link Test to 00:02:10:11:02:68.

        Link Test Packets Sent.......................... 20

        Link Test Packets Received...................... 20

        Local Signal Strength........................... -58dBm

        Local Signal to Noise Ratio..................... 29dB

You can also config the default "linktest" settings:

(Cisco Controller) config>linktest ?
frame-size     Configures linktest frame-size for each packet.
number-of-frames Configures number of frames to send for linktest.

Again, another reason WHY a proper wireless site survey is needed and why you need to always consider your lowest common denominator (client) for wireless reliability. If your dad (AP) is always yelling and you (client) always whisper back you are bound to have COMMUNICATION problems. Vocera is one of these such applications.

This evening I did benchmark testing on a wireless client which I want to share. I was working on a Samsung NQ unit with an integrated Atheros AR5007EG wireless NIC. I was told by the user the client would lose connectivity and had a slow network connection when connected. So I go through the normal check list, do I have signal for data- check, is the noise floor low -  check, do I have expected PHY data rates - check.  But this test was conducted right under the access point.

As I get distance between the client and the access point (also know as free space path loss) I see the wireless client signal strength nose dive hard.

So I check all the normal things, antenna connection, driver update, NIC config. All these check out OK. So I do side by side benchmark testing with a known good wireless NIC and notice an almost a 20 dBm difference. As you know all wireless NICs will hear (receive sensitivity) differently. But with advancements today, you will see most NICs are all generally in the same ballpark. I say that lightly and tip toeing.

Below is a snap shot of both clients, Samsung has the Atheros AR5007EG and my laptop Intel2915AG. Both clients are side by side at the same distance from the access point. I did further testing by adding another laptop for consistency. I also added a Cisco Linksys WUSB600N to the Samsung.

I don’t have another Samsung to test and it’s not my unit so I wont be taking it apart to investigate further. But the moral of the story, never ever discount the client. Each client will hear differently, and soemtimes a client may have issues or be a poor design.

I am often asked, "Is there away to disable a wireless NIC when I connect my laptop into a wired connection?". The answer is, YES!  In fact it is advisable to only have one NIC on at a time. When both NICs are enabled *Wired and Wireless" PCs can become confused. In fact there is a "costing" that is suppose to happen when you have both NICs enabled, but this doesn’t always work well and most of time doesn’t work at all!.

There is security concerns as well. Suppose you are wired into a corperate network and you have your wireless NIC on. Now suppose someone has a rogue access point and your PC connects to it. Once you are connected to the rogue access point the rogue AP can pass you a DHCP and you will then have a layer 3 adjacency with the attacker. It is possible one could then exploit your laptop and breach over into the corperate network.I have never tested this, but perhaps in the near future I may give it a spin.There are a number of options you have to accomplish this ... I will share with you 4 of them

1) BIOS change

2) Intel Supplicant

3) Juniper Odyssey Supplicant

4) Cisco Cssc Supplicant

1) BIOS - Newer PCs come with BIOS options that allow you to modifiy how your wireless and wired NIC operate when both connections are present. For example if you own a HP laptop and you drop into the BIOS you will see LAN/WLAN switching. When enabled, your wireless NIC will disable itself when plugged into a wired connection.

The downside to the BIOS option, suppose you have to roll out hundreds of PCs. Making BIOS changes isn’t as easy as just making a change to an image.

 2) Intel Supplicant - Intel is everywhere and its likely you have Intel wireless NICs in most of your PCs. Intel calls this functionality  ADAPTER SWITCHING.

Click on your Intel wireless icon in your system tray--> Tools --> Admin Tools --> Application Settings --> Adapter Switching

3) Juniper Odyssey  Supplicant - This supplicant is one that you have to pay for, but I am a big fan of the juniper client, I've used it for years and allows for easier administration of devices. Juniper calls this functionality WIRELESS SUPPRESSION.

Click on your Juniper wireless icon in your system tray--> Tools --> Options --> Wireless Suppression 

4) Cisco CSSC - If you use CSSC you will find the NIC option under Advance Settings.

From client mode--> Advance settings -->Simultaneous Connection portion of the Security Settings pane --> Only allow one connection at a time to restrict the Client to creating only a single connection (prevent multihomed configurations).Note: the preference of the media type is fixed for wired/Ethernet, when both types are available within a network.

Enjoy!

Did you know when you associate to an access point your wireless NIC reports to the OS a 4201 code? Or, when your wireless NIC loses connectivity it reports a 4202 code?

In this nugget, we will review the System Event Log for a wireless NIC. More specifically the 4201 and 4202 event code. I will also reproduce these event code in our lab.... Just another tool to have in the handbag when troubleshooting! Enjoy