Random Pics (Bangalore)

Random Pics

PMKSA in 802.11i

In 802.11i, a Pairwise Master Key (PMK) is the key that results from a successful authentication between a wireless station and an access point. The PMK is generally derived by the wireless station and the back-end EAP/AAA authentication server after a successful EAP authentication and sent to the wireless access point in a AAA message (In the context of EAP/AAA, the PMK is called Master Session Key 'MSK') secured using long-term security association between the authentications server and the access point.

The PMK is stored in the station and the access point with associated context information such as the access point's MAC addresses, the lifetime of the PMK and a unique identifier called PMKID. The collection of this information is called PMK Security Association (PMKSA). The PMKID is computed by applying a hash function (HMAC-SHA1-128) to the concatenation of the PMK, the label `PMK Name', the access point's MAC address (MAC_AP) and the station's MAC address (MAC_STA).

PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

When associating with an access point, the station determines if it has a valid PMK with the target access point by checking if it has a PMKSA that matches the target access point's MAC address. If such PMK does not exist, the station and the access point perform authentication using EAP. If the station determines that it shares a PMK with the target AP, then the station proposes the use of the PMK by including the PMKID in the RSN Information Element of the (Re)Association Request message. Upon reciept of a (Re)Assiciation Request with a PMKID, the access point checks whether is has a valid PMKSA with the same PMKID. If so, it begins the four-way handshake exchange using the negotiated PMKSA.

Taken from:

http://www.codealias.info/technotes/the_pairwise_master_key_security_association

PMK Cache / Static Key Caching

Everything is going mobile now, it was a time when man used building size machine for simple calculation. Now devices getting more compact and in the new Era of IoE we need mobility. 

With mobility we are also aiming for uninterrupted connectivity, normal data application still work well however issues are seen with time sensitive voice/vedio applications when client devices move from one AP to another. They work well with open authentication methods, however when it comes to security the clients need to authentication whenever they roam to new AP.

There are different methods in which we try to achieve security and un-interrupted services for the client devices. We use couple of caching mechanism in a way that once the client gets authenticated, they can regenerate the encryption keys doing the 4 way handshake without doing a complete authentication again. Following are couple of methods:

1. PMK Cache / Static Key Caching : In SKC, the client stores each Pairwise Master Key ID (PMKID) against a Pairwise Master Key Security Association (PMKSA). When a client finds an AP for which it has the PMKSA, it sends the PMKID in the association request to the AP. If the PMKSA is alive in the AP, the AP provides support for fast roaming. In SKC, full authentication is done on each new AP to which the client associates and the client must keep the PMKSA associated with all APs. For SKC, PMKSA is a per AP cache that the client stores and PMKSA is precalculated based on the BSSID of the new AP.







By default the Windows 7 machine have PMK caching enabled following is the snapshot on where you can confirm the setting.

SKC limitation on Cisco Wireless Infrastructure:

Restrictions for Sticky Key Caching
The controller supports SKC for up to eight APs per client. If a client roams to more than 8 APs per session, the old APs are removed to store the newly cached entries when the client roams. We recommend that you do not use SKC for large scale deployments.
SKC works only on WPA2-enabled WLANs.
SKC does not work across controllers in a mobility group.
SKC works only on local mode APs.



2. Pre-Authentication: Pre-authentication is a feature that allows a mobile device to authenticate with other Access  Points (APs) that it may roam to in the future. To achieve this, the  mobile station authentication frames are forwarded by the AP to the target AP, over the wired network. The first time a client associates to the network, the client must complete a full authentication. However, if the client knows where it will roam, the client can pre-authenticate to a new AP.


Pre-authentication is similar to IEEE 802.1X. The client performs an authentication through the new AP, which acts as the authenticator. The pre-authentication packets traverse through the existing AP to the new AP. Once the authentication is successful, the pre-authentication completes with a PMK security association established between the client and the new AP.






For pre-authentication to happen both client and AP have to support pre-authentication. That we can see in the beacon frame of the AP.


3. OKC(Opportunistic Key caching/Proactive Key Caching): Opportunistic Key Caching (OKC) is a similar technique, not defined by 802.11i, available for authentication between multiple APs in a network where those APs are under common administrative control. A deployment with multiple APs under the control of a single controller is one such example. Using OKC, a station roaming to any AP in the network will not have to complete a full authentication exchange, but will instead just perform the 4-way handshake to establish transient encryption keys. 

