After several projects, it is clear that the problem with WiFi certification systems is often not core functionality itself but rather configuration details in deployment environments that look invisible.——A few dozen top-of-the-ground APs, or a park covering hundreds of APs.——If there are several parameters for the front, then there will be a variety of strange things when you get online: some regional certification pages cannot pop up, others can authenticate and then jump back into Portal in a few moments, and some places not even SSID.
AP gateways point to and authenticate the network availability of servers
This is one of the most problematic and undetectable points in multiAP deployments. Most WiFi certification processes are as follows: when end-associated APs have access to IPs, all HTTP requests are reoriented to Portal authentication pages before they complete authentication. This redirection action is usually done by AC or gateway devices. If an intermediate device in the AP uplink does not properly configure a gateway address, or if the authentication server's IP is not on the terminal reach section, there will be situations where the terminal can take IP but cannot open the authentication page.
One of the case examples we have encountered is that one hotel project, AP certification in the lobby area, was normal, but the third floor guest room had no APA-scathing to play with. The last thing we found was a static route missing on the three-storey switchboard, which made it impossible for the AAP terminals on the third floor to get access to the IP assigned by DHCP. Once the second-floor switch was filled, the problem disappeared. This suggests that the more number of APs and the more complex the segment division of the network, the more the road availability needs to be checked earlier, not until they are deployed.
DNS path for Portal URL
Another easy to ignore is DNS. Before the terminal completes authentication, the first HTTP request sent will be redirected to Portal page. The URL of this Portal page is usually a domain name and the end needs to do a DNS first. If the DNS server is not configured properly, the solution will be used.——For example, the DNS sent by DHCP is not a public network DNS but an internal DNS, but this internal DNS has no records of the solution to Portal domain names.——The terminal is stuck at the DNS's parse step."The authentication page has been loaded but never open"。
The solution is simple, and two ways to do it are: either DNSs from DHCP point directly to a DNS that can decipher the Portal domain name or hand-in-hand A records of the Portal domain name on internal DNS. But the key is that in multiAP deployments, different types of VLAN DHPs may be configured differently, with each VLAN checking for consistency under DNS. The most common situation at project sites is that VLAN matches are correct for testing the environment, but DNS from another VLAN match is wrong for producing environment, only part of the floor is problematic after being connected and the path of screening can easily be misdirected.
NAS-Port-ID transmission between AC and authentication server
WiFi authentication system for RADIAS, where AC carries NAS-Port-ID properties in a message when transmitting Radius' request and tells the authentication server"This terminal is from which AP and which SSID.". This attribute is important for the billing system, location traceability, and trouble positioning. But there are a significant number of AC devices that do not match the format of NAS-Port-ID in the default configuration with the expectations of the authentication server or simply not.
Like some brand AC, default NAS-Port-ID format is"AP MAC address+SSID number+Radio number", but the authentication server expects"AP name + VLAN". The format mismatch does not lead to a failure of authentication, but it causes the key location information to be lost in the certification log and after-the-post problem does not know which AP is for the terminal link. Before deploying in multiAP environments, one test AP must first confirm the formatting of NAS-Port-ID and align the authentication server with the field logic, otherwise the log will be a pile of scrap data when it is online.
The authentication strategy is isolated in multiple SSID settings
A WiFi certification system is relatively simple to configure if it serves only a single SSID.——For example, an SSID on the staff network, a SSID on the visitors network, and an SSID on the internal equipment network.——Each SSID may be certified differently: 802.1X for employees, text-message for visitors, and MAC White List for equipment online.
The real problem scenario is that if different SSIDs have a different authentication template on some AC devices but under the same AP Group, there may be a pattern of interlocking.——The terminal under visitor SSID went to the employee's RADIUS server for authentication. On the surface it looked like"Authentication failed."But the root reason is that AC sent the authentication request to the wrong target. It took time to check it, because what you see from the terminal side was"Authentication failed"It is not possible to see which RADIUS was sent. All SSID certification template mapping should be reviewed before deployment, and confirmation that there are no cross-references and each SSID has the correct authentication method and correct RADIUS server address.
Maintain authentication status for terminal roaming
The multi-AP deployment terminal is normal for travelling between APs. If WiFi certification system does not support rapid roaming or certification status maintenance, the end is required to re-validate every time a cruise switch of AP. This is very bad in hotel and campus scenes, where users walk through corridors from one AP overflow area to another, WiFi breaks down and is replayed Portal.
The key parameters are two: one is PMK Cache and one is OKC (Opportunistic Key Caching). 802.1X, if AC supports PMK Cache, no need to re-walk the full EAP authentication process when a terminal moves to another AP, just four steps in handshake, which can be controlled within dozens of milliseconds. Portal certification usually relies on an online user list on AC to determine whether the terminal has been certified.——When terminal switch AP, AC through querying the online user list, if it is found that this MAC address is in authentication pass status, it will not play Portal again. But the mechanism relies heavily on AC for updating the online user table, and some have hundreds of milliseconds to a few seconds delay in the AC switch, which will be felt by the end during this period"It's broken and connected."The experience.
These configuration details are not a technical problem of any kind. But the more AP environments are magnifying mirrors, which can be multiplied.