cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
76150
Views
31
Helpful
8
Replies

Help me : Problem with WLC and AP

a.auvinet
Level 1
Level 1

Hi,

We have a few AP on our network which work fine.

But, those which are behind our fw don't work.

LAN WI-FI with WLC  <>--------Lan Routed---with Ap (Ok) ------------------

                                 <> -------FW <> Vlan behind Fw and APs not work fine.

WLC = Software Version                 7.0.220.0

Logs  on WLC :

spamApTask2: Jun 04 11:49:59.494: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 172.37.251.71

*spamApTask1: Jun 04 11:48:49.323: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 172.37.251.71

*spamApTask2: Jun 04 11:47:39.149: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 172.37.251.71

*spamApTask1: Jun 04 11:46:28.978: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 172.37.251.71

*spamApTask2: Jun 04 11:45:18.806: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 172.37.251.71

*spamApTask1: Jun 04 11:44:08.632: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer 172.37.251.71

*osapiBsnTimer: Jun 04 11:43:51.235: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:2202 Failed to complete DTLS handshake with peer 172.37.251.71

debud dtls :

*spamApTask1: Jun 04 11:22:42.434: 64:a0:e7:5f:e5:70 record=Alert epoch=0 seq=2

*spamApTask1: Jun 04 11:22:42.435: 64:a0:e7:5f:e5:70 SSL_do_handshake: SSL_ERROR_SSL while communicating with 172.37.251.71 : (null)

*spamApTask1: Jun 04 11:22:42.435: 64:a0:e7:5f:e5:70  Requested by openssl_dtls_process_packet

*spamApTask1: Jun 04 11:22:42.435: dtls_conn_hash_delete: Deleting hash for Local 172.18.3.2:5246  Peer 172.37.251.71:52258

*spamApTask1: Jun 04 11:22:42.435: 64:a0:e7:5f:e5:70 DTLS Connection 0x145520d0 closed by controller

*spamApTask1: Jun 04 11:22:42.436: dtls_conn_hash_search: Searching hash for Local 172.18.3.2:5247  Peer 172.37.251.71:52258

Cordially,

8 Replies 8

kangupta
Cisco Employee
Cisco Employee

HI,

- On the fw-

a. Make sure the FW is open for udp 5246 and 5247 ports required for the capwap process.

If this is a cisco ASA, you can set up ingress and egress packet captures to see what packets enter and leave the FW for this AP-

cap capin interface match udp any

cap capout interface match udp any

**match captures bidirectional flow for the interesting traffic.

b. Check the logs on the firewall for any drops.

c. cap capdrop type asp-drop all
This will tell you if the pkt was dropped and the reason for the drop

d. You can run the packet-tracer command on the firewall tracking this udp flow-

e.g. packet-tracer input inside udp 3.3.3.3 1212 2.2.2.3 5246 detailed

- What AP model is this? Is it the same AP that connects to the controller if there is no fw in the path?

- Does it use MIC or SSC cert? If SSC, make sure you have SSC checked and you will need to manually enter the hash for the AP on the controller under AP Authorization List -

Security> AP Policies

You can get the hash of the AP (f you dont have it) by enabling the following debug on the controller

debug pm pki enable

Other controller debugs for the AP-

debug mac address

debug capwap error enable

debug capwap events enable

- What about AP console log? Do you have access to that?

fbarboza
Level 4
Level 4

Hi,

Here is a very usfull link for troubleshooing an AP not joining the WLC, the debug commands can be LWAPP or CAPWAP depending on the code.

http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a00808f8599.shtml

Hi,

Sorry for my late.

I check as soon as possible.

Cdlt,

Saravanan Lakshmanan
Cisco Employee
Cisco Employee

DTLS handshake is between discovery and join process. Discovery is passing but dtls handshake is not successful to initiate join process.

what WLC used, does the AP has access to both AP manager(if 4400) & management interface of WLC.

what's ap join status showing.

Not applicable

Finally just change the year on the controller to 5 years back and set.. now all the cert expired APs will be joining there.. after the APs are joined just put the year back to current.

=============

Conditions:This symptom will occur after 10 years of the device manufacturing date.
The oldest APs (1120, 1130, 1230, 1310 series) with MICs were manufactured in July 2005,
so those APs will be unable to join AireOS controllers starting in July 2015.

This problem also affects WLCs approximately 10 years after manufacturing date.

For APs using Self-Signed Certificates (SSCs) that were generated by the Upgrade Tool, the symptom will occur on January 1, 2020.

SN: ALP112706LC
The AP chassis SN is in the first section of the output, for example: PID: AIR-LAP1131AG-E-K9, VID: V01, SN: FCZ1128Q0PE
The serial number format is: "LLLYYWWSSSS"; where "YY" is the year of manufacture and "WW" is the week of manufacture. The date code can be found in the 4 middle digits of the serial number.
Manufacturing Year Codes:
01 = 1997 06 = 2002 11 = 2007 16 = 2012
02 = 1998 07 = 2003 12 = 2008 17 = 2013
03 = 1999 08 = 2004 13 = 2009 18 = 2014
04 = 2000 09 = 2005 14 = 2010
05 = 2001 10 = 2006 15 = 2011

Manufacturing Week Codes:
1-5 : January 15-18 : April 28-31 : July 41-44 : October
6-9 : February 19-22 : May 32-35 : August 45-48 : November
10-14 : March 23-27 : June 36-40 : September 49-52 : December

Example: SN FCZ1128Q0PE has year code 11, meaning it was manufactured in 2007. The week code is 12, meaning it was manufactured in March.
The SN can also be found using Prime Infrastructure Reporting to find SNs for all of the APs.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq19142
Workaround:
Code with fix is available in CCO for 7.0, 7.4, 8.x

For 7.6, you may contact TAC for escalation code, although it is recommended to move to 8.0 for future support

Recovery for APs in a failed scenario:
NOTE: this workaround should be used only in order to allow APs with expired certificates to join the WLC for long enough to upgrade the software.

If the certificates have expired, disable NTP, then change the WLC clock time to a recent earlier time when the certificates were still valid. If you set the clock back too far, newer APs may not be able to join. Once the software has been upgraded, and the affected APs have joined, the WLC clock should be reset to the valid time.

Solution:
Cisco has released AireOS 7.0.252.0, and will release rebuilds for 7.4 in April 2015 and 8.0 in June 2015.

These rebuilds will implement a new CLI command to disable on the WLC
the lifetime validity checks for MICs and SSCs. By default, the command will be disabled, i.e. APs with expired MICs and SSCs will not be able to join.
After upgrading to the new rebuild, use the new command to disable the
lifetime validity check, allowing APs with MICs or SSCs older than 10 years to
join.

For 7.0.252.0:
(WLC)>config ap lifetime-check {mic|ssc} enable

For 7.4.140.0 and later:
(WLC)>config ap cert-expiry-ignore {mic|ssc} enable

This really helped me. Thank you!

Thanks so much for this post i had the same problem with a %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer and after 1 month of research i came to this post and change the date on my my WLC 2112 and  my ap AIR-LAP-1142N  is joining with no problem. Thanks a lot for this POST

Don't forget to update the software and issue the commands stated above, so they will not be stranded on the next reboot.
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