Although OKC is not a part of the 802.11i standard, several wireless vendors have adopted the technique and have achieved interoperability. Most notably, Microsoft has provided support for OKC in the Windows XP and Vista 802.1x supplicant.

The opportunistic PMK pre-caching technique works as follows: when a wireless station enters a mobility zone, it creates a new PMKSA (PMKSA_0) with the first access point after performing a full EAP authentication. The controller of the mobility zone retrieves the PMKSA_0 from the first access point and forwards it to other access points in the mobility zone. Each access point recieving the PMKSA_0 from the controller, uses it to derive a new PMKSA (PMKSA_i). These PMKSA_i are derived as follows. The PMKSA's PMK is the same as the original PMKSA_0 recieved from the controller. The PMKSA's PMKID (PMKID_i) is built as follows :

PMKID_i = HMAC-SHA1-128(PMKID_0, "PMK Name" | MAC_AP_i | MAC_STA) (1)

When the station moves to a new access point, it computes PMKID_i as specified in Eq.(1), then includes it in the (Re)Association Request message. If the access point is part of the same mobility zone, it will find a PMKSA that matches the PMKID_i presented by the station and use PMK_0 for the four-way handshake.

This way, a mobile station roaming between access points in the same mobility zone does need to perform a full EAP authentication each time it associates with a new access point. The same PMK will be used to create PMKSAs in all access points part of the same mobility zone.

A shortcoming of the opportunistic PMK pre-caching scheme is that it does not enable fast handoffs between mobility zones. When a station moves to a new mobility zone, a full EAP authentication must take place. This reduces the efficiency of the Opportunistic PMK pre-caching since its adoption does not completely eliminate lengthy handoffs.

Cisco Wireless - Understand CAPWAP/LWAPP

What is CAPWAP:

As Wikipedia defines: The Control And Provisioning of Wireless Access Points (CAPWAP) protocol is a standard, interoperable networking protocol that enables a central wireless LAN Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs), more commonly known as Wireless Access Points. 

The protocol specification is described in RFC 5415.

CAPWAP is based on LWAPP (Lightweight Access Point Protocol). The state machine of CAPWAP is similar to LWAPP's, but with the addition of a full Datagram Transport Layer Security (DTLS) tunnel establishment. 

Evolution of CAPWAP: ===============

Basic differences between LWAPP and CAPWAP:

LWAPP:
=========

Fragmentation/Re-assembly:                                 Relies on IpV4
Path-MTU Discovery:                                           Not supported
Control Channel Encryption between AP and WLC:     Yes (using AES)
Data Channel Encryption between AP and WLC:        No
UDP Ports:                                                         12222, 12223

CAPWAP: ========== Fragmentation/Re-assembly:                                 CAPWAP itself does both Path-MTU Discovery:                                           Has a robust P-MTU discovery mechanism,                                                                         can also detect dynamic MTU changes. Control Channel Encryption between AP and WLC:     Yes (Using DTLS) Data Channel Encryption between AP and WLC:        Yes (using DTLS) UDP Ports:                                                         5246 (ctrl) 5247 (data) More on LWAPP: ============

LWAPP is a generic protocol with a binding definition for the 802.11 wireless LAN protocol. LWAPPdefines how access points communicate with wireless LAN controllers. This communication can be either by means of native, Layer 2 Ethernet frames, or Layer 3 via IP packets. In the Cisco LWAPP implementation, Layer 3 LWAPP packets are carried in UDP packets.

LWAPP messages carry one of two types of payload:

•LWAPP Data Messages, which are encapsulated and forwarded data frames sent from and to wireless clients.

•LWAPP Control Messages, which are management messages exchanged between the wireless LAN controller and the access point.

The LWAPP protocol header contains a control bit (the C-Bit) which identifies data and control packets. When Layer 3 LWAPP is used, the LWAPP data and control packets are sent to separate UDP ports. Because both data and control frames can be fragmented, the payload LWAPP data or control message can be fragmented.

LWAPP Layer 2 Transport Mode:
========================


LWAPP communication between the access point and the wireless LAN controller can be in native, Layer 2 Ethernet frames. This is known as Layer 2 LWAPP mode. 

