[WX5860H/WA6338] Experience case on Windows 802.1x authenticated terminals going offline actively during remote access [reason code:2019]

The topology of this site uses adcampus as the radius server + AC-FIT AP for remote 802.1x authentication.

When PC1 used the remote desktop function built into the Windows computer to connect to the peer device PC2 on the same local area network (LAN), PC1 displayed the message This computer cannot connect to the remote computer. It was later found that PC1 could not ping the IP address of PC2, and subsequent investigation revealed that the wireless connection of the remotely accessed PC2 had been disconnected.

1. In the AC probe view, use command display system internal wlan client history-record mac-address xxxx-xxxx-xxxx to check that the offline reason corresponding to the offline time point is 2019.

2. Then use command dispaly system internal wlan client history-record help reason-code 2019 to determine that the offline reason isReceived dissociation packet in Userauth state, which indicates the terminal actively sent an offline packet

3、Captured the following debug on the AC,

debugging wlan client mac 1234-2323-2345 (terminal mac)
debugging wlan usersec all
debugging radius packet user username
debugging dot1x event
debugging dot1x error

The reason for the terminal going offline can be seen as receiving an active offline message sent by the terminal:

Received deauthentication or disassociation request from client in Userauth state: Reason code=8.
 A user failed 802.1X authentication.Reason:Received dissociation packet with reason code 8 in Userauth state.

4. Capturing debug ar5drv for radio 1 on the AP shows that the terminal actively sent a Disassoc message, and subsequent authentication attempts also fail

5. Therefore, further capture the wlan-report-latest report of the terminal. The fault time point shows that 802.1x identity verify has restarted, with the reason being: Onex user has changed (OneXRestartReasonOneXUserChanged 802.1X verify restart is the result of user change. This may occur if the current user logs out and a new user logs in to the local computer).

6. Check the offline reason on adcampus as [request restart], which also indicates this is an action actively triggered by the terminal. There are three possible reasons, as shown in the following two images.

7. This basically confirms that it is an issue with the Windows terminal's own mechanism. Simply perform a retrieval in the network to check for corresponding solutions.

1. Workaround: Temporarily identified as a Windows mechanism issue. Change the following to user identity verification, then save 1x account credentials. Only the remotely accessed computer needs this setting; the initiating computer does not.

2. Additional testing: The issue persists when using our inode.

3. If you do not want to modify basic Windows settings, there are two methods for quick network recovery:

(1) Log in to another account, then log back into this account; remote connection will not drop.

(2) Create a new service template, change the SSID, configure it exactly the same as the gzb one, then reconnect to this SSID. After reconnecting, remote access will not drop even when switching back.