The Wi-Fi network is operational and AP is installed, but the user can't either pop up or get a few login.——This is a classic scene that many projects have encountered since they were launched. The integrated dealers go to the field and check, and hardware is online, full signal, backstage configurations are not obvious, but it's an experience.
The most common problem is the DHCP delayed distribution. When users connect to SHID, the terminal needs to get an IP address from the DHCP server before it can pull a Portal page. But some equipment DHCP clients behave more conservatively and wait for several seconds to test network connectivity before applying for an address. If DHCP reacts slowly, users will feel that it is easier to try again without having a half-day post on WiFi. This solution can be extended by the time of the DHCP lease at AC or the gateway, while confirming that the number of addresses in the DHCP Address Pool is sufficient.——The number of users exceeds the size of the address pool, new users will not get their addresses and Portal pages will be unattainable.
The second easy to ignore is the browser intercept. Many windows and redirections are intercepted by default for the sake of saving traffic and protecting privacy. Users are used to automatically eject Portal when chaining hotels or malls to WiFi, but if there is a difference in settings in business environments with mobile systems or security software, certification may be diverted away from target-oriented applications, and users have no idea about having Portal pages. Some compatibility tests need to be done early on the terminal side to confirm whether the mainstream default settings will normally pop up.
The third reason is DNS configuration error. Portal authentication works on the basis of mandatory re-orientation of IP addresses——When users visit any site, the gateway intercepts the request and 302 is redirected to Portal. If DNS solves a problem, the user terminal may first decipher the domain name as an hijacked address or simply disassemble the failed link, leading to a break in the redaction chain. The most direct way of checking is by pinging an out-of-area name at the end to see if the returned IP is the IP of Portal Gateway. If not, check the correct DNS relay configuration of the gateway and confirm that there are abnormal DNS relays on routers or firewall side.
The fourth pit is that the Portal server itself lacks performance. Companies usually focus on Portal styles and functions when selecting a model, but they can easily ignore the co-mapping capabilities of the server ' s end.——If the Portal server has only one node, and does not balance its loads, a peak period will result in a slow page loading, certification time-over, or even direct overloading crash. This problem is difficult to detect during the project testing phase, because the test scenario is much lower than the actual production environment. It is proposed that a pressure test be conducted at the programme design stage to make clear the true and capped authentication system.
There is also a less easy to imagine reason for the certificate problem. More and more businesses are now asking Portal to use HTTPS on their pages to prevent authentication information being intercepted by intermediaries. But self-signed certificates trigger security warnings on mobile devices, as users see."Certificate is not credible"The solution is to use a certificate issued by the private company ' s CA in an enterprise, which gives advance bulk delivery of root certificates at all terminals so that encryption is secured without triggering a security warning from the browser.