There are issues with portal authentication and ACK_AUTH message of the portal server on WX5510E at a certain location.

In a traditional network environment, the portal server is a third-party server, and the versions used are all the latest versions from the official website

In the production environment, after the server has been running for a period of time, the serial number that is generated in the (ACK_AUTH message) between the AC and the portal server during the same authentication process is not consistent, but users are still able to successfully go online.

First, an analysis of the logs for the AC and portal server reveals the following characteristics:

It was discovered that the logs for the AC were consistently normal, but after the third-party portal server had been running for a period of time, the serial number that was received in the ACK_AUTH message on the portal server was different from the serial number in the REQ_AUTH message. It is suspected that the third-party server is having issues parsing the portal messages from our company. The on-site feedback was that the third-party server is using the portal 1.0 protocol, while our AC is using the portal 2.0 protocol, which is also backward compatible with portal 1.0. After attempting to test with the third-party server modified to use the portal 2.0 protocol, the following issues were encountered:

The issue appears to be that the AC is considering certain attribute properties to be non-compliant and cannot be assembled into the RADIUS message, but the attribute properties are actually sent from the server to the AC in the REQ_AUTH message. One possible issue could be that the server is classifying the attributes differently than our conventional implementation, but without packet analysis on-site, it is difficult to determine the cause. As a result, it is suspected that the portal implementation of the third-party server is not compatible with our system   

Through testing and contacting the third-party server vendor, it was confirmed that the issue was with the implementation of the third-party server's portal protocol. After replacing the server, the portal message interaction became normal again.