Example of AP containment
He all,
This is a quick example showing AP containment. The problem statement was the clients were not able to connect to this single AP on a specific SSID. During the course of debugging the issue, the AP was replaced and still the problem persisted. Upon further investigation it turned out that neighbor’s AP were containing our production AP.
The debugs showed the client abandoning the EAP process and associating and re-associating back to the same AP and failing again during the EAP handshake.
*Dot1x_NW_MsgTask_1: Jan 12 16:52:45.154: f4:5c:89:be:14:a9 Processing Access-Challenge for mobile f4:5c:89:be:14:a9
*Dot1x_NW_MsgTask_1: Jan 12 16:52:45.154: f4:5c:89:be:14:a9 Entering Backend Auth Req state (id=37) for mobile f4:5c:89:be:14:a9
*Dot1x_NW_MsgTask_1: Jan 12 16:52:45.154: f4:5c:89:be:14:a9 Sending EAP Request from AAA to mobile f4:5c:89:be:14:a9 (EAP Id 37)
*Dot1x_NW_MsgTask_1: Jan 12 16:52:45.154: f4:5c:89:be:14:a9 Reusing allocated memory for EAP Pkt for retransmission to mobile f4:5c:89:be:14:a9
…………………...
*apfMsConnTask_7: Jan 12 16:52:51.225: f4:5c:89:be:14:a9 Processing assoc-req station:f4:5c:89:be:14:a9 AP:a0:ec:f9:d8:fa:20-01 thread:15147690
*apfMsConnTask_7: Jan 12 16:52:51.226: f4:5c:89:be:14:a9 Reassociation received from mobile on BSSID a0:ec:f9:d8:fa:20 AP wlsn01-41-cap6
The above cycle would keep repeating over and over
If you see the below screenshot the arrows show the deauthentication frames sent out to broadcast address. Pay close attention to the RSSI of the frame which is -70dBm
Look at the highlighted frame now and check the RSSI (-49 dBm). This is a regular frame from the production AP.
I selected the deauth frames in the capture and 14.5% of the total frames were deauth frames.
This was a tricky issue and not commonly seen out in the field.
Note: The data shared above is only meant for educational purposes