The LWAPP Control and Data messages are encapsulated in Ethernet frames using Ethertype "0xBBBB". In Layer 2 LWAPP mode, although the access points may get an IP address via DHCP, all LWAPP communications between the access point and WLC are in Ethernet encapsulated frames, not IP packets. The access points must be on the same Ethernet network as the WLC. For this reason, Layer 2 LWAPP mode may not be suitable for scalability purposes in most deployments. Furthermore, Layer 2 mode is supported only by the Cisco 410x and 440x series of WLCs and the Cisco 1000 series access points. Layer 2 LWAPP is not supported by lightweight Cisco Aironet 1200, 1252, 1130AG, or 1240AG access points, or the Cisco 2006, WiSM, or WLCM series WLCs.

Data packets between wireless LAN clients and other hosts are typically IP packets.

When Host A sends a packet to Host B, the following sequence occurs:

•An IP packet is transmitted by Host A over the 802.11 RF interface after being encapsulated in an 802.11 frame with Host A's MAC address as the source address and the access point's radio interface MAC address as the destination address.

•At the access point, the access point adds an LWAPP Header to the frame with the C-Bit set to zero and then encapsulates the LWAPP Header and 802.11 frame into an Ethernet frame. This Ethernet frame uses the access point Ethernet MAC address as the source MAC address and the WLC MAC address as the destination MAC address.

•At the WLC, the Ethernet and LWAPP headers are removed and the original 802.11 frame is processed.

•After processing the 802.11 MAC Header, the WLC extracts the payload (the IP packet), encapsulates it into an Ethernet frame, and then forwards the frame onto the appropriate wired network, typically adding an 802.1Q VLAN tag.


•The packet then travels through the wired switching and routing infrastructure to Host B.


LWAPP Layer 3 Transport Mode:
=========================


Layer 3 LWAPP Control and Data messages are transported over the IP network in UDP packets. This transport architecture is inherently more flexible and scalable than Layer 2 LWAPP and is the generally preferred solution. Layer 3 LWAPP is supported on all Cisco WLC platforms and lightweight access points.

The LWAPP Control and Data messages are encapsulated in UDP packets that are carried over the IP network. The only requirement is established IP connectivity between the access points and the WLC. The LWAPP tunnel uses the access point's IP address and the WLC's AP Manager interface IP address as endpoints. On the access point side, both LWAPP Control and Data messages use an ephemeral port that is derived from a hash of the access point MAC address as the UDP port. On the WLC side, LWAPP Data messages always use UDP port 12222. On the WLC side, LWAPP Control messages always use UDP port 12223.

The mechanics and sequencing of Layer 3 LWAPP are similar to Layer 2 LWAPP except that the packets are carried in UDP packets instead of being encapsulated in Ethernet framesThe mechanics and sequencing of Layer 3 LWAPP are similar to Layer 2 LWAPP except that the packets are carried in UDP packets instead of being encapsulated in Ethernet frames.

When Host A sends a data packet to Host B, the following sequence occurs:

•The packet is transmitted by Host A over the 802.11 RF interface. This packet is encapsulated in an 802.11 frame with Host A's MAC address as the source address and the access point's radio interface MAC address as the destination address.

•At the access point, the access point adds an LWAPP Header to the frame with the C-Bit set to zero and then encapsulates the LWAPP Header and 802.11 frame into a UDP packet that is transmitted over IP. The source IP address is the access point's IP address and the destination IP address is the WLC's AP Manager Address. The source UDP port is the ephemeral port based on a hash of the access point MAC address. The destination UDP port is 12222.

•The IP packet is encapsulated in Ethernet as it leaves the access point and transported by the switching and routed network to the WLC.

•At the WLC, the Ethernet, IP, UDP, and LWAPP headers are removed from the original 802.11 frame.

•After processing the 802.11 MAC header, the WLC extracts the payload (the IP packet from Host A), encapsulates it into an Ethernet frame, and then forwards the frame onto the appropriate wired network, typically adding an 802.1Q VLAN tag.


•The packet is then transmitted by the wired switching and routing infrastructure to Host B.


Layer 2 LWAPP WLC Discovery Algorithm:
============================

LWAPP communication between the AP and the WLC can be in native, Layer 2 Ethernet frames. This is known as Layer 2 LWAPP mode. Although defined in the RFC draft, Layer 2 LWAPP mode is considered deprecated in Cisco's implementation. 

This is the first method that a LAP uses to discover a WLC. The LAPs that support Layer 2 LWAPP mode broadcast a LWAPP discovery request message in a Layer 2 LWAPP frame. If there is a WLC in the network configured for Layer 2 LWAPP mode, the controller responds with a discovery response. The LAP then moves to the join phase.

