cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8489
Views
5
Helpful
11
Replies

CAPWAP messages WISM2 7.5.102

             Hi.

I have a question about a CAPWAP messages in my trap logs after upgrading my WISM2 to 7.5.102.

AP "xxxxxx", MAC: 34...... disassoiated previously due to Link Failure Uptime 4 days , 10 h... Reason: Capwap WTP Event request

My AP environment is 1142N attached thru WS-2960S switches. This message was not in my traplogs before upgarding to 7.5.102.

The switch and WAN environment is the same as before upgarding.

Thanks for any tips.

Regards

Johan Lindstrand

11 Replies 11

Hi,

I´m facing the same issue. I was thinking that it could be a problem on WAN links, but it only happens with 1142AP.

Did you solve it ? or did you downgrade your wism ? bug ?

Thanks

Eder

Even with this msg, does your 1142 works as normally  or do you have to reboot the AP to bring it back.

Possibly could be a bug. Not sure you are hitting one of this, but worth to check CSCui66891, CSCuj15277

HTH

Rasika

**** Pls rate all useful responses ****

Hi,

Thanks for you reply. I´m not sure if my radio stuck, what looks for me that AP lose conectivity for a brief moment with WLC and then recovery connectivity (flapping).

I have APs(same model) at same site without issues, and APs (same model) in others site with same behavior.

AP model LAP1141N

Below logs are from AP reboot process... however joining erros occurs several times during the day... and association time with controller keeps reseting (example: AP up time 1d / association time 15 min).

That instability to AP association creates WLAN instability, because my authentication is central.

*Mar  1 00:12:38.693: %CAPWAP-3-ERRORLOG: Selected MWAR 'WLC01'(index 0).

*Mar  1 00:12:38.693: %CAPWAP-3-ERRORLOG: Go join a capwap controller

*Dec 20 14:16:42.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 192.168.1.1 peer_port: 5246

*Dec 20 14:16:42.776: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 192.168.1.1 peer_port: 5246

*Dec 20 14:16:42.777: %CAPWAP-5-SENDJOIN: sending Join Request to 192.168.1.1

*Dec 20 14:16:42.786: %CAPWAP-3-ERRORLOG: Invalid event 10 & state 5 combination.

*Dec 20 14:16:42.786: %CAPWAP-3-ERRORLOG: CAPWAP SM handler: Failed to process message type 10 state 5.

*Dec 20 14:16:42.787: %CAPWAP-3-ERRORLOG: Failed to handle capwap control message from controller

*Dec 20 14:16:42.787: %CAPWAP-3-ERRORLOG: Failed to process encrypted capwap packet from 192.168.1.1

*Dec 20 14:16:42.897: Starting Ethernet promiscuous mode

*Dec 20 14:16:43.202: %LWAPP-4-CLIENTEVENTLOG: OfficeExtend Localssid saved in AP flash

*Dec 20 14:16:43.294: ac_first_hop_mac - IP:10.8.2.136 Hop IP:10.8.2.136 IDB:BVI1

*Dec 20 14:16:44.555: %CAPWAP-5-JOINEDCONTROLLER: AP has joined controller WLC01

Hi Eder,

1st: Please check ur WLC time settings.

2nd: I think u r hitting a  bug though its not related to to 7.5 : CSCud97983

https://tools.cisco.com/bugsearch/bug/CSCud97983

you must raise a TAC case and try to resolve ur issue.

Regards

Saravanan Lakshmanan
Cisco Employee
Cisco Employee

#Don't think you're hitting those mentioned bugs.

#It could be just the WAN link/intermediate device flapping and APs are not tolerant for it.

Suggested Workaround to increase the tolerance:

#Bump the AP retransmit count and interval to 8 & 5

#Enable AP fast heartbeat to 10 for local/flex APs.

Hi Saravanan,

I have a question about a CAPWAP messages in my trap logs after upgrading my WISM2 to 7.5.102.

Since it is happening since 7.5.102.0 upgrade, I still believe this should be a bug...:

Rasika

Hi Rasika

Regards to:

AP "xxxxxx", MAC: 34...... disassoiated previously due to Link Failure Uptime 4 days , 10 h... Reason: Capwap WTP Event request

It can be just cosmetic message or real AP disconnection. Traplog alone is not enough to tag it as bug, need AP logs ie., show log, more event.log(along with capwap debugs from affected AP and capwap debug on WLC for that AP) that showing what happened around the mentioned time. Mostly, it'll show retransmission exceeded to 5 and AP is getting disconnected. If we really don't see any AP disconnection and we're keep seeing this traplog then enable debug snmp trap to monitor how frequently it traps this message.

To the surprise, in general, have seen all the APs are dropping the packets all/most of the time but the APs that missed 5 consecutive packets(reaches the max configured retransmission) will only disassociate from the WLC. The other APs were lucky and got recovered within 5 drops and reset its count to 0. This explains the random AP disconnect and only one out of 5 AP from same switch disconnections.

Thanks

Saravanan

Hi Saravanan,

Thanks for that explanation +5 for you..

I hope your suggestion will help these guys to improve their situation with 1140 series.

Rasika

Thanks for your suggestions... I will try to apply it and check if solve my issue.

smithtrans1
Level 1
Level 1

Had the exact same issue running 7.6.110, down graded to 7.4.121 and having no issues at all, would recommend downgrading.

Please create a new thread.

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:

Review Cisco Networking products for a $25 gift card