Any campus network Authentication & Billing is online, and the first two weeks were the hardest. It's not the system itself.The real users have various boundaries in the real network environment, and the test environments are simply not measurable.We've delivered several college projects, and we've concluded that the user complaints at the beginning of the visit are concentrated on a few fixed technical pain points.
The first high-level complaint point isPortal page is not available.. This is the most typical problem in all Authentication & Billing systems from the beginning of their initial onlineization. The principle is not complicated: user terminals launch HTTP requests after WiFi connects, AC detects uncertified terminal and redirects requests to Portal pages on authentication servers through Portal protocols. But in real environments, this process goes through at least five stages: terminal→AP→AC→Core switch→Portal server, any loop problem will cause Portal to fail. The three most common reasons are: the terminal DNS cache has failed in its re-directionalization.——The user has previously been able to access other WiFi, DNS caches old resolution results; second, the Portal version of the protocol between AC and Portal servers is incompatible and some manufacturers ' AC have its own extension field on the Portal agreement implementation that is not fully consistent with standard protocols; third, the HTTPS request processing——Many mobile browsers now default to HTTPS, but Portal reoriented the treatment of HTTPS is much more complicated than HTTP, and if an AC does not properly configure HTTPS hijacking or SSL certificates, the first page that users open will fail if it is HTTPS.
The second HF complaint isAfter the certification, we can't get on the net.. The problem is more headaches for the carrier than Portal can play, because what users see is that"The certification has been successful.", but the flow is not working. Check it down and root causes are often sent under permission. Authentication & Billing requires user privileges to be sent to AC after authentication has been successful——The VLAN, QoS strategy, the IP section that you can access. If the RADIUS CoA (Change of Authority) report between AC and the authentication server is not sent or sent but not executed by AC, the user's status is on the authentication server"Online"On the AC or..."Not certified". In another case, the dial-up mode, which certified successful children to dial up a PPOE to the operator Bras, takes seconds to dial-up the switch itself, and if it is too short or the operator BRAS is slow to respond, it will result in user-end certification success but the browser cannot turn on the web page.
The third issue is particularly vulnerable to neglect:Some old terminal equipment could not complete the authentication processThe university network environment is extremely complex.——The students have cell phones ranging from hundreds of Andre machines to the latest iPhone, which spans three or four years. There was a project where an online group of Andre phones that left the factory around 2018 were clicked and submitted without a response after entering the account code on Portal's authentication page. A front-end frame used for Portal's page was checked long enough to be incompatible with the WebView version of the system, resulting in the JavaScript incident not being properly triggered. The final solution is to have the Portal server do terminal type testing, downgrade the low WebView page template and remove JS interactive logic from the submission of a pure form.
The fourth complaint focused onMAC Seamless Authentication ExpiresSeamless Authentication is based on the principle that after first authentication, the authentication server records the user's MAC address and account number binding, and when the next terminal is connected to WiFi AC automatically initiates the authentication request without requiring a re-entry of the account code. But in actual operation, NatSHELL_SEAMLES_AUTH has a much higher probability of failure than it would have been. The random MAC address function (iOS and Android have opened by default) at the cell phone end is a major reason.——The binding of the authentication server records is automatically disabled every time even the MAC addresses generated by WiFi are different. One more hidden reason is that some old APs report to AC on frequent roaming switches late or inaccurately, which leads to an inconsistency between the MAC address and the actual terminal MAC when they launch NATSHELL_SEAMLES_AUTH.
The fifth area of complaints isThe set cost is abnormal.. Users of the monthly package were down early at the end of the month, and users of the traffic package found that they actually consumed a lot more traffic than the mobile phone system counted, and that the balance was not received in real time after charging. These problems often do not lie behind the fee logic itself.Delays in reconciling mechanisms and data synchronizationFor example, the daily stoppage check script for a monthly package is performed at 2am. If a month ends (e.g. 30) and the script fails without warning, user 31 is misdirected. In traffic statistics, the system counts network-level traffic (including agreed costs), while mobile phone end counts application-level traffic, which naturally varies 10-15%.——This discrepancy will inevitably lead to a large number of complaints if users are not informed in advance.
The first complaints are handled online.The most effective is not how fast the technology programme has been changed, but rather a transparent and responsive information system.. A clear answer for each user——Whether the problem is in the process of being repaired, user configuration problems or temporarily unsupported——Many school information centres do not have FAQ pages and self-help drainage guidelines before they go online, which leads to students calling the information centres whenever problems arise, duty workers are simply unable to get through, and a large number of repeated complaints and emotional escalations result.
The most real mirror is the distribution of user type complaints and response efficiency for the previous two weeks. If a project team can pre-empt each of these five high-profile issues before they go online, it's not possible to see if they are going to be able to do so.——Portal Compatibility tests cover mainstream terminal models, RADIUS CoA hairs are fully end-to-end validations, MAC Seamless Authentication is performing pressure testing for cross-AP cruise scenarios, billing logic is a full process drill to make boundary dates, self-help FAQ pages are ready in advance——So the initial shock period on the line can be reduced from two weeks to two or three days.
Finally, there is a small suggestion:Do not open full user during the first week of online. The teachers and students of a dormitory building or two colleges are released as greyscale, observe for three days, fix the problems they reveal, then open them up. This is a few days slow, but it's actually much more time than getting full access to the fire. Many projects are too urgent.——The leadership demanded that one day be on the line and, as a result, all were opened with 400 or 500 complaints called on the first day, while the entire Information Centre did not sleep for a week.