This debug lwapp events enable command output shows the sequence of events that occur when a LAP using Layer 2 LWAPP mode registers with the WLC:



Thu Sep 27 00:24:25 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST 
from AP 00:0b:85:51:5a:e0 to ff:ff:ff:ff:ff:ff on port '2'
Thu Sep 27 00:24:25 2007: 00:0b:85:51:5a:e0 Successful transmission of 
LWAPP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 2
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Received LWAPP JOIN REQUEST 
from AP 00:0b:85:51:5a:e0 to 00:0b:85:48:53:c0 on port '2'
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 AP ap:51:5a:e0: 
txNonce  00:0B:85:48:53:C0 rxNonce  00:0B:85:51:5A:E0 
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 LWAPP Join-Request MTU path from 
AP 00:0b:85:51:5a:e0 is 1500, remote debug mode is 0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Successfully added NPU Entry for 
AP 00:0b:85:51:5a:e0 (index 48)Switch IP: 0.0.0.0, Switch Port: 0, intIfNum 2, 
vlanId 0AP IP: 0.0.0.0, AP Port: 0, next hop MAC: 00:0b:85:51:5a:e0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Successfully transmission of 
LWAPP Join-Reply to AP 00:0b:85:51:5a:e0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Register LWAPP event for 
AP 00:0b:85:51:5a:e0 slot 0
Thu Sep 27 00:24:40 2007: 00:0b:85:51:5a:e0 Register LWAPP event for 

AP 00:0b:85:51:5a:e0 slot 1


Layer 3 LWAPP WLC Discovery Algorithm:
==============================

The LAPs use the Layer 3 discovery algorithm if the Layer 2 discovery method is not supported or if the Layer 2 discovery method fails. The Layer 3 discovery algorithm uses different options in order to attempt to discover WLCs. The Layer 3 LWAPP WLC discovery algorithm is used to build a controller list. After a controller list is built, the AP selects a WLC and attempts to join the WLC. The LWAPP Layer 3 WLC discovery algorithm repeats until at least one WLC is found and joined.


Boadcast Method:
=============

After the LAP gets an IP address from the DHCP server, the LAP begins this discovery process:

The LAP broadcasts a Layer 3 LWAPP discovery message on the local IP subnet. Any WLC that is configured for Layer 3 LWAPP mode and that is connected to the same local subnet receives the Layer 3 LWAPP discovery message.
Each of the WLCs that receives the LWAPP discovery message replies with a unicast LWAPP discovery response message to the LAP.


Here the debug lwapp events enable command shows this discovery process:

(Cisco Controller) >debug lwapp events enable
Mon May 22 12:00:21 2006: Received LWAPP DISCOVERY REQUEST from AP 
00:0b:85:5b:fb:d0 to ff:ff:ff:ff:ff:ff on port '1'
Mon May 22 12:00:21 2006: Successful transmission of LWAPP Discovery-Response 
to AP 00:0b:85:5b:fb:d0 on Port 1


The debug lwapp packet enable command output for the local subnet broadcast discovery looks like this example:

(Cisco Controller) >debug lwapp packet enable
Tue May 23 12:37:50 2006: Start of Packet
Tue May 23 12:37:50 2006: Ethernet Source MAC (LRAD):      00:0B:85:51:5A:E0
Tue May 23 12:37:50 2006: Msg Type       :
Tue May 23 12:37:50 2006:    DISCOVERY_REQUEST
Tue May 23 12:37:50 2006: Msg Length     :   31
Tue May 23 12:37:50 2006: Msg SeqNum     :   0
Tue May 23 12:37:50 2006: 
IE            :   UNKNOWN IE 58
Tue May 23 12:37:50 2006: IE Length     :   1
Tue May 23 12:37:50 2006: Decode routine not available, Printing Hex Dump

Tue May 23 12:37:50 2006: 00000000: 00


The value of the IE 58 parameter indicates the discovery type, which could be the following:

0 - broadcast
1 - configured
2 - OTAP
3 - dhcp server

4 - dns


OTA Method:
==========

LAPs also use the Over-the-Air Provisioning (OTAP) feature in order to discover the WLC. The OTAP feature is disabled by default in 4.2.39.13, 5.0.68.0 and later WLC versions. OTAP is enabled by default in the WLC versions earlier than 4.2.39.13.. This is the discovery process when OTAP is enabled:

The LAPs that are already registered to the WLC can advertise the WLC IP address to the LAPs (in an attempt to find the WLC) with the use of neighbor messages that are sent over the air.

