AC connected to IMC authentication portal mac-trigger seamless users get disconnected after a period of time requiring re-authentication issue

2025-04-28 11:03:09 Published
  • 0 Followed
  • 0Collected ,891Browsed

Network Topology

AC bypass core, local forwarding, connect IMC, service template configuration portal+mac-trigger authentication


Problem Description

On-According to on-site feedback, after the AC was upgraded from the old version to the latest version, the terminals under the client portal + mac-trigger service template would experience portal disconnection approximately every 45-46 minutes, requiring re-authentication.


Process Analysis

1. Since the issue is easily reproducible, enable debug mode for UAM and Portal logs on IMC. Then observe a terminal that has already reproduced the issue after completing Portal login. As expected, after about 45~46 minutes, the terminal goes offline, and the Portal entry on the AC disappears, requiring re-authentication. At this point, checking the Portal logs (debug level) on IMC reveals that IMC sent a req_logout message to the AC upon reaching the arrival time, causing the terminal to go offline.

Upon checking the configuration on IMC, relevant heartbeat timeout settings were indeed found:

The specific mechanisms will not be elaborated here. It should be noted that after adjusting these two parameters to 0 on the IMC (i.e., disabling the heartbeat function), only terminals that complete Portal login after this function is disabled will no longer obtain the heartbeat attribute. Terminals that logged into the Portal before disabling the heartbeat function will still go offline after approximately 45 min. If they log in again after the heartbeat function is disabled, they will no longer be affected by the heartbeat attribute and thus will not disconnect.

2. However, another point of confusion is: The service template is configured with MAC-trigger authentication. After the terminal expires and the portal disconnects, it should automatically complete re-authentication via seamless authentication. Moreover, the age setting for seamless entry on IMC is relatively long, and no disappearance of seamless entries was observed during fault reproduction. Could it be that MAC-trigger authentication did not take effect?

3. After resolving issue 1, to verify issue 2, the portal entry of a terminal was deleted on the AC using: portal delete-user username xxx, to verify its mac-trigger function. It was found that the authentication failed, so debug portal was enabled on the AC, and UAM and Portal debug logs were simultaneously enabled on IMC to reproduce the issue.

The general process for a portal mac-trigger terminal going online again is shown in the figure below [Internal lab environment diagram, IP address and other details are not confidential].

Troubleshooting revealed that during the mac-trigger seamless authentication process, after the AC sent req_macbind_info to the IMC, the IMC replied with ack_macbind_info (errorcode = 0). At this point, the IMC should have sent req_challenge (CHAP mode) or req_info (Portal 2.0 PAP mode) to the AC, but the IMC did not send this message, causing the timer on the AC to time out and the mac-trigger authentication to fail.

4. After further feedback of this information to IMC, the AC feedback sent to IMC in the mac-trigger message (i.e., req_macbind_info) was version 2.0 and did not carry the field (EX_ATTR_START_TIME = 113 user online start time). As a result, after IMC replied to AC with ack_macbind_info (errorcode=0), it no longer sent req_info or req_challenge to AC, leading to unsuccessful silent authentication.

5. So why was the mac-trigger message sent by AC to IMC version 2.0, and why did similar failures not occur before the upgrade?

After consulting the colleagues who executed the change and checking the AC command display history-command all, it was found that after the AC upgrade, they configured version 2 under the original mac-trigger server.

As for why this configuration was added, their explanation was that they saw portal 2.0 configured below on IMC and mistakenly assumed that the version under mac-trigger-server should also be consistent, when in fact it was unnecessary.

 

 

 


Solution

Execute undo on the AC to revert the version 2 under mac-trigger-server back to the default version 1. At this point, the req_macbind_info message sent by the AC to IMC changes to version 1, and IMC no longer verifies the following field attribute: (EX_ATTR_START_TIME = 113 User online start time). Subsequent mac-trigger authentication proceeds normally.

Please rate this case:   
0 Comments

No Comments

Add Comments: