WLC 5508 AP AIR-LAP1142N-E-K9 and android clients issues

[tanner.zaitt]

Hi,

Do you aware of any issues with Android clients?

My WLC is 5508 and the AP is LAP1142N-E-K9.
The SSID is open without security for public wifi.
The DHCP server is on Microsoft Windows Server with Routing and remote access features enabled.
The Android devices are not able to browse internet.
They connects successfully but without internet.
On the same AP Iphone smartphones and standard Laptop machines have internet.
The issue is only with one AP in the infrastructure, other APs are okey.

Do you have any ideas where is the problem?

Thank you in advance.

[Rich R]

NO! Stay away from 8.2! Those bugs aren't fixed in 8.2 anyway.

It depends on what APs you have but you can probably upgrade to 8.3.150.0 which does support 1142.
https://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html#ctr-ap_support
https://software.cisco.com/download/home/282600534/type/280926587/release/8.3.150.0

[tanner.zaitt]

This is the log from debugging client output:
Do you know what more I could check?
I see how the Samsung tablet is associated with 5Ghz Wifi on the AP and DHCP address has been received.
I see the client on the WLC controller on the Monitoring on the Clients menu.
But the feadback is that the Tablet has no internet connection.
What could I check more?

Aug 03 09:50:23.333	*apfMsConnTask_7	Client made new Association to AP/BSSID BSSID 18:9c:5d:96:58:47 AP TBAP1
Aug 03 09:50:23.335	*apfMsConnTask_7	Client has entered DHCP Required state
Aug 03 09:50:23.335	*apfMsConnTask_7	Client has successfully cleared AP association phase
Aug 03 09:50:23.335	*apfMsConnTask_7	Client expiration timer code set for 1800 seconds. The reason: Client is scheduled for session timeout deletion (wlan with webauth)
Aug 03 09:50:23.335	*apfMsConnTask_7	WLC/AP is sending an Association Response to the client with status code 0 = Successful association
Aug 03 09:50:23.335	*apfMsConnTask_7	Client is trying to associate in 5 Ghz band
Aug 03 09:50:26.697	*DHCP Socket Task	Received DHCP request from client
Aug 03 09:50:26.698	*DHCP Socket Task	Received DHCP OFFER from DHCP server
Aug 03 09:50:26.737	*DHCP Socket Task	Received DHCP request from client
Aug 03 09:50:26.738	*DHCP Socket Task	Received DHCP ACK from DHCP server
Aug 03 09:50:26.738	*DHCP Socket Task	Client has entered RUN state
Aug 03 09:50:26.739	*DHCP Socket Task	Received DHCP ACK, assigning IP Address 192.168.154.83

[tanner.zaitt]

I moved the client device to another Access Point  from another WLC controller and there is no issue.

I checked bot WLC controllers and APs I didn't find differences on the configuration it's too strange.

Finally I moved the AP to the second controller and client device now has internet connection.
It's strange.

[marce1000]

 - You will need to perform and compare client-debugs from the two environments tried (working and not working) and compare to check what's happening

 M.

[Rich R]

I don't think this problem is visible in WLC debugs at all.

Packet captures might show something useful but otherwise you need debugs off the device itself because it sounds like a device issue.

[tanner.zaitt]

Now we noticed that:

The controller with issues not present mac addresses on the physical port of the core switch where the WLC is connected.

[tanner.zaitt]

We suspect a bug in Juniper QFX switch,  soon as possible we will plan to change the physical port and to see what will happen. 

By the way I did see these errors on the WLC controller:
*spamApTask3: Aug 03 12:56:00.961: %LWAPP-3-REPLAY_ERR: spam_lrad.c:38430 The system has received replay error on slot 1, WLAN ID 2, count 1 from AP 18:9c:5d:96:56:e0
*Dot1x_NW_MsgTask_0: Aug 03 12:33:04.622: %DOT1X-3-INVALID_REPLAY_CTR: 1x_eapkey.c:446 Invalid replay counter from client 46:fa:b2:23:62:c0 - got 00 00 00 00 00 00 00 02, expected 00 00 00 00 00 00 00 03
*Dot1x_NW_MsgTask_7: Aug 03 12:33:04.497: %DOT1X-3-INVALID_REPLAY_CTR: 1x_eapkey.c:446 Invalid replay counter from client 9a:50:0f:b9:d0:b7 - got 00 00 00 00 00 00 00 02, expected 00 00 00 00 00 00 00 03
On the second independent controller I don't see errors like these.
It's strange because the 802.1x is not implemented. It's maybe prepared but not implemented.

[tanner.zaitt]

Hi, finally we identified the issue, thank you for your answers and attention.

The issue was with Juniper QFX core switch.
One of the members of the stack stopped to learn mac addresses from WLC controllers.
We moved the WLC to the other member and mac address table was okay.

The issue is bug on the Juniper OS:
Juniper Networks - Problem Report Search

The system might stop new MAC learning and impact the Layer 2 traffic forwarding.

PROBLEM

When the issue happens, the following error logs could be seen:
BRCM_SALM:brcm_salm_periodic_clear_pending(),195: Failed to delete Pending entres forunit = 0, modid = 0, port = x, err code = -9
LBCM-L2,pfe_bcm_l2_mac_delete(),x:FDb MAC HW-delete failed(-6) for vlan-hw-token=4mac= invalid
To restore from the problematic status, consider rebooting the system in the maintenance window.

RELEASE NOTES

On QFX platforms, if there are a lot of MAC moves, the system might stop new MAC learning and lots of old MAC addresses might be stuck and couldn't be aged and deleted. 
Due to this issue, could have impact on layer 2 traffic forwarding and the customer service.

SEVERITY 

major

STATUS

open

RESOLVED IN

Release Junos

18.4R2-S4	X
19.1R3-S4	X
19.4R2	X
20.1R2	X
20.2R1	X

PRODUCT

MX Series,QFX Series

FUNCTIONAL AREA

software

TRIGGERS

This issue might be seen if the following conditions are met:
* QFX platforms
* Running with Layer 2 traffic forwarding
* A lot of MAC moves (e.g. receiving traffic which contains 16k different destination MAC addresses at the rate of 2000 packets per second)

Best Regards.