New LAPs that attempt to discover WLCs hear these messages and then unicast LWAPP discovery request messages to the WLCs.


WLCs that receive the LWAPP discovery message reply with a unicast LWAPP discovery response message to the LAP

You should have OTAP enabled only during AP provisioning intervals. After APs are deployed, disable OTAP as a deployment best practice. Also, Cisco Aironet LAPs (1130 AG, 1200, and 1240 AG series) ship from the factory with a stripped-down version of lightweight Cisco IOS® Software that is called the LWAPP Recovery Cisco IOS image. OTAP is not supported on those APs out-of-the-box that run LWAPP Cisco IOS Software. When you upgrade Cisco Aironet APs from autonomous Cisco IOS Software to lightweight mode, the LWAPP Recovery Cisco IOS image is the software that is loaded. The LWAPP Recovery Cisco IOS image does not support OTAP. In order to support OTAP, Aironet LAPs must first join a WLC in order to download a full LWAPP Cisco IOS image.

The debug lwapp event enable command output illustrates the sequence of messages that the WLCs send:

Tue May 23 14:37:10 2006: Received LWAPP DISCOVERY REQUEST from AP 
00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port '1'
Tue May 23 14:37:10 2006: Successful transmission of LWAPP Discovery-Response to 
AP 00:0b:85:5b:fb:d0 on Port 1

Because the LAP knows the WLC IP address through neighbor messages, the LAP sends a unicast discovery request to the WLC. 

The value of the IE 58 parameter in the debug lwapp packet enable command output shows you that the LAP used OTAP as the discovery method.

Tue May 23 14:21:55 2006: Start of Packet
Tue May 23 14:21:55 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB
Tue May 23 14:21:55 2006: Msg Type       :
Tue May 23 14:21:55 2006:    DISCOVERY_REQUEST
Tue May 23 14:21:55 2006: Msg Length     :   31
Tue May 23 14:21:55 2006: Msg SeqNum     :   0
Tue May 23 14:21:55 2006: 
IE            :   UNKNOWN IE 58
Tue May 23 14:21:55 2006: IE Length     :   1
Tue May 23 14:21:55 2006: Decode routine not available, Printing Hex Dump
Tue May 23 14:21:55 2006: 00000000: 02                                                .



Locally Saved WLC IP:
================

If the LAP was registered to a WLC in a previous deployment, the LAP maintains the list of WLC IP addresses locally in NVRAM. The stored WLC IP addresses include all of the WLCs that are in previously joined WLC "mobility groups". This is the discovery process:

LAPs send a unicast Layer 3 LWAPP discovery request to each of the WLC IP addresses that the LAP has in its NVRAM.

WLCs that receive the LWAPP discovery message reply with a unicast LWAPP discovery response message to the LAP.


The debug lwapp events enable command and the debug lwapp packet enable command for this method of WLC discovery:

Note: If you use the clear ap-config ap_name command in order to reset the LAP to the factory defaults, all the LAP configurations are reset. The configurations that are reset include the WLC IP addresses that are stored in NVRAM. In this case, the LAP must use some other method in order to discover the WLC.

(Cisco Controller) >debug lwapp events enable
Tue May 23 14:37:10 2006: Received LWAPP DISCOVERY REQUEST from AP 
00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port '1'
Tue May 23 14:37:10 2006: Successful transmission of LWAPP Discovery-Response to 
AP 00:0b:85:5b:fb:d0 on Port 1
(Cisco Controller) >debug lwapp packet enable
Tue May 23 14:45:36 2006: Start of Packet
Tue May 23 14:45:36 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB
Tue May 23 14:45:36 2006: Msg Type       :
Tue May 23 14:45:36 2006:    DISCOVERY_REQUEST
Tue May 23 14:45:36 2006: Msg Length     :   31
Tue May 23 14:45:36 2006: Msg SeqNum     :   0
Tue May 23 14:45:36 2006: 
IE            :   UNKNOWN IE 58
Tue May 23 14:45:36 2006: IE Length     :   1
Tue May 23 14:45:36 2006: Decode routine not available, Printing Hex Dump

Tue May 23 14:45:36 2006: 00000000: 01 


DHCP OPTION 43 Method:
==================

When the LAP powers up, it looks for a DHCP server in order to get an IP address. The DHCP server allots an IP address to the LAP and also provides the list of WLC IP addresses with the use of DHCP option 43. The LAP sends out a unicast discovery request to each of the WLCs. The WLCs that hear these messages reply with a discovery response, which initiates the registration process. 

