WiFi's real name certification system is online, often not the end of trouble but the beginning of another. On the first few weeks, certificates fail to come together: they don't even pop up a page, receive a code, pass a certificate, but they don't go online, and they do not work at all. These problems are easy to look at, but if we do not create a sort of lineup, the carriers will be trapped in a fire-fighting cycle. We have developed the most common types of certification failure after being online, with a row trail that saves a lot of useless effort.
No proof page. Look at the orientation link first.
Users connect to WiFi, open browsers but enter the site directly or have no web alerts and have no access to the authentication page, which is a problem with the highest frequency. Root causes are almost always reoriented: uncertified users are not exactly drawn to Portal when accessing the extranet. The order of checkes is generally whether the terminal has regular access to IP, DNS resolution, AC/C, or gateway heavy orientation rules, and the authentication server address is not working. Most commonly we get DHCPs giving IPs, but DNS is misdirected by security strategies that cannot be triggered. Taking a test cell phone during the screening, one step by step from WiFi to the page, is much more useful than blindly rebooting.
I can't get the code. 80% of it is in text-message.
The authentication page came out, the cell phone number was lost and it was never received. This type of failure is almost always in SMS channels. Possible reasons are: the channel is restricted by operators, the supplier interface malfunctions, the number is judged by operators to be high-risk interception, text message content triggers sensitive words. Checking is done on two sides: on one side of the certification system, see if a request has been sent or returned to code; on the other hand, we use different operators ' mobile phone numbers. We suggest that back-up SMS access be secured before being connected, automatic transitions during major traffic anomalies and monitoring success rates and delays in arrival.
The certification goes through, but it's not online. Check out the release strategy.
User input authentication code to show successful authentication, but the web page is still not open."Fake success"Most confusing. The root reason is usually that after authentication, firewalls or AC did not take the terminal from"VLAN not certified"Move To"Authenticated VLAN", or release the access strategy is not in effect. Checks are made to see if the authentication system has been returned and issued correctly to network equipment and whether the network device has been implemented. We have encountered an occasional excess of release interface between AC and certification systems, which has been half-unexacted. Such problems require a log cross-check on the authentication system and network equipment, which can be easily misjudged.
It's always good and bad, mostly co-mixed or chain shaking.
Authentication is normal, and the peak period fails in large areas or a region is bad when it's good. The authentication server is sent to the top, the return chain drop package, the AP load is not evenly distributed, and the peak level is exposed. Checking for monitoring of peak periods: certification of CPUs and connections, delayed drop-in links, and the number of AAP tapes. We have done a yard where hundreds are fine, 2,000 people are certified at once, the server connection pool is exhausted, half the cards are locked up to get the identification code."Wait till it's done again."The time capture field data is more effective than static inspection.
The specific terminal is not connected. It looks compatible and protocold.
Andre can not connect to apples, or a brand phone is always failing. The end compatibility problem may be due to differences in the handling of Portal re-direction, mistrust of HTTPS intercept certificates, different realizations of captive network tests. Apple equipment is particularly special, with its own network detection mechanisms and some certification pages' jump logic that fight. Checking is done using multiple brand terminals to focus on the performance of authentication pages on the corresponding system. We suggest that the authentication page should be end-suited and provide one."Manually open authentication page"The user can move in case the auto-jump fails.
The batch failed.
If all users fail simultaneously at one point, it is not essentially local configuration but external dependence: SMS gateways, identity docking systems, public security reporting platforms, and DNS services. Checking the health of these external services immediately to see if there are any corresponding errors in the system and alerts. We emphasize that all external reliance should be brought to surveillance and warning when the volume fails.
Check account status of users that fail repeatedly
Individual people can't pass, and others are normal. Most of them are out of this account itself: blackened, limited frequency, states abnormality, and identity systems. Checking the authentication history, failure codes, restrictions on records in the certification system. We have seen users get a dozen times to access the code, trigger the limit frequency is temporarily locked and we don't know it. There are accounts that are disabled in the identification system but WiFi side does not synchronize, and authentication fails forever.
Building a screening manual is better than putting fire out of people's bodies.
Each of these questions is viewed from the bottom up and is extremely inefficient. We suggest that we produce a failure-checking manual on the way online, which will make clear the path to check each type of phenomenon, the usual commands, log locations, and who we contact. The first line of action will be able to track most of the problems for ten minutes. The manual will also need to be continuously updated with the problem accumulated and new failures added."Waiting for a complaint."Changed"Watch the board."The ability to check has been deposited, and the troubles that come down on the line actually have.