cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1011
Views
0
Helpful
11
Replies

4.0.217.0

d-berlinski
Level 1
Level 1

Has anyone had any issues post installation of this version. Specifically, APs randomly disassociating/associating as a result of a max re-transmission event.

11 Replies 11

Darren Ramsey
Level 4
Level 4

Running 217 in our Data Center for about 24 hours. Have not seen any issues yet. Mix of AP1230 SSC and AP1242 MIC. Have not baked enough yet to put in production on WISM controllers.

Thanks for the info. I have about the same mix of AP's as you do but use the 4400 controllers. One problem I am having is that I am unable to suppress decrypt errors and they are slowly filling up my logs. Please keep me posted on any issues you may see.

Post a snip of your errors and I'll see if I have any. I typically run new code on the 4400's first and then migrate to WISM, so right now 217 is running on a 4402.

Here are the log entried I am seeing...

24 Thu Apr 26 07:27:15 2007 AP's Interface:0(802.11b) Operation State Up: Base Radio MAC:00:14:1c:cf:a7:50 Cause=Unknown

25 Thu Apr 26 07:27:13 2007 AP Associated. Base Radio MAC: 00:14:1c:cf:a7:50

26 Thu Apr 26 07:26:57 2007 Decrypt errors occurred for client 00:0d:29:2c:8c:4a using unknown key on 802.11b/g interface of AP 00:14:1c:01:05:20

27 Thu Apr 26 07:26:57 2007 AP Disassociated. Base Radio MAC:00:14:1c:cf:a7:50

28 Thu Apr 26 07:26:57 2007 AP's Interface:1(unknown type) Operation State Down: Base Radio MAC:00:14:1c:cf:a7:50 Cause=Max Retrasmission

29 Thu Apr 26 07:26:57 2007 AP's Interface:0(802.11b) Operation State Down: Base Radio MAC:00:14:1c:cf:a7:50 Cause=Max Retrasmission

Understand that I have 2 controllers running this code with the same issues and they manage approximately 50 APs. This event occurs at random times and on random APs. Cisco needs a sniffer trace of the AP and debugs on the controller to be able to help me. I need to be psychic at this point.

Have not seen that in 217, but I did see a similar action in 206 (CSCsh50966), supposed to be fixed in 216. You might try adding a static ARP per the bug notes to your switch interface on the controller's ap-manager VLAN just to test. Is HSRP running on the ap-manager vlan? When the AP disassociates, do you loose any pings to the AP? Is the AP able to rejoin or does it reload?

TAC suggested i put in a static arp but i looked at the arp table right after an event and the entry had been there for some time. I guess I can give it a try. HSRP is running on the ap-manager interface. I'm not sure if I lose any pings (hard to catch the event). I don't believe it does, it just does a discovery/join and is back up in 30 sec or so. I think that only the radio becomes unavailable.

I've seen some HSRP bugs but seems like they do not cause packet loss. Anything in the console log on the AP? Did TAC give you any LWAPP debug commands to execute on the AP console?

Here's what I got off of an AP. There are actually 2 events. It's hard to do the debugs on the controller due to the randomness of the events.

Apr 23 19:41:37.949: LWAPP_CLIENT_ERROR_DEBUG: Retransmission count for packet exceeded more than max(RRM_DATA_REQ

, 1)

*Apr 23 19:41:37.949: LWAPP_CLIENT_ERROR_DEBUG: GOING BACK TO DISCOVER MODE

*Apr 23 19:41:37.950: %LWAPP-5-CHANGED: LWAPP changed state to DISCOVERY

*Apr 23 19:41:37.950: %LWAPP-5-CHANGED: LWAPP changed state to DISCOVERY

*Apr 23 19:41:37.951: bsnInitRcbSlot: slot 1 has NO radio

*Apr 23 19:41:37.959: bsnUnlockDevice: not bring radio up: radio 1 is in admin disable state

*Apr 23 19:41:37.962: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down