The debug lwapp events enable command output shows the sequence of LWAPP messages:

Tue May 23 14:43:42 2006: Received LWAPP DISCOVERY REQUEST from AP 
00:0b:85:5b:fb:d0 to 00:0b:85:33:84:a0 on port '1'
Tue May 23 14:43:42 2006: Successful transmission of LWAPP Discovery-Response to 
AP 00:0b:85:5b:fb:d0 on Port 1


The debug lwapp packet enable command output that indicates that DHCP option 43 was used as the discovery method in order to discover WLC IP addresses:

Tue May 23 16:14:32 2006: Start of Packet
Tue May 23 16:14:32 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB
Tue May 23 16:14:32 2006: Msg Type       :
Tue May 23 16:14:32 2006:    DISCOVERY_REQUEST
Tue May 23 16:14:32 2006: Msg Length     :   31
Tue May 23 16:14:32 2006: Msg SeqNum     :   0
Tue May 23 16:14:32 2006: 
IE            :   UNKNOWN IE 58
Tue May 23 16:14:32 2006: IE Length     :   1
Tue May 23 16:14:32 2006: Decode routine not available, Printing Hex Dump

Tue May 23 16:14:32 2006: 00000000: 03                                                .

DNS Discovery Method:

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

You can also use the DNS server in order to return WLC IP addresses to the LAP. This is the discovery process:

The LAP attempts to resolve the DNS name "CISCO-LWAPP-CONTROLLER.localdomain."

The AP is informed of this domain name through DHCP option 15. DHCP option 15 specifies the domain name that the AP should use for DNS resolution. Therefore, it is necessary that DHCP option 15 be configured with the domain name information. This allows the DHCP server that sends the IP address of the DNS server to also send this DHCP option 15 information (the domain name to be resolved) to the AP.

When the LAP is able to resolve this name to one or more WLC IP addresses, the LAP sends a unicast Layer 3 LWAPP discovery request to each of the WLCs.

The WLCs that receive the LWAPP discovery message reply with a unicast LWAPP discovery response message to the AP.

After the LAP gets the DNS server IP address, the LAP sends out a DNS query for the DNS name CISCO-LWAPP-CONTROLLER.localdomain. The DNS server should be configured such that it returns the WLC IP address for this query. When the LAP gets the WLC IP address, the LAP starts the registration process with the WLC.

The debug lwapp packet enable command output shows the discovery type as DNS:

Tue May 23 16:14:32 2006: Start of Packet

Tue May 23 16:14:32 2006: Ethernet Source MAC (LRAD):      00:D0:58:AD:AE:CB

Tue May 23 16:14:32 2006: Msg Type       :

Tue May 23 16:14:32 2006:    DISCOVERY_REQUEST

Tue May 23 16:14:32 2006: Msg Length     :   31

Tue May 23 16:14:32 2006: Msg SeqNum     :   0

Tue May 23 16:14:32 2006: 

IE            :   UNKNOWN IE 58

Tue May 23 16:14:32 2006: IE Length     :   1

Tue May 23 16:14:32 2006: Decode routine not available, Printing Hex Dump

Tue May 23 16:14:32 2006: 00000000: 04                                                .

Note:  If, after the completion of steps 1 through 5, the LAP does not receive an LWAPP discovery response, the LAP resets and restarts the hunting algorithm.

Using IP-HELPER on the L3 Interface:

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

After the LAP gets an IP address from the DHCP server, the LAP broadcasts a Layer 3 LWAPP discovery message on to its local subnet. The IP address of the WLC is configured as the ip-helper address on the router. The router forwards these broadcasts to the IP addresses configured with the ip-helper command on the interface on which the broadcast is heard. When you use the ip helper-address command, DIRECTED BROADCASTS, as well as unicasts, eight different UDP ports are forwarded automatically.

Please find the previous post:

http://lets-start-to-learn.blogspot.in/2014/08/ip-helper-misconceptions.html

Following example shows the configuration on the router:

Router(config)#interface Fastethernet 0/1

Router(config-if)#ip helper-address 172.16.0.1

Router(config-if)#exit

Router(config)ip forward-protocol udp 12223

Note: If you run WLC version 5.2 or later, use the UDP port number 5246 because the CAPWAP broadcast uses UDP port 5246.

Router(config)ip forward-protocol udp 5246