Wireless client association hostname

Hi all, 
I'm having issue with the above unit. Currently I have 3 units of AIR-SAP2602E-S-K9 with 15.2(2)JB under 1 SSID. Currently all my clients connected to the AP does not have their computer hostname appearing under the client association. What it is showing instead is the hostname of the AP. For eg;
Device Type
Name
IP Address
MAC Address
State
Parent
VLAN
ccx-client
AP-HOSTNAME
XXX.XXX.XXX.XXX
Xxx.xXx.Xxx
EAP-Associated
self
1
Any Idea how I can get the hostname of the clients instead?

If both the SSID and your client were configured for open, and you still couldn't associate, something doesn't jive. There are a couple of things that can cause an issue like this.
1) Is the MFP Client Protection "Required" under the advanced tab?
2) Is the WMM Policy "Required" under the QoS tab?
3) Is the "Aironet IE" enabled under the advanced tab of the SSID? That can cause problems for some clients.
Any of those (especially the first two) would cause a similar issue with not being able to associate, as having mismatched encryption types.

Similar Messages

  • Continuous Wireless Client Associations and De-authentications

    I have a remote site whose wlan consist of a 2112-WLC and twelve 1142N's.  The issue I am seeing is that several clients will associate continuously   throughout the day.  This does not occur for any specific client or ap.  These multiple associations appear to take place every 5-10 minutes most of the time.  I have 4 other sites using the same wireless network equipment and I do not see this problem.  I have verified the ap signal strengths and verified that the noise and interference levels are ok.  Any assistance provided will be very appreciated.

    Is enable session time out enabled
    WLANS-->ADVANCED-->Look at enable session time out ... what does it say ?

  • Wireless Client associated to 2 APs

    I searched for my mac address in WCS and I recieved three results. See the attached screenshot. I am just curious why the second entry show I am associated to AP 00:00:00:00:00:00?
    I do not have an AP named that.
    Running 4.2.130 on all my WLC. Have a mis of WiSM and 4400 Controllers totaling about 10 WLCs.

    As Jeff mentioned, this is due to your client roaming and most likely due to wlc roaming. The information you see is not real time accurate, especially the wlc information of clients. You can see that 10.92.0.111 shows the client as still being authenticated which is not the case. So most likely what happens is the wlc is cached until flushed or cleared, but ap's keep the real time information, so the all zero's just mean that the wlc knows of the client but not yet flushed the old info and when it tries to detect which ap that user is on, there isn't one.... so it produces the all zero's.

  • Dot11 associations table, client associated with 0.0.0.0

    I'm having an issue where wireless client association seam to fail to get IP address, but acctually don't...
    MAC Address    IP address      Device        Name            Parent         State    
    0016.eaae.c896 0.0.0.0         unknown       -               self           EAP-Assoc
    001f.e178.c6d8 192.168.27.192  unknown       -               self           EAP-Assoc
    This happens only "sometimes", especially when the clients (laptops) wake up from sleep mode.
    Although the association shows IP 0.0.0.0, the state is "EAP-Assoc" and I can confirm that the client passed RADIUS authentication, received IP from DHCP and can ping the gateway.
    The wireless network is made up by autonomous/standalone access-points (Cisco aironet 1100, 1130, 1200, 1040).
    Network access is PEAP, WPA/AES, dot1x, multiple Vlans...
    All access-points have an access-list at the radio IN that is dropping all IP broadcasts.
    When I remove the ACL, everything appear to be fine (at least all the times that I checked), but when the ACL is active the issue doesn't always come up.
    I must understand what is going on because this ACL (although it's not very common) has proven it's value by saving 30-40% CPU usage on access-points...
    Does anyone know how the "dot11 associations" table is built??
    Maybe some tips on how to troubleshoot the issue.
    thanks in advance

    As an answer to your early quetsions (that I don't know why we did not answer it yet):
    Assoc table is mainly built from information in association frames.
    Assoc frames have no idea about IP addresses so how the APs know the IP? Not from assoc frames of course.
    Each vendor may have different way to know the IP (they can look into the header of the IP traffic of that special client or they an look into dhcp communication).
    summarizing the issue so far:
    - The issue happens ONLY with the ACL in place.
    - It does not happen with all clients.
    - It happens ONLY when the clients in power save mode.
    - It happens with same clients if they use static ip address even if they are not in power save mode (please confirm or amend this sentence to be more accurate).
    Why power save mode do not show the IP? - > answering this quetion almost solves the problem.
    what is common among the problematic clients? - > need to know this in order to isolate further.
    Is it AP hardware/software related? -> helps to isolate further.
    I said that it could possibly be related to information elements but not necessarily.
    There are information element that transfer Power Save capability between clietns and the AP. I have no idea though how those can be related.
    More information about information elements can be found in the IEEE standard downloadable from here:
    http://standards.ieee.org/getieee802/download/802.11-2007.pdf
    go to section :
    7.3.2 Information elements
    in page 99.
    I tried to read about power save and tried to link that with our issue with no hope.
    It could possibly a bug or so that when PS is used the AP behaves differently.
    HTH
    Amjad

  • Wireless client disconnecting

    Hi All,
    We have a WLAN setup with 1 AP 1230 assigned as a WDS, and the 16 APs configured as Infrastructure AP. Off late, I am experiencing a problem where all my clients are getting disconnected frequently. I have checked the logs and the logs indicate the follwoing:
    %DOT11-4-TKIP_MIC_FAILURE: TKIP Michael MIC failure was detected on a packet (TSC=0x19B42) received from 0013.ced4.bd48.
    Oct 24 12:45:42 172.20.166.22 5673: Oct 24 07:15:42.428: %DOT11-3-TKIP_MIC_FAILURE_REPEATED: Two TKIP Michael MIC failures were detected within 48 seconds on Dot11Radio0 interface. The interface will be put on MIC failure hold state for next 60 seconds.
    Oct 24 12:45:42 172.20.166.22 5674: Oct 24 07:15:42.429: %DOT11-4-TKIP_MIC_FAILURE: TKIP Michael MIC failure was detected on a packet (TSC=0x19B43) received from 0013.ced4.bd48.
    Oct 24 12:45:42 172.20.166.22 5675: Oct 24 07:15:42.430: %DOT11-4-TKIP_MIC_FAILURE: TKIP Michael MIC failure was detected on a packet (TSC=0x19B44) received from 0013.ced4.bd48.
    Oct 24 12:45:42 172.20.166.22 5676: Oct 24 07:15:42.430: Too many MIC failures.
    I need a solution to overcome this problems. Please let me know if you need any further information, to help me provide a solution.
    regds,
    Mahesh

    Good afternoon Mahesh...
    Similar to a CRC, TKIP uses Message Integrity Check(MIC) to ensure protection of the payload and headers. Presently the Michael algorithm is used to accomplish this function. Essentially these messages are early warning signs of RF interference, hardware failure and or an active attack.
    The initial error message of TKIP_MIC_FAILURE is rather harmless, as there is no effect to surrounding clients. It simply states that the AP has received a packet which failed its integrity check. MIC replaced WEP's CRC-32 checksum for improved security. You will NOT see this issue in LEAP as it does not utilize MIC.
    TKIP_MIC_FAILURE_REPEATED, however is another story. If you see this log entry on an access point, you will want to respond quickly. This is stating that a workstation has sent X number of MIC failures in a certain number of seconds. As stated by the 802.11i standard, the access point goes into a blackout period. ( Cisco's default is 60 second blackout period), what this does is disassociates all wireless clients associated with the access point and puts the radio in a type of hold where it does not allow any associations until the blackout is lifted.
    The offending client and those associated with the access point do not receive any sort of error. All the user will notice, is that their laptop's wireless has been disconnected. If the user's laptop is able to access another AP it will attempt to connect to it, if behaving and configure correctly. What we have seen in at our facility is the offending client will continue to cause TKIP errors and bring down the AP it just connected to.
    Is there a Band-Aid to this problem?
    Interface dot11radio x
    countermeasure tkip hold-time 0
    This is NOT a solution, its simply a fix to keep your APs from going into blackout. Again I would only use this if you had a larger volume of laptops with malfunctioning nics than your local techsupport could handle.
    There are two typical causes for these errors, hardware problems and RF issues. RF changes even at 5ft, if you are able to go to multiple areas of your facility (saying you have a large facility) and take still shoot out errors, you likly have a hardware issue. Replace the card and your good to go.
    While upgrading to the latest IOS is always the best messure even when not facing problems you will likly not see a decrease/increase.
    hope this helps.... Simply put , research if its a single laptop... If it is, attempt to replace the nic.. We had one laptop which even after reloading the IOS, swapping the cards, etc it kept commiting the units. We kept the harddrive and sent the laptop off and was RMA'd. New laptop came in, put the old hdd back in, no problems.
    We have not noticed a link between driver version nor firmware...

  • Client Association,Authentication

    Hey All,
    In regards to the Assoiciation and Authentication I would just like to check that I am getting the process correct:
    1. Authentication( open or shared) this is the client talking to the AP and saying that it is an 802.11 device ( kind of like an ethernet cable being pluged into a wall jack), if it has a PSK then it must have the right details to Auth with the AP. This is Auth'd to the AP but not the network, so no network traffic can pass just yet.
    2. Association the client associates with the BSS/AP and data can now pass over to the AP.
    3. 802.1x Authentication ( EAP) - if required
      In the above Image the Associated status means it passed step 2 and the Auth means in passed 802.1x? 
    If this is the case in the above Image the Authed clients ( blue line) are the clients that have passed 802.1x? and the red line is clients that have passed stage 2?
    Thanks

    Hello,
    In the client association process,  access points send out beacons announcing one or more SSIDs, data rates,  and other information. The client sends  out a probe and scans all the channels and listens for beacons and  responses to the probes from the access points. The client associates to the access point that has  the strongest signal. If the signal becomes low, the client repeats the scan to associate with  another access point (this process is called roaming). During  association, the SSID, MAC address, and security settings are sent from  the client to the access point and  checked by the access point. Figure  3-6 illustrates the client  association process.
    Figure 3-6 Client  Association
    A wireless clients association to a selected access point  is actually the second step in a two-step process. First, authentication  and then association must occur before an 802.11 client can pass traffic through the access  point to another host on the network. Client  authentication in this initial process is not the same as network  authentication (entering username and password to get access to the  network). Client authentication is simply  the first step (followed by association) between the wireless client and access point, and it establishes  communication. The 802.11 standard specifies only two different methods  of authentication: open authentication and shared key authentication.  Open authentication is simply the exchange of four "hello" type packets  with no client or access point  verification, to allow ease of connectivity. Shared key authentication  uses a statically defined WEP key, known between the client and access point, for verification. This  same key might or might not be used to encrypt the actual data passing  between a wireless client and an access  point based on user configuration.
    http://www.ciscopress.com/articles/article.asp?p=1156068&seqNum=3

  • Wireless device associating and disassociating fro...

    HH3 version A arrived recently to replace a faulty HH1 (why didn't I get a version B?), and in the log, one of our wireless devices, even though it's in standby, is associationg and disassociating from the HH every 5 mins or so
    I've switched it from 802.11b/g/n because one of the PCs 'only' has an 802.11g wireless adaptor. 
    From the log
    12:31:51, 25 Sep. (660121.260000) Device disconnected: Hostname: Wii IP: 192.168.1.72 MAC: 00:22:aa:29:d7:da
    12:31:50, 25 Sep. ath0: STA 00:22:aa:29:d7:da IEEE 802.11: Client disassociated
    12:31:40, 25 Sep. (660109.750000) Lease for IP 192.168.1.72 renewed by host Wii (MAC 00:22:aa:29:d7:da). Lease duration: 30240 min
    12:31:40, 25 Sep. (660109.750000) Device connected: Hostname: Wii IP: 192.168.1.72 MAC: 00:22:aa:29:d7:da Lease time: 30240 min. Link rate: 24.0 Mbps
    12:31:40, 25 Sep. (660109.730000) Lease requested
    12:31:39, 25 Sep. ath0: STA 00:22:aa:29:d7:da IEEE 802.11: Client associated
    12:27:51, 25 Sep. (659881.070000) Device disconnected: Hostname: Wii IP: 192.168.1.72 MAC: 00:22:aa:29:d7:da
    12:27:50, 25 Sep. ath0: STA 00:22:aa:29:d7:da IEEE 802.11: Client disassociated
    12:27:40, 25 Sep. (659869.920000) Lease for IP 192.168.1.72 renewed by host Wii (MAC 00:22:aa:29:d7:da). Lease duration: 30240 min
    12:27:40, 25 Sep. (659869.910000) Device connected: Hostname: Wii IP: 192.168.1.72 MAC: 00:22:aa:29:d7:da Lease time: 30240 min. Link rate: 11.0 Mbps
    12:27:40, 25 Sep. (659869.900000) Lease requested
    12:27:39, 25 Sep. ath0: STA 00:22:aa:29:d7:da IEEE 802.11: Client associated
    and the same at 12.21, 12.16, 12.11, etc
    What's going on, and how should I iron it out?

    It looks like an issue with the Wii. You could try altering the settings on the Wii, to give it a static IP address.
    See
    Using static IP addresses on your home network
    It should not keep disassociating with the home hub.Try changing the home hub encryption to WPA only.
    There are some useful help pages here, for BT Broadband customers only, on my personal website.
    BT Broadband customers - help with broadband, WiFi, networking, e-mail and phones.

  • HWIC-AP-AG-A keep on disconnecting wireless clients sometime its ok but sometimes its not

    hi,
    i have a  HWIC-AP-AG-A running in 2801 router.
    RTR01(config-if)#do sho run int Dot11Radio0/1/0
    Building configuration...
    Current configuration : 367 bytes
    interface Dot11Radio0/1/0
    no ip address
    no dot11 extension aironet
    encryption vlan 30 mode ciphers tkip
    encryption vlan 40 mode ciphers tkip
    encryption vlan 10 mode ciphers tkip
    ssid GuestUsers
    ssid InternalUsers
    ssid SecureZone
    speed basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
    channel 2412
    station-role root
    no cdp enable
    end
    RTR01(config-if)#do sho run int Dot11Radio0/1/1
    Building configuration...
    Current configuration : 325 bytes
    interface Dot11Radio0/1/1
    no ip address
    encryption vlan 30 mode ciphers tkip
    encryption vlan 40 mode ciphers tkip
    encryption vlan 10 mode ciphers tkip
    ssid GuestUsers
    ssid InternalUsers
    ssid SecureZone
    speed basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
    station-role root
    no cdp enable
    there are days that the wireless signal is keep on disconnecting.. im no sure what is the problem or.. what can i do?
    n Interface FastEthernet0/3/0, changed state to up
    *Jan 12 11:00:25.511: %LINK-3-UPDOWN: Interface BVI30, changed state to down
    *Jan 12 11:00:25.511: %LINK-3-UPDOWN: Interface BVI40, changed state to down
    *Jan 12 11:00:26.535: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI30, changed state to down
    *Jan 12 11:00:26.535: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI40, changed state to down
    *Jan 12 11:00:27.679: %DSPRM-5-UPDOWN: DSP 1 in slot 0, changed state to up
    *Jan 12 11:00:28.091: %LINK-3-UPDOWN: Interface Foreign Exchange Office 0/0/0, changed state to up
    *Jan 12 11:00:28.503: %LINK-3-UPDOWN: Interface Foreign Exchange Office 0/0/1, changed state to up
    *Jan 12 11:00:28.735: %LINK-3-UPDOWN: Interface Foreign Exchange Station 0/2/1, changed state to up
    *Jan 12 11:00:28.843: %LINK-3-UPDOWN: Interface Foreign Exchange Station 0/2/0, changed state to up
    *Jan 12 11:00:31.563: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
    *Jan 12 11:00:32.290: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 222.164.193.47, mask 255.255.252.0, hostname marlonmalinao.homeip.net
    *Jan 12 11:00:33.582: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed state to up
    *Jan 12 11:00:42.381: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 123: Neighbor 10.10.254.1 (Tunnel1) is up: new adjacency
    *Jan 12 11:00:44.773: %SSH-5-SSH2_SESSION: SSH2 Session request from 172.25.254.4 (tty = 0) using crypto cipher 'aes256-cbc', hmac 'hmac-sha1' Succeeded
    *Jan 12 11:00:56.652: %SSH-5-SSH2_USERAUTH: User 'mc.malinao' authentication for SSH2 Session from 172.25.254.4 (tty = 0) using crypto cipher 'aes256-cbc', hmac 'hmac-sha1' Succeeded
    *Jan 12 11:00:57.948: %DOT11-6-FREQ_USED: Interface Dot11Radio0/1/1, frequency 5320 selected
    *Jan 12 11:00:57.952: %LINK-3-UPDOWN: Interface Dot11Radio0/1/1, changed state to up
    *Jan 12 11:00:59.076: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0/1/1, changed state to up
    *Jan 12 11:01:00.172: %LINK-3-UPDOWN: Interface BVI30, changed state to up
    *Jan 12 11:01:01.171: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI30, changed state to up
    *Jan 12 11:01:05.499: %LINK-3-UPDOWN: Interface BVI40, changed state to up
    *Jan 12 11:01:06.499: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI40, changed state to up
    *Jan 12 11:01:13.202: %IPPHONE-6-REG_ALARM: 14: Name=SEP001E4AF3B6D4 Load= SCCP70.8-4-2S Last=UCM-closed-TCP
    *Jan 12 11:01:13.206: %IPPHONE-6-REGISTER: ephone-6:SEP001E4AF3B6D4 IP:172.25.254.61 Socket:1 DeviceType:Phone has registered.
    *Jan 12 11:01:25.401: %DOT11-6-ASSOC: Interface Dot11Radio0/1/1, Station   8c7b.9dde.e8f9 Associated SSID[InternalUsers] AUTH_TYPE[OPEN] KEY_MGMT[WPA PSK]
    *Jan 12 11:01:37.236: %DOT11-6-ASSOC: Interface Dot11Radio0/1/1, Station MCMRTR01 0019.d2b8.3c68 Associated SSID[GuestUsers] AUTH_TYPE[OPEN] KEY_MGMT[WPA PSK]
    *Jan 12 11:03:15.542: %DOT11-6-DISASSOC: Interface Dot11Radio0/1/1, Deauthenticating Station 0013.e8a2.a4c1 Reason: Sending station has left the BSS SSID[InternalUsers]
    *Jan 12 11:03:43.247: %LINK-3-UPDOWN: Interface Dot11Radio0/1/0, changed state to up
    *Jan 12 11:03:44.247: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0/1/0, changed state to up
    *Jan 12 11:07:20.957: %DOT11-7-AUTH_FAILED: Station 0013.e8a2.a4c1 Authentication failed
    *Jan 12 11:07:32.720: %DOT11-6-ASSOC: Interface Dot11Radio0/1/1, Station MCMX61 0013.e8a2.a4c1 Associated SSID[GuestUsers] AUTH_TYPE[OPEN] KEY_MGMT[WPA PSK]
    *Jan 12 11:08:16.023: %DOT11-6-DISASSOC: Interface Dot11Radio0/1/1, Deauthenticating Station 8c7b.9dde.e8f9 Reason: Previous authentication no longer valid SSID[InternalUsers]
    *Jan 12 11:08:16.343: %DOT11-6-ASSOC: Interface Dot11Radio0/1/1, Station   8c7b.9dde.e8f9 Associated SSID[InternalUsers] AUTH_TYPE[OPEN] KEY_MGMT[WPA PSK]
    *Jan 12 11:09:21.208: %DOT11-4-MAXRETRIES: Packet to client 8c7b.9dde.e8f9 reached max retries, removing the client
    *Jan 12 11:09:21.208: %DOT11-6-DISASSOC: Interface Dot11Radio0/1/1, Deauthenticating Station 8c7b.9dde.e8f9 Reason: Previous authentication no longer valid SSID[InternalUsers]

    Your wireless clients will associate to the best AP interms of signal strenght and signal to noise etc.
    There is an LWAPP tunnel between the access point and the controller.
    At the controller there will be logical interfaces for the wireless LANS that are asssociated to specific VLANs on the wired network.
    It doesn't matter where you are in the building as a client as its the controller that puts the client data onto the wired network.
    All client data is tunneled between the access point and the controller.
    With regard to the losing IP address situation. I assume that the clients do initially get an IP address and then lose it after a period of time.
    Check the session timeout paramter on the controller (look on the WLAN-Advanced).
    There is a bug with some versions of software relating to session timeouts. Try setting the timeout to 65535 seconds. The default setting is probably 30 minutes.

  • Some Wireless clients won't authenticate to 887VA-W

    Hi folks
    I've swapped over a few months ago from an 877w router to an 887VAw which has a separate AP in-built, and there are a few wireless clients that had no problem authenticating to the 877w but just refuse to communicate to the 887VA-W.
    The clients in question are set top box type devices : (1)Now TV and (2) Sky Wireless Adapter.
    They have no problem seeing the SSID's being broadcast, and for troubleshooting I've setup an open test SSID without any encryption, but the clients still won't authenticate and grab an ip address, or more accurately they just don't get a dhcp ip address so I don't think authentication is really the issue. I don't know why these clients aren't happy with dhcp on the guest vlan (vlan2) where other clients get an ip address and work fine. Perhaps the fact I'm using vlan1 (being used for the Eap-Fast home wlan) as the native untagged vlan might have something to do with it? If I use a static ip address on the guest vlan (vlan 2 / ip 10.1.1.n ) then the Sky Wireless Adapter can send and receive packets across the wlan.
    Can anybody please suggest some debugs or config changes to try and nail the problem? The relevant configs from the AP is pasted below, and the router below that.
    Brgds, Tim
    aaa new-model
    aaa group server radius rad_eap
     server name rs-local
    aaa authentication login default local
    aaa authentication login eap_methods group rad_eap
    aaa authentication ppp default local
    aaa authorization exec default local
    dot11 ssid home
       vlan 1
       authentication open eap eap_methods
       authentication network-eap eap_methods
       authentication key-management wpa version 2
    dot11 ssid guest
       vlan 2
       authentication open
       authentication key-management wpa
       mbssid guest-mode
       wpa-psk ascii 7 abcdef123
    dot11 ssid test
       vlan 3
       authentication open
       mbssid guest-mode
    interface Dot11Radio0
     no ip address
     no ip route-cache
     encryption vlan 1 mode ciphers aes-ccm
     encryption vlan 2 mode ciphers aes-ccm
     broadcast-key vlan 1 change 30
     broadcast-key vlan 2 change 43200
     ssid home
     ssid guest
     ssid test
     antenna gain 0
     mbssid
     speed  basic-1.0 basic-2.0 basic-5.5 basic-11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
     packet retries 64 drop-packet
     no preamble-short
     station-role root
    interface Dot11Radio0.1
     encapsulation dot1Q 1 native
     no ip route-cache
     no cdp enable
     bridge-group 1
     bridge-group 1 subscriber-loop-control
     bridge-group 1 spanning-disabled
     bridge-group 1 block-unknown-source
     no bridge-group 1 source-learning
     no bridge-group 1 unicast-flooding
    interface Dot11Radio0.2
     encapsulation dot1Q 2
     no ip route-cache
     no cdp enable
     bridge-group 2
     bridge-group 2 subscriber-loop-control
     bridge-group 2 spanning-disabled
     bridge-group 2 block-unknown-source
     no bridge-group 2 source-learning
     no bridge-group 2 unicast-flooding
    interface Dot11Radio0.3
     encapsulation dot1Q 3
     no ip route-cache
     no cdp enable
     bridge-group 3
     bridge-group 3 subscriber-loop-control
     bridge-group 3 spanning-disabled
     bridge-group 3 block-unknown-source
     no bridge-group 3 source-learning
     no bridge-group 3 unicast-flooding
    interface GigabitEthernet0
     description the embedded AP GigabitEthernet 0 is an internal interface connecting AP with the host router
     no ip address
     no ip route-cache
    interface GigabitEthernet0.1
     encapsulation dot1Q 1 native
     no ip route-cache
     bridge-group 1
     bridge-group 1 spanning-disabled
     no bridge-group 1 source-learning
    interface GigabitEthernet0.2
     encapsulation dot1Q 2
     no ip route-cache
     bridge-group 2
     bridge-group 2 spanning-disabled
     no bridge-group 2 source-learning
    interface GigabitEthernet0.3
     encapsulation dot1Q 3
     no ip route-cache
     bridge-group 3
     bridge-group 3 spanning-disabled
     no bridge-group 3 source-learning
    interface BVI1
     ip address 172.27.44.2 255.255.255.0
     no ip route-cache
    ip default-gateway 172.27.44.1
    ****Router Config****
    interface Wlan-GigabitEthernet0
     description Internal switch interface connecting to the embedded AP
     switchport mode trunk
     no ip address
    interface wlan-ap0
     description Service module interface to manage the embedded AP
     ip unnumbered BVI1

    Hi Sebastian
    Please see ip dhcp debug from 887VA-W showing the Sky client requesting an ip address but failing to get one. Also a debug from an 877-W showing successful dhcp assignment. Also the dhcp config as requested.The successful trace shows 2 mac addresses from the Sky wireless adapter/ Sky box each getting a dhcp address. I don't know whether the failure is a bug in the 887 dhcp code or some config in the embedded AP that needs tweaking.
    Bregs, Tim
    The Sky wired adapter (I think it's the mac of the sky box lan port) mac is 00:19:FB:A4:B2:1A
    The Sky wireless mac is 18:28:61:99:7B:A8
    887VA-W Debug - Failure:
    887#term mon
    887#sh deb
    DHCP server packet debugging is on.
    887#
    887#
    000141: Dec 16 07:03:02.082 London: DHCPD: ARP entry exists (10.1.1.10, e0c9.7ad6.24ee).
    000142: Dec 16 07:03:02.082 London: DHCPD: unicasting BOOTREPLY to client e0c9.7ad6.24ee (10.1.1.10).
    Denham_887#
    000143: Dec 16 07:05:25.536 London: DHCPD: client's VPN is .
    000144: Dec 16 07:05:25.536 London: DHCPD: No option 125
    000145: Dec 16 07:05:25.536 London: DHCPD: DHCPDISCOVER received from client 0019.fba4.b21a on interface BVI1.
    000146: Dec 16 07:05:25.536 London: DHCPD: Allocate an address without class information (10.1.1.0)
    000147: Dec 16 07:05:25.536 London: DHCPD: Saving workspace (ID=0x4000009)
    Denham_887#
    000148: Dec 16 07:05:27.536 London: DHCPD: Reprocessing saved workspace (ID=0x4000009)
    000149: Dec 16 07:05:27.536 London: DHCPD: DHCPDISCOVER received from client 0019.fba4.b21a on interface BVI1.
    000150: Dec 16 07:05:27.536 London: DHCPD: Sending DHCPOFFER to client 0019.fba4.b21a (10.1.1.12).DHCPD: Setting only requested parameters
    000151: Dec 16 07:05:27.536 London: DHCPD: no option 125
    000152: Dec 16 07:05:27.536 London: DHCPD: broadcasting BOOTREPLY to client 0019.fba4.b21a.
    Denham_887#
    000153: Dec 16 07:05:32.468 London: DHCPD: New packet workspace 0x123EC554 (ID=0xC700000A)
    000154: Dec 16 07:05:32.468 London: DHCPD: client's VPN is .
    000155: Dec 16 07:05:32.468 London: DHCPD: No option 125
    000156: Dec 16 07:05:32.468 London: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI1.
    000157: Dec 16 07:05:32.468 London: DHCPD: Allocate an address without class information (10.1.1.0)
    000158: Dec 16 07:05:32.472 London: DHCPD: Saving workspace (ID=0xC700000A)
    Denham_887#
    000159: Dec 16 07:05:34.080 London: DHCPD: New packet workspace 0x1240A47C (ID=0x5500000B)
    000160: Dec 16 07:05:34.080 London: DHCPD: client's VPN is .
    000161: Dec 16 07:05:34.080 London: DHCPD: No option 125
    000162: Dec 16 07:05:34.080 London: DHCPD: DHCPDISCOVER received from client 0019.fba4.b21a on interface BVI1.
    000163: Dec 16 07:05:34.080 London: DHCPD: Sending DHCPOFFER to client 0019.fba4.b21a (10.1.1.12).DHCPD: Setting only requested parameters
    000164: Dec 16 07:05:34.080 London: DHCPD: no option 125
    000165: Dec 16 07:05:34.080 London: DHCPD: broadcasting BOOTREPLY to client 0019.fba4.b21a.
    Denham_887#
    000166: Dec 16 07:05:34.468 London: DHCPD: Reprocessing saved workspace (ID=0xC700000A)
    000167: Dec 16 07:05:34.468 London: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI1.
    000168: Dec 16 07:05:34.468 London: DHCPD: Sending DHCPOFFER to client 0118.2861.997b.a8 (10.1.1.13).DHCPD: Setting only requested parameters
    000169: Dec 16 07:05:34.468 London: DHCPD: no option 125
    000170: Dec 16 07:05:34.468 London: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    Denham_887#
    000171: Dec 16 07:05:35.476 London: DHCPD: client's VPN is .
    000172: Dec 16 07:05:35.476 London: DHCPD: No option 125
    000173: Dec 16 07:05:35.476 London: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI1.
    000174: Dec 16 07:05:35.476 London: DHCPD: Sending DHCPOFFER to client 0118.2861.997b.a8 (10.1.1.13).DHCPD: Setting only requested parameters
    000175: Dec 16 07:05:35.476 London: DHCPD: no option 125
    000176: Dec 16 07:05:35.476 London: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    Denham_887#
    000177: Dec 16 07:05:37.520 London: DHCPD: client's VPN is .
    000178: Dec 16 07:05:37.520 London: DHCPD: No option 125
    000179: Dec 16 07:05:37.520 London: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI1.
    000180: Dec 16 07:05:37.520 London: DHCPD: Sending DHCPOFFER to client 0118.2861.997b.a8 (10.1.1.13).DHCPD: Setting only requested parameters
    000181: Dec 16 07:05:37.524 London: DHCPD: no option 125
    000182: Dec 16 07:05:37.524 London: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    Denham_887#
    000183: Dec 16 07:05:40.532 London: DHCPD: client's VPN is .
    000184: Dec 16 07:05:40.532 London: DHCPD: No option 125
    000185: Dec 16 07:05:40.532 London: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI1.
    000186: Dec 16 07:05:40.532 London: DHCPD: Sending DHCPOFFER to client 0118.2861.997b.a8 (10.1.1.13).DHCPD: Setting only requested parameters
    000187: Dec 16 07:05:40.532 London: DHCPD: no option 125
    000188: Dec 16 07:05:40.532 London: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    Denham_887#
    000189: Dec 16 07:05:43.540 London: DHCPD: client's VPN is .
    000190: Dec 16 07:05:43.540 London: DHCPD: No option 125
    000191: Dec 16 07:05:43.540 London: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI1.
    000192: Dec 16 07:05:43.540 London: DHCPD: Sending DHCPOFFER to client 0118.2861.997b.a8 (10.1.1.13).DHCPD: Setting only requested parameters
    000193: Dec 16 07:05:43.540 London: DHCPD: no option 125
    000194: Dec 16 07:05:43.540 London: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    Denham_887#
    000195: Dec 16 07:05:48.884 London: DHCPD: client's VPN is .
    000196: Dec 16 07:05:48.884 London: DHCPD: No option 125
    000197: Dec 16 07:05:48.884 London: DHCPD: DHCPDISCOVER received from client 0019.fba4.b21a on interface BVI1.
    000198: Dec 16 07:05:48.884 London: DHCPD: Sending DHCPOFFER to client 0019.fba4.b21a (10.1.1.12).DHCPD: Setting only requested parameters
    000199: Dec 16 07:05:48.884 London: DHCPD: no option 125
    000200: Dec 16 07:05:48.884 London: DHCPD: broadcasting BOOTREPLY to client 0019.fba4.b21a.
    887VA-W dhcp config:
    887#sh run | section dhcp
    no ip dhcp use vrf connected
    ip dhcp binding cleanup interval 10
    no ip dhcp conflict logging
    ip dhcp pool home
     network 172.27.44.0 255.255.255.0
     dns-server 208.67.222.222 208.67.220.220  
     default-router 172.27.44.1
    ip dhcp pool test
     import all
     network 11.1.1.0 255.255.255.0
     default-router 11.1.1.1
     dns-server 208.67.222.222 208.67.220.220
    ip dhcp pool guest
     import all
     network 10.1.1.0 255.255.255.0
     default-router 10.1.1.1
     dns-server 208.67.222.222 208.67.220.220
    877-W Debug - Success:
    877#deb ip dhcp se
    877#deb ip dhcp server pa
    DHCP server packet debugging is on.
    877#deb ip dhcp server ev
    DHCP server event debugging is on.
    877#
    000258: *Jun 23 22:20:07.087 BST: DHCPD: checking for expired leases.
    000259: *Jun 23 22:20:14.684 BST: %DOT11-6-ASSOC: Interface Dot11Radio0, Station   1828.6199.7ba9 Associated SSID[guest] AUTH_TYPE[OPEN] KEY_MGMT[WPAv2 PSK]
    000260: *Jun 23 22:20:16.289 BST: DHCPD: Sending notification of DISCOVER:
    000261: *Jun 23 22:20:16.289 BST:   DHCPD: htype 1 chaddr 1828.6199.7ba8
    000262: *Jun 23 22:20:16.289 BST:   DHCPD: remote id 020a00000a010101f2000000
    000263: *Jun 23 22:20:16.289 BST:   DHCPD: circuit id 00000000
    000264: *Jun 23 22:20:16.289 BST: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI2.
    000265: *Jun 23 22:20:16.289 BST: DHCPD: Seeing if there is an internally specified pool class:
    000266
     *Jun 23 22:20:16.289 BST:   DHCPD: htype 1 chaddr 1828.6199.7ba8
    000267: *Jun 23 22:20:16.289 BST:   DHCPD: remote id 020a00000a010101f2000000
    000268: *Jun 23 22:20:16.289 BST:   DHCPD: circuit id 00000000
    000269: *Jun 23 22:20:16.289 BST: DHCPD: Sending DHCPOFFER to client 0118.2861.997b.a8 (10.1.1.9).
    000270: *Jun 23 22:20:16.289 BST: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    000271: *Jun 23 22:20:16.493 BST: DHCPD: DHCPREQUEST received from client 0118.2861.997b.a8.
    000272: *Jun 23 22:20:16.493 BST: DHCPD: Sending notification of ASSIGNMENT:
    000273: *Jun 23 22:20:16.493 BST:  DHCPD: address 10.1.1.9 mask 255.255.255.0
    000274: *Jun 23 22:20:16.493 BST:   DHCPD: htype 1 chaddr 1828.6199.7ba8
    000275: *Jun 23 22:20:16.493 BST:   DHCPD: lease time remaining (secs) = 86400
    000276: *Jun 23 22:20:16.493 BST: DHCPD: Appending system default domain
    000278: *Jun 23 22:20:16.493 BST: DHCPD: Sending DHCPACK to client 0118.2861.997b.a8 (10.1.1.9).
    000279: *Jun 23 22:20:16.493 BST: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    000280: *Jun 23 22:20:17.089 BST: DHCPD: checking for expired leases.
    000281: *Jun 23 22:20:18.097 BST: %SYS-5-CONFIG_I: Configured from console by vty0
    Denham#
    000282: *Jun 23 22:20:21.314 BST: DHCPD: Sending notification of DISCOVER:
    000283: *Jun 23 22:20:21.314 BST:   DHCPD: htype 1 chaddr 0019.fba4.b21a
    000284: *Jun 23 22:20:21.314 BST:   DHCPD: remote id 020a00000a010101f2000000
    000285: *Jun 23 22:20:21.314 BST:   DHCPD: circuit id 00000000
    000286: *Jun 23 22:20:21.314 BST: DHCPD: DHCPDISCOVER received from client 0019.fba4.b21a on interface BVI2.
    000287: *Jun 23 22:20:21.314 BST: DHCPD: Seeing if there is an internally specified pool class:
    000288: *
    Jun 23 22:20:21.314 BST:   DHCPD: htype 1 chaddr 0019.fba4.b21a
    000289: *Jun 23 22:20:21.314 BST:   DHCPD: remote id 020a00000a010101f2000000
    000290: *Jun 23 22:20:21.314 BST:   DHCPD: circuit id 00000000
    000291: *Jun 23 22:20:21.314 BST: DHCPD: Sending DHCPOFFER to client 0019.fba4.b21a (10.1.1.8).
    000292: *Jun 23 22:20:21.314 BST: DHCPD: broadcasting BOOTREPLY to client 0019.fba4.b21a.
    000293: *Jun 23 22:20:21.406 BST: DHCPD: DHCPREQUEST received from client 0019.fba4.b21a.
    000294: *Jun 23 22:20:21
    406 BST: DHCPD: Sending notification of ASSIGNMENT:
    000295: *Jun 23 22:20:21.406 BST:  DHCPD: address 10.1.1.8 mask 255.255.255.0
    000296: *Jun 23 22:20:21.406 BST:   DHCPD: htype 1 chaddr 0019.fba4.b21a
    000297: *Jun 23 22:20:21.406 BST:   DHCPD: lease time remaining (secs) = 86400
    000298: *Jun 23 22:20:21.406 BST: DHCPD: Can't find any hostname to update
    000299: *Jun 23 22:20:21.406 BST: DHCPD: Sending DHCPACK to client 0019.fba4.b21a (10.1.1.8).
    000300: *Jun 23 22:20:21.406 BST: DHCPD: broadcasting
    BOOTREPLY to client 0019.fba4.b21a.
    000302: *Jun 23 22:20:33.049 BST: DHCPD: Sending notification of DISCOVER:
    000303: *Jun 23 22:20:33.049 BST:   DHCPD: htype 1 chaddr 1828.6199.7ba8
    000304: *Jun 23 22:20:33.049 BST:   DHCPD: remote id 020a00000a010101f2000000
    000305: *Jun 23 22:20:33.049 BST:   DHCPD: circuit id 00000000
    000306: *Jun 23 22:20:33.049 BST: DHCPD: DHCPDISCOVER received from client 0118.2861.997b.a8 on interface BVI2.
    000307: *Jun 23 22:20:33.049 BST: DHCPD: Seeing if there is an internally specified pool class:
    000308
    Denham#: *Jun 23 22:20:33.049 BST:   DHCPD: htype 1 chaddr 1828.6199.7ba8
    000309: *Jun 23 22:20:33.049 BST:   DHCPD: remote id 020a00000a010101f2000000
    000310: *Jun 23 22:20:33.049 BST:   DHCPD: circuit id 00000000
    000311: *Jun 23 22:20:33.049 BST: DHCPD: Sending DHCPOFFER to client 0118.2861.997b.a8 (10.1.1.9).
    000312: *Jun 23 22:20:33.053 BST: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.
    000313: *Jun 23 22:20:33.081 BST: DHCPD: DHCPREQUEST received from client 0118.2861.997b.a8.
    000314: *Jun 23
    Denham# 22:20:33.081 BST: DHCPD: Sending notification of ASSIGNMENT:
    000315: *Jun 23 22:20:33.081 BST:  DHCPD: address 10.1.1.9 mask 255.255.255.0
    000316: *Jun 23 22:20:33.081 BST:   DHCPD: htype 1 chaddr 1828.6199.7ba8
    000317: *Jun 23 22:20:33.081 BST:   DHCPD: lease time remaining (secs) = 86400
    000318: *Jun 23 22:20:33.081 BST: DHCPD: Appending system default domain
    000319: *Jun 23 22:20:33.085 BST: DHCPD: Using hostname 'skywirelessconnector.indahouse.dyndns.org.' for dynamic update (from hostname opti
    indahouse#uon)
    000320: *Jun 23 22:20:33.085 BST: DHCPD: Sending DHCPACK to client 0118.2861.997b.a8 (10.1.1.9).
    000321: *Jun 23 22:20:33.085 BST: DHCPD: broadcasting BOOTREPLY to client 1828.6199.7ba8.

  • -1 (Minus One) Wireless Client Rate for networked PCs with Ariport Express

    Trying to figure out connection problems...
    Under Airport Utility > Advanced > Logs and Statistics > Wireless Clients...
    My MBP gets a Rate 54Mbps when I am beside it in my room, but sometimes drops down to 11 or so and then goes back up. I think this is why I am losing my AirTunes connection.
    Both PCs on the network are farther away but are showing a Rate of -1Mbps, even when they are brought into the same room as the APX.
    Any thoughts.

    1. How does the client device know which Airport to connect to?
    The Mac computer will automatically connect to the wireless access point with the strongest signal...which is probably the closest AirPort. An iPhone or iPad may not do this and will tend to stay connected to one AirPort.
    2. How can I tell which of the Airports the attached client device is using?
    On a Mac, open Macintosh HD > Applications > Utilities > AirPort Utility. Click on one of AirPorts. In the area to the right, locate the AirPort ID and jot that down. Then do the same for your other AirPort.
    Move your Mac near one of the AirPorts and log on to the wireless. Hold down the option key on the Mac while you click the fan shaped AirPort icon at the top of the screen. Look for the BSSID. That is the AirPort ID of the device to which you are connected.
    If you are close to the "remote" AirPort, and you see the AIrPort ID of the "main" router when you are testing, then you know that the network is not configured correctly.
    Can I use this second Airport Express to extend the wireless network via "Extended Wireless Network" while the other two are in "Roaming Netowrk" configuration? Without bogging down??
    There will be a modest 10-15% bandwidth loss with the "extend" setup, assuming that the Express is located where it can receive a strong wireless signal from the AirPort to which it is associated. You can avoid the bandwidth loss if the Express is also connected via Ethernet as part of the roaming configuration.

  • WLC 5760 - MAC Filtering wireless clients

    Hi,
    Does anyone ever deployed mac-filtering authentication to wireless clients in the WLC 5760?
    I've configured a WLAN for Mac-filtering authentication only (named it as "macauth"):
    wlan RNVDOS 4 RNVDOS
    aaa-override
    no broadcast-ssid
    client vlan RNVDOS
    mac-filtering macauth
    no security wpa
    no security wpa akm dot1x
    no security wpa wpa2
    no security wpa wpa2 ciphers aes
    session-timeout 1800
    no shutdown
    Then, below Configuration->Security->MAC Filtering I've added several MAC addresses i.e. :
    MAC Address: 88532e9ef70a  Attribute List: macauth
    Which turned out to be display in the CLI as:
    username 88532e9ef70a mac aaa attribute list macauth
    The problem is that whenever I try to associate the wireless client 88532e9ef70a, the client passes to the exclusion list.:
    Sep 16 10:54:55.603: 8853.2E9E.F70A Adding mobile on LWAPP AP  0C68.03EA.4070 (1)  1 wcm: E9E.F70A (.t^GwtSessionID: 0afe01fbtQ^GwH^Cnz^Gw00dd) was added to ^G$h\225v^K
    Sep 16 10:54:55.603: 8853.2E9E.F70A  Creating WL station entry for client -  rc 0 1 wcm:
    Sep 16 10:54:55.603: 8853.2E9E.F70A Association received from mobile on AP  0C68.03EA.4070  1 wcm: (.t^GwtSessionID: 0afe01fbtQ^GwH^Cnz^Gw00dd) was added to ^G$h\225v^K
    Sep 16 10:54:55.603: 8853.2E9E.F70A qos upstream policy is unknown and downstream policy is unknown 1 wcm: ssionID: 0afe01fbtQ^GwH^Cnz^Gw00dd) was added to ^G$h\225v^K
    Sep 16 10:54:55.603: 8853.2E9E.F70A apChanged 0 wlanChanged 0 mscb ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0 1 wcm: H^Cnz^Gw00dd) was added to ^G$h\225v^K
    Sep 16 10:54:55.603: 8853.2E9E.F70A Applying WLAN policy on MSCB. 1 wcm:  ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:55.603: 8853.2E9E.F70A Applying WLAN ACL policies to client 1 wcm:  0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:55.603: 8853.2E9E.F70A No Interface ACL used for Wireless client in WCM(NGWC) 1 wcm: usOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:55.603: 8853.2E9E.F70A Applying site-specific IPv6 override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm:  ^G$h\225v^K
    Sep 16 10:54:55.603: 8853.2E9E.F70A Applying local bridging Interface Policy for station  8853.2E9E.F70A  - vlan 4, interface 'RNVDOS' 1 wcm: ce 'RNVDOS'
    Sep 16 10:54:55.603: 8853.2E9E.F70A Applying site-specific override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: DOS'
    Sep 16 10:54:55.603: 8853.2E9E.F70A STA - rates (8): 1 wcm:  140 18 152 36 176 72 96 108 0 0 0 0 0 0 0 0
    Sep 16 10:54:55.603: 8853.2E9E.F70A new capwap_wtp_iif_id a45d40000000a5, sm capwap_wtp_iif_id 0 1 wcm: - vapId 4, site 'renova', interface 'RNVDOS'
    Sep 16 10:54:55.603: 8853.2E9E.F70A apfProcessAssocReq (apf_80211.c: 1 wcm: 5137) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from Idle to AAA Pending
    Sep 16 10:54:55.603: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:55.604: 8853.2E9E.F70A
    client incoming attribute size are 0 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:55.604: 8853.2E9E.F70A Sending Assoc Response to station on BSSID  0C68.03EA.4070  (status 256) ApVapId 2 Slot 1 1 wcm: 68.03EA.4070  from Idle to AAA Pending
    Sep 16 10:54:55.604: 8853.2E9E.F70A apfProcessRadiusAssocResp (apf_80211.c: 1 wcm: 2149) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from AAA Pending to Authenticated
    Sep 16 10:54:55.604: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 18) in 10 seconds
    Sep 16 10:54:55.813: 8853.2E9E.F70A Association received from mobile on AP  0C68.03EA.4070  1 wcm: n.t^Gwseconds
    Sep 16 10:54:55.813: 8853.2E9E.F70A qos upstream policy is unknown and downstream policy is unknown 1 wcm: onds
    Sep 16 10:54:55.813: 8853.2E9E.F70A apChanged 0 wlanChanged 0 mscb ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0 1 wcm: H^Cnz^Gw  0C68.03EA.4070  f^G$h\225v^K
    Sep 16 10:54:55.813: 8853.2E9E.F70A Applying WLAN policy on MSCB. 1 wcm:  ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:55.813: 8853.2E9E.F70A Applying WLAN ACL policies to client 1 wcm:  0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:55.813: 8853.2E9E.F70A No Interface ACL used for Wireless client in WCM(NGWC) 1 wcm: usOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:55.813: 8853.2E9E.F70A Applying site-specific IPv6 override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: f^G$h\225v^K
    Sep 16 10:54:55.813: 8853.2E9E.F70A Applying local bridging Interface Policy for station  8853.2E9E.F70A  - vlan 4, interface 'RNVDOS' 1 wcm: ce 'RNVDOS'
    Sep 16 10:54:55.813: 8853.2E9E.F70A Applying site-specific override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: DOS'
    Sep 16 10:54:55.813: 8853.2E9E.F70A STA - rates (8): 1 wcm:  140 18 152 36 176 72 96 108 0 0 0 0 0 0 0 0
    Sep 16 10:54:55.813: 8853.2E9E.F70A new capwap_wtp_iif_id a45d40000000a5, sm capwap_wtp_iif_id 0 1 wcm: - vapId 4, site 'renova', interface 'RNVDOS'
    Sep 16 10:54:55.813: 8853.2E9E.F70A apfProcessAssocReq (apf_80211.c: 1 wcm: 5137) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:55.813: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:55.814: 8853.2E9E.F70A
    client incoming attribute size are 0 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:55.814: 8853.2E9E.F70A Sending Assoc Response to station on BSSID  0C68.03EA.4070  (status 256) ApVapId 2 Slot 1 1 wcm: 68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:55.814: 8853.2E9E.F70A apfProcessRadiusAssocResp (apf_80211.c: 1 wcm: 2149) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from AAA Pending to Authenticated
    Sep 16 10:54:55.814: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 18) in 10 seconds
    Sep 16 10:54:56.520: 8853.2E9E.F70A Association received from mobile on AP  0C68.03EA.4070  1 wcm: n.t^Gwseconds
    Sep 16 10:54:56.520: 8853.2E9E.F70A qos upstream policy is unknown and downstream policy is unknown 1 wcm: onds
    Sep 16 10:54:56.520: 8853.2E9E.F70A apChanged 0 wlanChanged 0 mscb ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0 1 wcm: H^Cnz^Gw  0C68.03EA.4070  f^G$h\225v^K
    Sep 16 10:54:56.520: 8853.2E9E.F70A Applying WLAN policy on MSCB. 1 wcm:  ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.520: 8853.2E9E.F70A Applying WLAN ACL policies to client 1 wcm:  0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.520: 8853.2E9E.F70A No Interface ACL used for Wireless client in WCM(NGWC) 1 wcm: usOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.520: 8853.2E9E.F70A Applying site-specific IPv6 override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: f^G$h\225v^K
    Sep 16 10:54:56.520: 8853.2E9E.F70A Applying local bridging Interface Policy for station  8853.2E9E.F70A  - vlan 4, interface 'RNVDOS' 1 wcm: ce 'RNVDOS'
    Sep 16 10:54:56.520: 8853.2E9E.F70A Applying site-specific override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: DOS'
    Sep 16 10:54:56.520: 8853.2E9E.F70A STA - rates (8): 1 wcm:  140 18 152 36 176 72 96 108 0 0 0 0 0 0 0 0
    Sep 16 10:54:56.520: 8853.2E9E.F70A new capwap_wtp_iif_id a45d40000000a5, sm capwap_wtp_iif_id 0 1 wcm: - vapId 4, site 'renova', interface 'RNVDOS'
    Sep 16 10:54:56.520: 8853.2E9E.F70A apfProcessAssocReq (apf_80211.c: 1 wcm: 5137) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:56.520: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:56.521: 8853.2E9E.F70A
    client incoming attribute size are 0 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:56.521: 8853.2E9E.F70A Sending Assoc Response to station on BSSID  0C68.03EA.4070  (status 256) ApVapId 2 Slot 1 1 wcm: 68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:56.521: 8853.2E9E.F70A apfProcessRadiusAssocResp (apf_80211.c: 1 wcm: 2149) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from AAA Pending to Authenticated
    Sep 16 10:54:56.521: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 18) in 10 seconds
    Sep 16 10:54:56.729: 8853.2E9E.F70A Association received from mobile on AP  0C68.03EA.4070  1 wcm: n 10 seconds
    Sep 16 10:54:56.729: 8853.2E9E.F70A qos upstream policy is unknown and downstream policy is unknown 1 wcm: onds
    Sep 16 10:54:56.729: 8853.2E9E.F70A apChanged 0 wlanChanged 0 mscb ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0 1 wcm: A  on AP  0C68.03EA.4070  from AAA Pending to Authenticated
    Sep 16 10:54:56.729: 8853.2E9E.F70A Applying WLAN policy on MSCB. 1 wcm:  ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.729: 8853.2E9E.F70A Applying WLAN ACL policies to client 1 wcm:  0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.729: 8853.2E9E.F70A No Interface ACL used for Wireless client in WCM(NGWC) 1 wcm: usOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.729: 8853.2E9E.F70A Applying site-specific IPv6 override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: from AAA Pending to Authenticated
    Sep 16 10:54:56.729: 8853.2E9E.F70A Applying local bridging Interface Policy for station  8853.2E9E.F70A  - vlan 4, interface 'RNVDOS' 1 wcm: ce 'RNVDOS'
    Sep 16 10:54:56.729: 8853.2E9E.F70A Applying site-specific override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: DOS'
    Sep 16 10:54:56.729: 8853.2E9E.F70A STA - rates (8): 1 wcm:  140 18 152 36 176 72 96 108 0 0 0 0 0 0 0 0
    Sep 16 10:54:56.729: 8853.2E9E.F70A new capwap_wtp_iif_id a45d40000000a5, sm capwap_wtp_iif_id 0 1 wcm: - vapId 4, site 'renova', interface 'RNVDOS'
    Sep 16 10:54:56.729: 8853.2E9E.F70A apfProcessAssocReq (apf_80211.c: 1 wcm: 5137) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:56.729: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:56.730: 8853.2E9E.F70A
    client incoming attribute size are 0 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:56.730: 8853.2E9E.F70A Sending Assoc Response to station on BSSID  0C68.03EA.4070  (status 256) ApVapId 2 Slot 1 1 wcm: 68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:56.730: 8853.2E9E.F70A apfProcessRadiusAssocResp (apf_80211.c: 1 wcm: 2149) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from AAA Pending to Authenticated
    Sep 16 10:54:56.730: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 18) in 10 seconds
    Sep 16 10:54:56.937: 8853.2E9E.F70A Association received from mobile on AP  0C68.03EA.4070  1 wcm: n.t^Gwseconds
    Sep 16 10:54:56.937: 8853.2E9E.F70A qos upstream policy is unknown and downstream policy is unknown 1 wcm: onds
    Sep 16 10:54:56.937: 8853.2E9E.F70A apChanged 0 wlanChanged 0 mscb ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0 1 wcm: H^Cnz^Gw  0C68.03EA.4070  f^G$h\225v^K
    Sep 16 10:54:56.937: 8853.2E9E.F70A Applying WLAN policy on MSCB. 1 wcm:  ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.937: 8853.2E9E.F70A Applying WLAN ACL policies to client 1 wcm:  0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.937: 8853.2E9E.F70A No Interface ACL used for Wireless client in WCM(NGWC) 1 wcm: usOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:56.937: 8853.2E9E.F70A Applying site-specific IPv6 override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: f^G$h\225v^K
    Sep 16 10:54:56.937: 8853.2E9E.F70A Applying local bridging Interface Policy for station  8853.2E9E.F70A  - vlan 4, interface 'RNVDOS' 1 wcm: ce 'RNVDOS'
    Sep 16 10:54:56.937: 8853.2E9E.F70A Applying site-specific override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: DOS'
    Sep 16 10:54:56.937: 8853.2E9E.F70A STA - rates (8): 1 wcm:  140 18 152 36 176 72 96 108 0 0 0 0 0 0 0 0
    Sep 16 10:54:56.937: 8853.2E9E.F70A new capwap_wtp_iif_id a45d40000000a5, sm capwap_wtp_iif_id 0 1 wcm: - vapId 4, site 'renova', interface 'RNVDOS'
    Sep 16 10:54:56.937: 8853.2E9E.F70A apfProcessAssocReq (apf_80211.c: 1 wcm: 5137) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:56.937: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:56.937: 8853.2E9E.F70A
    client incoming attribute size are 0 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:56.937: 8853.2E9E.F70A Sending Assoc Response to station on BSSID  0C68.03EA.4070  (status 256) ApVapId 2 Slot 1 1 wcm: 68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:56.937: 8853.2E9E.F70A apfProcessRadiusAssocResp (apf_80211.c: 1 wcm: 2149) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from AAA Pending to Authenticated
    Sep 16 10:54:56.937: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 18) in 10 seconds
    Sep 16 10:54:57.143: 8853.2E9E.F70A Association received from mobile on AP  0C68.03EA.4070  1 wcm: n.t^Gwseconds
    Sep 16 10:54:57.143: 8853.2E9E.F70A qos upstream policy is unknown and downstream policy is unknown 1 wcm: onds
    Sep 16 10:54:57.143: 8853.2E9E.F70A apChanged 1 wlanChanged 0 mscb ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0 1 wcm: H^Cnz^Gw  0C68.03EA.4070  f^G$h\225v^K
    Sep 16 10:54:57.143: 8853.2E9E.F70A Applying WLAN policy on MSCB. 1 wcm:  ipAddr 0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:57.143: 8853.2E9E.F70A Applying WLAN ACL policies to client 1 wcm:  0.0.0.0, apf RadiusOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:57.143: 8853.2E9E.F70A No Interface ACL used for Wireless client in WCM(NGWC) 1 wcm: usOverride 0x0, numIPv6Addr=0
    Sep 16 10:54:57.143: 8853.2E9E.F70A Applying site-specific IPv6 override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: f^G$h\225v^K
    Sep 16 10:54:57.143: 8853.2E9E.F70A Applying local bridging Interface Policy for station  8853.2E9E.F70A  - vlan 4, interface 'RNVDOS' 1 wcm: ce 'RNVDOS'
    Sep 16 10:54:57.143: 8853.2E9E.F70A Applying site-specific override for station  8853.2E9E.F70A  - vapId 4, site 'renova', interface 'RNVDOS' 1 wcm: DOS'
    Sep 16 10:54:57.143: 8853.2E9E.F70A STA - rates (8): 1 wcm:  130 132 139 150 12 18 24 36 0 0 0 0 0 0 0 0
    Sep 16 10:54:57.143: 8853.2E9E.F70A STA - rates (12): 1 wcm:  130 132 139 150 12 18 24 36 48 72 96 108 0 0 0 0
    Sep 16 10:54:57.144:  8853.2E9E.F70A  0.0.0.0 START (0) Deleted mobile LWAPP rule on AP [ 0C68.03EA.4070 ] 1 wcm:  site 'renova', interface 'RNVDOS'
    Sep 16 10:54:57.144: 8853.2E9E.F70A Updated location for station old AP  0C68.03EA.4070 -1, new AP  0C68.03EA.4070 -0 1 wcm: va', interface 'RNVDOS'
    Sep 16 10:54:57.144: 8853.2E9E.F70A new capwap_wtp_iif_id a45d40000000a5, sm capwap_wtp_iif_id 0 1 wcm: P  0C68.03EA.4070 -0
    Sep 16 10:54:57.144: 8853.2E9E.F70A apfProcessAssocReq (apf_80211.c: 1 wcm: 5137) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:57.144: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:57.144: 8853.2E9E.F70A
    client incoming attribute size are 0 1 wcm:   (callerId: 20) in 10 seconds
    Sep 16 10:54:57.145: 8853.2E9E.F70A Sending Assoc Response to station on BSSID  0C68.03EA.4070  (status 256) ApVapId 2 Slot 0 1 wcm: 68.03EA.4070  from Authenticated to AAA Pending
    Sep 16 10:54:57.145: 8853.2E9E.F70A apfBlacklistMobileStationEntry2 (apf_ms.c: 1 wcm: 6129) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from AAA Pending to Exclusion-list (1)
    Sep 16 10:54:57.145: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 44) in 10 seconds
    Sep 16 10:54:57.145: 8853.2E9E.F70A client is added to the exclusion list, reason 1 1 wcm: d: 44) in 10 seconds
    Sep 16 10:54:57.145: *apfReceiveTask: 1 wcm:  %APF-4-ADD_TO_BLACKLIST_REASON: Client 8853.2E9E.F70A (AuditSessionID: 0afe01fb5236e37f000000de) was added to exclusion list. Reason: 802.11 association failure 
    Sep 16 10:54:57.836: 8853.2E9E.F70A Ignoring assoc request due to mobile in exclusion list or marked for deletion  1 wcm: fbtQ^GwH^Cnz^Gw00de) was added to ^G$h\225v^K
    Sep 16 10:54:58.533: 8853.2E9E.F70A Ignoring assoc request due to mobile in exclusion list or marked for deletion  1 wcm: fbtQ^GwH^Cnz^Gw00de) was added to ^G$h\225v^K
    Sep 16 10:54:59.231: 8853.2E9E.F70A Ignoring assoc request due to mobile in exclusion list or marked for deletion  1 wcm: fbtQ^GwH^Cnz^Gw00de) was added to ^G$h\225v^K
    Sep 16 10:54:59.922: 8853.2E9E.F70A Ignoring assoc request due to mobile in exclusion list or marked for deletion  1 wcm: fbtQ^GwH^Cnz^Gw00de) was added to ^G$h\225v^K
    Sep 16 10:55:06.972: 8853.2E9E.F70A apfMsExpireCallback (apf_ms.c: 1 wcm: 664) Expiring Mobile!
    Sep 16 10:55:06.972: 8853.2E9E.F70A Scheduling deletion of Mobile Station: 1 wcm:   (callerId: 46) in 60 seconds
    Sep 16 10:55:06.972: 8853.2E9E.F70A apfMsExpireMobileStation (apf_ms.c: 1 wcm: 7067) Changing state for mobile  8853.2E9E.F70A  on AP  0C68.03EA.4070  from Exclusion-list (1) to Exclusion-list (2)
    Sep 16 10:55:06.972:  8853.2E9E.F70A  0.0.0.0 START (0) Deleted mobile LWAPP rule on AP [ 0C68.03EA.4070 ] 1 wcm: 3.2E9E.F70A  on AP  0C68.03EA.4070  from Exclusion-list (1) to Exclusion-list (2)
    Sep 16 10:55:06.972:  8853.2E9E.F70A  0.0.0.0 START (0) FastSSID for the client [ 0C68.03EA.4070 ] NOTENABLED 1 wcm: E9E.F70A  on AP  0C68.03EA.4070  from Exclusion-list (1) to Exclusion-list (2)
    Sep 16 10:55:06.972: 8853.2E9E.F70A Incrementing the Reassociation Count 1 for client (of interface RNVDOS) 1 wcm: D
    Sep 16 10:55:06.972: 8853.2E9E.F70A Clearing Dhcp state for station  ---  1 wcm:  for client (of interface RNVDOS)
    WLC1#
    WLC1#
    Kind Regards,
    Vasco

    Hi Patrick,
    Thank you for sharing your solution. It didn't solved entirely the problem but you pointed to the right direction!
    They are caused, because the system searches for an aaa authorization list, which is not configured.
    To resolve this configure the following
    aaa authorization network mac-filter local
    where mac-filter is the name you defined in the SSID.
    I've used your sugestion to create an aaa local authorization list but instead of naming it with the SSID, I've used the name of the attribute list ( macauth ) and it solved the problem:
    aaa authorization network macauth local
    username 88532e9ef70a mac aaa attribute list macauth
    wlan RNVDOS 4 RNVDOS
    client vlan RNVDOS
    mac-filtering macauth
    WLC1#sh wireless client summ
    Number of Local Clients : 1
    MAC Address    AP Name                          WLAN State              Protocol
    8853.2e9e.f70a APf872.ead7.31da                 4    UP                 11n(5)  
    Cheers,
    Vasco

  • WLC 2504 v7.5.102.0 Client Association Issues. Association not consistent

    Hi All,
    I'm having a strange issue whereby client association to my corporate or guest wifi ssid are not consistent. Sometimes I have no issues connecting repeatedly and other times I cannot connect and receive the "Windows was unable to connect to *SSID*"
    I'm unable to determine whether it is a wireless association issue or if its a authentication issue as I have troubles connecting to both my secure (WPA2, AES, 802.1x) corporate wifi or my guest (Open Auth) wifi.
    Currently per day I have about 15 users using the wifi on both SSID's. The access points are right in the vicinity of the users. I have 2 LAP1142 access points on separate 802.11a/b/g/n channels and signal strenght is always high.. I'm certain its not co-channel interference or interference whatsoever. RSSI values are -60dBm and SNR 30+ dB. On average I will have 10 users on the wireless fine but one or two people are unable to connect.
    I have had wireshark run and when it does not connect I do not see anything in the logs. No traffic is captured!
    I cannot see the AAA capturing anything. Signal strength as stated above is high ( I have the AP on my desk!)
    Sometimes I can instantly connect with no troubles and other times its not association at all. I've recently updated to version 7.5 and these issues started to occur. Previous version 7.3 had no problems at all for years!.
    The logs in the WLC show
    *Dot1x_NW_MsgTask_0: Nov 27 04:42:09.956: #DOT1X-3-INVALID_WPA_KEY_MSG_STATE: 1x_eapkey.c:864 Received invalid EAPOL-key M2 msg in START  state - invalid secure bit; KeyLen 24, Key type 1, client 3c:a9:f4:4x:xx:xx
    Does anyone have an idea what could this issue could be?
    Many thanks

    Thanks for your reply Sandeep. Been working on it all afternoon with debugging.
    To answer your question, sometimes I can connect and sometimes I cannot. This afternoon I haven't been able to connect much at all. 2 out of 20 times perhaps. Other users I can see are connected to the two access points in this office. This isn't just happening on my laptop but several laptops. Same symptom.
    Heres the dot1x output I have captured from the debug of a FAILED association attempt.
    (Cisco Controller) >show debug
    MAC Addr 1.................................. 3C:A9:F4:36:1C:48
    Debug Flags Enabled:
      dot1x aaa enabled.
      dot1x packet enabled.
      dot1x events enabled.
      dot1x states enabled.
    (Cisco Controller) >*DHCP Socket Task: Nov 27 07:44:49.842: 3c:a9:f4:36:1c:48 apfMsRunStateInc
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 Processing RSN IE type 48, length 22 for mobile 3c:a9:f4:36:1c:48
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 Received RSN IE with 0 PMKIDs from mobile 3c:a9:f4:36:1c:48
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 Found an cache entry for BSSID 20:bb:c0:c9:26:92 in PMKID cache at index 0 of station 3c:a9:f4:36:1c:48
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 Removing BSSID 20:bb:c0:c9:26:92 from PMKID cache of station 3c:a9:f4:36:1c:48
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 Resetting MSCB PMK Cache Entry 0 for station 3c:a9:f4:36:1c:48
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 Setting active key cache index 0 ---> 8
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 unsetting PmkIdValidatedByAp
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 apfMsRunStateDec
    *apfMsConnTask_4: Nov 27 07:45:15.284: 3c:a9:f4:36:1c:48 apfMs1xStateDec
    *dot1xMsgTask: Nov 27 07:45:15.287: 3c:a9:f4:36:1c:48 Disable re-auth, use PMK lifetime.
    *dot1xMsgTask: Nov 27 07:45:15.288: 3c:a9:f4:36:1c:48 dot1x - moving mobile 3c:a9:f4:36:1c:48 into Connecting state
    *dot1xMsgTask: Nov 27 07:45:15.288: 3c:a9:f4:36:1c:48 Sending EAP-Request/Identity to mobile 3c:a9:f4:36:1c:48 (EAP Id 1)
    *dot1xMsgTask: Nov 27 07:45:15.288: 3c:a9:f4:36:1c:48 Sending 802.11 EAPOL message  to mobile 3c:a9:f4:36:1c:48 WLAN 3, AP WLAN 3
    *dot1xMsgTask: Nov 27 07:45:15.288: 00000000: 02 00 00 3c 01 01 00 3c  01 00 6e 65 74 77 6f 72  ...<...<..networ
    *dot1xMsgTask: Nov 27 07:45:15.288: 00000010: 6b 69 64 3d 54 50 49 2d  57 49 46 49 2c 6e 61 73  kid=PI-WIFI,nas
    *dot1xMsgTask: Nov 27 07:45:15.288: 00000020: 69 64 3d 4d 2d 54 50 49  2d 51 4c 44 2d 44 43 30  id=M-PI-QLD-DC0
    *dot1xMsgTask: Nov 27 07:45:15.288: 00000030: 30 31 2d 57 43 30 31 2c  70 6f 72 74 69 64 3d 31  01-WC01,portid=1
    *dot1xMsgTask: Nov 27 07:45:29.326: 3c:a9:f4:36:1c:48 Failure sending WPA EAPOL-Key due to invalid state 0 to mobile 3c:a9:f4:36:1c:48
    *dot1xMsgTask: Nov 27 07:45:29.326: 3c:a9:f4:36:1c:48 Unable to send WPA key to mobile 3c:a9:f4:36:1c:48
    (Cisco Controller) >*dot1xMsgTask: Nov 27 07:45:29.326: 3c:a9:f4:36:1c:48 Unable to update broadcast key to mobile 3C:A9:F4:36:1C:48
    *osapiBsnTimer: Nov 27 07:45:45.126: 3c:a9:f4:36:1c:48 802.1x 'txWhen' Timer expired for station 3c:a9:f4:36:1c:48 and for message = M0
    *dot1xMsgTask: Nov 27 07:45:45.126: 3c:a9:f4:36:1c:48 dot1x - moving mobile 3c:a9:f4:36:1c:48 into Connecting state
    *dot1xMsgTask: Nov 27 07:45:45.126: 3c:a9:f4:36:1c:48 Sending EAP-Request/Identity to mobile 3c:a9:f4:36:1c:48 (EAP Id 2)
    *dot1xMsgTask: Nov 27 07:45:45.126: 3c:a9:f4:36:1c:48 Sending 802.11 EAPOL message  to mobile 3c:a9:f4:36:1c:48 WLAN 3, AP WLAN 3
    *dot1xMsgTask: Nov 27 07:45:45.126: 00000000: 02 00 00 3c 01 02 00 3c  01 00 6e 65 74 77 6f 72  ...<...<..networ
    *dot1xMsgTask: Nov 27 07:45:45.126: 00000010: 6b 69 64 3d 54 50 49 2d  57 49 46 49 2c 6e 61 73  kid=PI-WIFI,nas
    *dot1xMsgTask: Nov 27 07:45:45.126: 00000020: 69 64 3d 4d 2d 54 50 49  2d 51 4c 44 2d 44 43 30  id=M-PI-QLD-DC0
    I can see that the WLC has tried to send a EAP-Request/Identity request to the client but no response back. I just don't understand why it works at times and why it doesn't.
    It has the same issues on my guest network which is open authentication. Nothing has changed in regards to configuration and it has been working for years. Only thing that changed was a version upgrade to 7.5 three weeks ago.
    Here is the debug output of the client MAC when attempting to association to the GUEST network.
    (Cisco Controller) >debug client 3C:A9:F4:36:1C:48
    (Cisco Controller) >*apfProbeThread: Nov 27 07:53:48.059: aggregated probe IE: TIMESTAMP
    *apfMsConnTask_4: Nov 27 07:58:02.021: 3c:a9:f4:36:1c:48 Adding mobile on LWAPP AP 20:bb:c0:c9:26:90(0)
    *apfMsConnTask_4: Nov 27 07:58:02.021: 3c:a9:f4:36:1c:48 Association received from mobile on BSSID 20:bb:c0:c9:26:91
    *apfMsConnTask_4: Nov 27 07:58:02.021: 3c:a9:f4:36:1c:48 Global 200 Clients are allowed to AP radio
    *apfMsConnTask_4: Nov 27 07:58:02.021: 3c:a9:f4:36:1c:48 Max Client Trap Threshold: 0  cur: 5
    *apfMsConnTask_4: Nov 27 07:58:02.021: 3c:a9:f4:36:1c:48 Rf profile 600 Clients are allowed to AP wlan
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 Applying Interface policy on Mobile, role Unassociated. Ms NAC State 0 Quarantine Vlan 0 Access Vlan 0
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 Re-applying interface policy for client
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 0.0.0.0 START (0) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2164)
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 0.0.0.0 START (0) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2185)
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 apfApplyWlanPolicy: Apply WLAN Policy over PMIPv6 Client Mobility Type
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 In processSsidIE:4565 setting Central switched to TRUE
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 In processSsidIE:4568 apVapId = 2 and Split Acl Id = 65535
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 Applying site-specific Local Bridging override for station 3c:a9:f4:36:1c:48 - vapId 2, site 'default-group', interface 'guest'
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 Applying Local Bridging Interface Policy for station 3c:a9:f4:36:1c:48 - vlan 650, interface id 12, interface 'guest'
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 processSsidIE  statusCode is 0 and status is 0
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 processSsidIE  ssid_done_flag is 0 finish_flag is 0
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 STA - rates (8): 130 132 139 150 12 18 24 36 0 0 0 0 0 0 0 0
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 suppRates  statusCode is 0 and gotSuppRatesElement is 1
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 STA - rates (12): 130 132 139 150 12 18 24 36 48 72 96 108 0 0 0 0
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 extSuppRates  statusCode is 0 and gotExtSuppRatesElement is 1
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 0.0.0.0 START (0) Initializing policy
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state START (0)
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 0.0.0.0 AUTHCHECK (2) Change state to L2AUTHCOMPLETE (4) last state AUTHCHECK (2)
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 Not Using WMM Compliance code qosCap 00
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP 20:bb:c0:c9:26:90 vapId 2 apVapId 2 flex-acl-name:
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state L2AUTHCOMPLETE (4)
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 apfMsAssoStateInc
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 apfPemAddUser2 (apf_policy.c:333) Changing state for mobile 3c:a9:f4:36:1c:48 on AP 20:bb:c0:c9:26:90 from Idle to Associated
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 apfPemAddUser2:session timeout forstation 3c:a9:f4:36:1c:48 - Session Tout 65535, apfMsTimeOut '65535' and sessionTimerRunning flag is  0
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 Scheduling deletion of Mobile Station:  (callerId: 49) in 65535 seconds
    *apfMsConnTask_4: Nov 27 07:58:02.022: 3c:a9:f4:36:1c:48 Func: apfPemAddUser2, Ms Timeout = 65535, Session Timeout = 65535
    *apfMsConnTask_4: Nov 27 07:58:02.023: 3c:a9:f4:36:1c:48 Sending Assoc Response to station on BSSID 20:bb:c0:c9:26:91 (status 0) ApVapId 2 Slot 0
    *apfMsConnTask_4: Nov 27 07:58:02.023: 3c:a9:f4:36:1c:48 apfProcessAssocReq (apf_80211.c:7957) Changing state for mobile 3c:a9:f4:36:1c:48 on AP 20:bb:c0:c9:26:90 from Associated to Associated
    *apfMsConnTask_4: Nov 27 07:58:02.026: 3c:a9:f4:36:1c:48 Updating AID for REAP AP Client 20:bb:c0:c9:26:90 - AID ===> 4
    *apfReceiveTask: Nov 27 07:58:04.998: 3c:a9:f4:36:1c:48 0.0.0.0 DHCP_REQD (7) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED
    *apfReceiveTask: Nov 27 07:58:04.998: 3c:a9:f4:36:1c:48 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 5716, Adding TMP rule
    *apfReceiveTask: Nov 27 07:58:04.998: 3c:a9:f4:36:1c:48 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule
      type = Airespace AP - Learn IP address
      on AP 20:bb:c0:c9:26:90, slot 0, interface = 1, QOS = 0
      IPv4 ACL ID = 255, IPv
    *apfReceiveTask: Nov 27 07:58:04.998: 3c:a9:f4:36:1c:48 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 15206  Local Bridging Vlan = 650, Local Bridging intf id = 12
    *apfReceiveTask: Nov 27 07:58:04.998: 3c:a9:f4:36:1c:48 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255, L2 ACL ID 255)
    *pemReceiveTask: Nov 27 07:58:04.999: 3c:a9:f4:36:1c:48 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
    *pemReceiveTask: Nov 27 07:58:04.999: 3c:a9:f4:36:1c:48 Sent an XID frame
    *IPv6_Msg_Task: Nov 27 07:58:05.000: 3c:a9:f4:36:1c:48 Pushing IPv6 Vlan Intf ID 12: fe80:0000:0000:0000:f0a7:e03b:151a:3af8 , and MAC: 3C:A9:F4:36:1C:48 , Binding to Data Plane. SUCCESS !! dhcpv6bitmap 0
    *IPv6_Msg_Task: Nov 27 07:58:05.000: 3c:a9:f4:36:1c:48 Link Local address fe80::f0a7:e03b:151a:3af8 updated to mscb. Not Advancing pem state.Current state: mscb in apfMsMmInitial mobility state and client state APF_MS_STATE_A
    (Cisco Controller) >

  • 1131AG: Wireless clients randomly unreachable

    Hi,
    I have a weird issue with my 1131AG-E-K9. I set up a lab at home to get back into the topic after a few years break. My 1131AG is connected to one of the PoE ports of an ASA5505. Clients are 2 Soundbridge internet radios, my Android phone and my laptop. The wireless clients get their IP via DHCP from a central server in the wired LAN.
    Now the problem:
    The wireless clients become randomly unreachable. The DHCP leases are valid 1 hour and once a day, usually in the afternoon, the radios don't get a new IP anymore. When I monitor the LAN, I see the DHCPREQUEST, DHCPDISCOVER and DHCPOFFER packets but they don't seem to arrive in the WLAN. When I manually deassociate one arbitrary client or a completely different client, say, my laptop joins the network and gets an IP via DHCP, suddenly all clients receive the DHCPOFFER and go back active.
    So it looks like the access point would somehow start throwing away packets from the server to the radios after some time.
    I'm pretty much clueless and have googled for hours to find a solution...
    The server and the radios are talking constantly to each other, however, mostly through broadcasts (Bonjour and DLNA).
    I do not have the problem when I use a cheap crap consumer AP instead of the 1131AG, so I would at first glance exclude the ASA as source of the problems. The network is also flat, i.e. the WLAN is the same subnet as the LAN and there's no routing, no fw rules and no different VLANs involved.
    Ideas, anyone?
    -S

    Hi Sebastian, thank you for your reply! The access point is an autonomous access point AIR-AP1131-AG-E-K9, so there is no WLC involved.
    This is the config:
    ! Last configuration change at 15:16:16 UTC Mon Nov 24 2014 by sgofferj
    ! NVRAM config last updated at 15:16:21 UTC Mon Nov 24 2014 by sgofferj
    version 12.4
    no service pad
    service timestamps debug datetime msec
    service timestamps log datetime msec
    service password-encryption
    hostname echo
    no logging buffered
    no logging rate-limit
    no logging console
    aaa new-model
    aaa group server radius rad_eap
    aaa group server radius rad_mac
    aaa group server radius rad_acct
     server [RFC1918] auth-port 1812 acct-port 1813
    aaa group server radius rad_admin
     server [RFC1918] auth-port 1812 acct-port 1813
     cache expiry 1
     cache authorization profile admin_cache
     cache authentication profile admin_cache
    aaa group server tacacs+ tac_admin
     cache expiry 1
     cache authorization profile admin_cache
     cache authentication profile admin_cache
    aaa group server radius rad_pmip
    aaa group server radius dummy
    aaa authentication login eap_methods group rad_eap
    aaa authentication login mac_methods local
    aaa authorization exec default local
    aaa accounting exec default start-stop group rad_acct
    aaa accounting network acct_methods start-stop group rad_acct
    aaa cache profile admin_cache
     all
    aaa session-id common
    no ip igmp snooping
    dot11 syslog
    dot11 vlan-name LAN vlan 1
    dot11 ssid Stefan_Gofferje
       vlan 1
       authentication open
       authentication key-management wpa version 2
       guest-mode
       mbssid guest-mode
       wpa-psk ascii 7 [CODE]
       no ids mfp client
    power inline negotiation injector 001d.450b.fb08
    crypto pki trustpoint TP-self-signed-2716624410
     enrollment selfsigned
     subject-name cn=IOS-Self-Signed-Certificate-2716624410
     revocation-check none
     rsakeypair TP-self-signed-2716624410
    crypto pki certificate chain TP-self-signed-2716624410
     certificate self-signed 01
      30820249 308201B2 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
      31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
      69666963 6174652D 32373136 36323434 3130301E 170D3134 30373136 31393132
      35375A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
      4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D32 37313636
      32343431 3030819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281
      8100C3E0 BCF4B199 68C92993 E4DA9F8E BFD62231 C974A8DA A39F47A7 1268E490
      F59A3BCD 123D0F8C 98B4DAC1 0E65FB70 BE42A8A5 A8CF8A75 A5287804 7B3244AC
      3AAF5F88 A0533A76 B192A6F8 88AFBADF 2D101637 E6061BC3 FE2F197B BA7E3172
      BA5FAA01 85F59AA6 3A99E2C5 4F1F1624 71657D4E 9392E228 B0FA6D3C F97EAFB5
      0F770203 010001A3 71306F30 0F060355 1D130101 FF040530 030101FF 301C0603
      551D1104 15301382 11656368 6F2E676F 66666572 6A652E6E 6574301F 0603551D
      23041830 1680141C 09AC7570 978D1975 1CA7A73C 5927A051 6DB28630 1D060355
      1D0E0416 04141C09 AC757097 8D19751C A7A73C59 27A0516D B286300D 06092A86
      4886F70D 01010405 00038181 000EB3FE 7EA03ABE D215F9DB 0421AC99 CACC9501
      9710D99B 3B2F155B FB7C24E1 45DA20E8 FCF7FC2D 4B794CAA 7FDF7B0E 3253A0DE
      510B067D 5832636C BE03EA47 F673A389 7488788A 329F014A 755D5D1A 92502A41
      11FAD8E8 CE1458DF 45246365 42B42549 C3370C03 7C8FEA47 5F0D4E01 1FF20773
      741A6839 A6BBB581 7CDA3262 32
      quit
    username sgofferj privilege 15 password 7 [CODE]
    bridge irb
    interface Dot11Radio0
     no ip address
     no ip route-cache
     encryption mode ciphers aes-ccm
     encryption vlan 1 mode ciphers aes-ccm
     broadcast-key change 10
     ssid Stefan_Gofferje
     no short-slot-time
     speed  basic-1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
     channel 2437
     station-role root
     no dot11 extension aironet
    interface Dot11Radio0.1
     encapsulation dot1Q 1 native
     no ip route-cache
     bridge-group 1
     bridge-group 1 subscriber-loop-control
     bridge-group 1 block-unknown-source
     no bridge-group 1 source-learning
     no bridge-group 1 unicast-flooding
     bridge-group 1 spanning-disabled
    interface Dot11Radio1
     no ip address
     no ip route-cache
     encryption mode ciphers aes-ccm
     encryption vlan 1 mode ciphers aes-ccm
     broadcast-key change 10
     ssid Stefan_Gofferje
     no dfs band block
     speed  basic-6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0
     channel dfs
     station-role root
     no dot11 extension aironet
    interface Dot11Radio1.1
     encapsulation dot1Q 1 native
     no ip route-cache
     bridge-group 1
     bridge-group 1 subscriber-loop-control
     bridge-group 1 block-unknown-source
     no bridge-group 1 source-learning
     no bridge-group 1 unicast-flooding
     bridge-group 1 spanning-disabled
    interface FastEthernet0
     no ip address
     no ip route-cache
     duplex auto
     speed auto
    interface FastEthernet0.1
     encapsulation dot1Q 1 native
     no ip route-cache
     bridge-group 1
     no bridge-group 1 source-learning
     bridge-group 1 spanning-disabled
    interface BVI1
     ip address dhcp client-id FastEthernet0
     no ip route-cache
    no ip http server
    ip http authentication aaa
    ip http secure-server
    ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
    ip radius source-interface BVI1
    logging trap debugging
    logging [RFC1918]
    access-list 111 permit tcp any any neq telnet
    snmp-server view dot11view ieee802dot11 included
    snmp-server community public RO
    tacacs-server host [RFC1918] key 7 [CODE]
    radius-server attribute 32 include-in-access-req format %h
    radius-server host [RFC1918] auth-port 1812 acct-port 1813 key 7 [CODE]
    radius-server vsa send accounting
    bridge 1 route ip
    line con 0
     access-class 111 in
    line vty 0 4
     access-class 111 in
    sntp server [RFC1918]
    sntp broadcast client
    end

  • AP1200 as Root Bridge: Accept wireless clients or not?

    Cisco's docs precisely contradict themselves on this topic. In some places they state clearly that configuring an AP1200 as a root bridge means it will NOT accept connections from normal wireless clients. In other places they state just as clearly that in root bridge mode an AP1200 WILL accept connections from both non-root bridges and normal wireless clients.
    Which is correct?

    Yes, I discovered that after setting up several units and running some experiments. At first all I saw were the options offered in the "express setup" area. The root-bridge choice there says nothing about wireless clients, and the help screen it invokes says it won't work. But on the radio interface config screen the option you mention is offered and ITS help screen notes wireless clients will be accepted (as its name implies).
    The telnet interface offers all the options as well.
    I can confirm that it does work: In root-bridge with wireless client mode the unit will accept associations from non-root bridges, other AP1230's in WGB mode, and even non-Cisco clients.
    The testing continues... thanks!

  • WCS Showing one client associated to two AP´s

    Hello,
    I´m working on a wireless project that uses some LAP´s 1250, 3 controllers 5508 and a WCS software to manage everything. In one of the areas there are a lot of users, around 90, this area has 6 LAP´s. Some of those clients frequently migrate from one AP to the other. When this happens the WCS shows that client is associated with two AP´s. But when I check the clients list on the controllers, the client is only at one LAP. We are using WCS Version  6.0.181.0. Do you have any problem link this? Is it a WCS bug?
    regards,
    Felipe

    I haven't run into this issue.  This is just a guess but I'm wondering if the client association information is just delayed between WCS and the WLC after a client roams.  You could check the client history and see the amount of time the client was associated to each access point and try to figure out what is going on.

Maybe you are looking for