Cisco Support Community
Community Member

Wireless clients sporadically loosing connectivity


I have an issue where my wireless clients will sporadically not be able to connect to the LAN at random intervals. I have a mix of windows, mac, iOS, and android devices that all have the issue. When one unit is having the issue, the others do not (very random). Here is my setup:

WLC2106 >TRUNK> Meraki MS220 >ACCESS> 2x 1142n APs. My router for all my VLANs is Meraki MX60 (also connected to MS220). 

My wireless clients are on their own VLAN, APs on their own, and mgmt for the WLC is on its own. The ap-manager interface for the WLC is on the same VLAN as the APs performing layer 2 discovery. 

When this has occurred, I have run a packet capture on the connection between my switch and router. In this capture, I see the following repeated multiple times:

Troubled client mac in example is e8:4e:84:ff:b4:03

(This is from an old capture, before I changed some networking so I put place holders for the IPs. Unfortunately, it fixed before I could re-capture. Result has been the same before and after)

03:38:31.453445 ARP, Request who-has ROUTER-IP tell CLIENTIP, length 42
03:38:31.454215 ARP, Reply ROUTERIP is-at 00:18:0a:43:40:df, length 42

From here I ran an ARP debug on the WLC and got this repeatedly (this is fresh):

*dtlArpTask: Nov 06 23:54:27.035: Arp from Wirless side to DS or passive client

*dtlArpTask: Nov 06 23:54:27.312: dtlArpBcastRecv: received packet (rxTunType 1, dataLen 122)

*dtlArpTask: Nov 06 23:54:27.313: processLwappArp: received lwapp packet from STA e84e.84ff.b403
*dtlArpTask: Nov 06 23:54:27.313: Received dtlArpRequest
   sha: e8:4e:84:ff:b4:03 spa:
   tha: 00:00:00:00:00:00 tpa:
   intf: 1, vlan: 11, node type: 2, mscb: found, isFromSta: 1
*dtlArpTask: Nov 06 23:54:27.313: dtlArpFindClient:ARP look-up for failed (not a client).

*dtlArpTask: Nov 06 23:54:27.313: Sending ARP to DS (mscb 0xbdc0524, port 1)
   sha e84e.84ff.b403 spa:
   tha 0000.0000.0000 tpa:
*dtlArpTask: Nov 06 23:54:27.313: dtlARPRequestSend: sending ARP request to ffff.ffff.ffff (vlanId 11, intIfNum 1, exitPort 1, tmpVlanId 0 flag 0x5


Looking at a capture on the switch to WLC, I see:

04:23:30.674924 00:18:0a:43:40:df > e8:4e:84:ff:b4:03, ethertype 802.1Q (0x8100), length 60: vlan 11, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has tell


It looks like they are ARPing for each other but never get there. Again, this happens at sporadic times and I cannot find any correlation. I can make the client gain immediate access if I disconnect and reconnect to the WLAN. Or it typically resolves itself after about 20-30 minutes. 

I've been banging my head against the wall with this for a few weeks. Any help would help this headache go away. 

Controller was running I just downgraded while writing this to and will see if it happens in this version.




Everyone's tags (6)
Hall of Fame Super Blue

1.  What kind of wireless

1.  What kind of wireless client(s)?  Specify the hardware?  (Smartphones, tablets, laptops)

2.  How is the signal strength when this issue occurs?  Measure both sides (AP to client and Client to AP)

3.  What radio are the clients trying to get in?  a or b?

4.  What happens if you have open authentication?

Community Member

Hello,I ended up downgrading


I ended up downgrading the controller to a different version (cannot recall off the top of my head but still 7.0). It hasn't happened in the past few days. Leo Laohoo, here are the answers to your questions:

1.  What kind of wireless client(s)?  Specify the hardware?  (Smartphones, tablets, laptops)

  • iPad 3rd gen
  • Samsung Galaxy Tab 10.1 (2014 edition)
  • Lenovo T440 (intel AC-7260)
  • Dell E6410 (intel chip, not sure of part number)

2.  How is the signal strength when this issue occurs?  Measure both sides (AP to client and Client to AP)

  • When it last happened, it was in the 60-80 range.

3.  What radio are the clients trying to get in?  a or b?

  • Looking at the client list I see a mix of A/G

4.  What happens if you have open authentication?

  • Haven't tried this one yet. The area that this is in has a large amount of foot traffic. If the issue occurs again, I will make another SSID and not broadcast


It turns out that I've been having this issue at another location as well with a 2500 series controller however it occurs MUCH much less.

CreatePlease to create content