*Apr 23 19:41:37.964: LWAPP_CLIENT_ERROR: lwapp_name_lookup - Could Not resolve CISCO-LWAPP-CONTROLLER.***

*Apr 23 19:41:37.965: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset

*Apr 23 19:41:37.977: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up

*Apr 23 19:41:47.969: %LWAPP-5-CHANGED: LWAPP changed state to JOIN

*Apr 23 19:41:47.971: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to administratively down

*Apr 23 19:37:36.915: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down

*Apr 23 19:37:37.836: %LWAPP-5-CHANGED: LWAPP changed state to CFG

*Apr 23 19:37:37.881: %LWAPP-5-CHANGED: LWAPP changed state to DOWN

*Apr 23 19:41:45.000: %LWAPP-5-CHANGED: LWAPP changed state to UP

*Apr 23 19:41:45.197: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset

*Apr 23 19:41:45.330: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up

*Apr 23 19:41:46.330: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

*Apr 23 21:18:36.329: LWAPP_CLIENT_ERROR_DEBUG: Retransmission count for packet exceeded more than max(ECHO_REQUEST

, 1)

*Apr 23 21:18:36.329: LWAPP_CLIENT_ERROR_DEBUG: GOING BACK TO DISCOVER MODE

*Apr 23 21:18:36.330: %LWAPP-5-CHANGED: LWAPP changed state to DISCOVERY

*Apr 23 21:18:36.330: %LWAPP-5-CHANGED: LWAPP changed state to DISCOVERY

*Apr 23 21:18:36.330: bsnInitRcbSlot: slot 1 has NO radio

*Apr 23 21:18:36.339: bsnUnlockDevice: not bring radio up: radio 1 is in admin disable state

*Apr 23 21:18:36.342: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to down

*Apr 23 21:18:36.344: LWAPP_CLIENT_ERROR: lwapp_name_lookup - Could Not resolve CISCO-LWAPP-CONTROLLER.****

*Apr 23 21:18:36.344: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset

*Apr 23 21:18:36.356: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up

*Apr 23 21:18:46.349: %LWAPP-5-CHANGED: LWAPP changed state to JOIN

*Apr 23 21:18:46.350: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to administratively down

*Apr 23 21:15:44.915: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down

*Apr 23 21:15:45.833: %LWAPP-5-CHANGED: LWAPP changed state to CFG

*Apr 23 21:15:45.877: %LWAPP-5-CHANGED: LWAPP changed state to DOWN

*Apr 23 21:18:46.000: %LWAPP-5-CHANGED: LWAPP changed state to UP

*Apr 23 21:18:46.026: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset

*Apr 23 21:18:46.036: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up

*Apr 23 21:18:47.036: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

I can duplicate the (ECHO_REQUEST,1) message by blocking connectivity from the AP to the ap-manager interface. The (RRM_DATA_REQ,1) message is unfamiliar but appears to be rooted in the power and channel management system. Sorry, I have no further suggestions to make. I guess it's up to TAC to figure this one out. Please keep us posted on how this plays out.

I see the decrypt error when a client renews its session after reaching the idle timeout or wlan session timeout. Extend the timeout and the error's will go away.

I have a WLC 4402 with 45 1010 APs

now I'm running WLC version 4.1.185.0 and there is a problem: APs randomly disassociate from WLC - it happens usually one-two times a day

with an errors:

AP's Interface:1(802.11b) Operation State Up: Base Radio MAC:00:0b:85:xx:xx:xx Cause=Unknown

AP's Interface:1(802.11b) Operation State Down: Base Radio MAC:00:0b:85:xx:xx:xx Cause=Max Retrasmission

I've tried the suggested solutions putting a static ARP entry and moving AP's to different VLAN but nothing solves the problem until the AP's physicly rebooted - until next time

and now that you mention this, I think the problem begin just after upgrading to 4.0.217.0

Are there any specific requirements for newer versions?

Still looking for an answer....

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: