Go to Main Contents

:: Industry developments

The deployment of the WiFi certification system has revealed that AP compatibility is the biggest pit.

I was particularly impressed by one of the projects. The client had a three-year Arba Wi-Fi network that ran well, and then went to WiFi certification because it was required to comply.

Your position:Home > Content Centre > Industry News > > Text

I was particularly impressed by one project. The client had a three-year Arba wireless network, running well, and then went to WiFi certification because compliance requirements were required. This is supposed to be a Radius server with a Portal page, which turned the project from two weeks to almost two months.

The same manufacturer has different types of AP behavior.

The most devastating thing is the APA compatibility. Clients don't buy it once, buying four or five batches of AP-205 to AP-515 over three years. Same brand, same series of equipment, should be configured in a consistent way, but we later find that this is not the case.

The old AP-205 solid version is parked on an older version that does not support the coA function we want. CoA is a very important capability in WiFi authentication system.——When the user package expires, or when the manager kicks people in the backstage, or changes strategy, the Radius server needs to notify AC/AP of real-time readjustment of user's network privileges through a CoA submission. If there is no coA, it will only be able to apply the new policy until the user reconnects again."Vacuum period"。

What is more problematic is the Portal recalibration of behaviour. The same equipment is Arba, where AP-315 will re-direct the user ' s HTTP to the authentication page in a Portal certification site, which is done through HTTP 302, standard behavior. But AP-505 under a solid version uses HTTP 307, while some old Android phone has problems with 307, and it's wrong to make mistakes. We finally have to fix it by upgrading the full web and adjusting the AC side configuration parameters, but this process has wasted much time to locate the problem.

The multi-brand web scene is a nightmare.

If it's a brand, you can at least get some back-up from the factory. It's a historical multi-brand web site. I've seen a park with an AP for H3C for office buildings and a sharp set of equipment for gyms and cafeterias. The three brands have a system of WiFi certification that is attached to the AC for different manufacturers.

The first question is the difference between Radius properties fields. H3C and H3C place an AP MAC address in Called-Station-Id fields, and a sharp entry of AP names. You have to write strategy on the Radius server——Like what?"Only specific packages are allowed for users in a given area"——You have to judge which AP access is based on Called-Station-Id. If the field is not all three, the strategy cannot be written.

The second problem is the difference in how VLAN sends it. After 802.1X certification has been successful, Radius can tell AC which VLAN user to divide through the Tunel-Private-Group-Id properties. But some manufacturers require this value to fill VLAN ID (number), others request VLAN Name (string) and also a required format."VLAN=123". If you're in the wrong format, AC simply ignores this attribute, and the user falls into the default VLAN, authenticating successfully but not online, and checking is extremely painful.

The loss of the AP side log makes the error position guess

WiFi certification systems usually have two perspectives. First, the Radius server logs can see whether a request for authentication is there, whether it is accepted or rejected; second, AC logs can see how user-associated status and strategy are going to be sent. But AP itself is often a black box.——Many APs default to not open a debug level log, and even if it does, the log will cover only a small period of memory cache.

There was one time, a user gave back and said,"It's connected, but it'll be off in a few minutes."Radius and AC's logs were clean and clean, and no anomalies could be seen. We contacted AP vendor technical support to open the AP wireless debug log remotely. It was only discovered that the PMK cache had not been properly updated during a fast-walking 802.11 r, which led to four handshakes. This issue is not strictly a pan for WiFi certification, but users don't care whose pot it is, and he knows nothing about it."The certification doesn't work."。

So every time I do the WiFi certification system project, I'm going to do one thing before it: take out all the models of the client site and run the authentication process from head to end in a minimal testing environment. Run without knowing, I can always find several compatibility problems. The cost of early detection and scheduling is much less than getting involved with the company when you go online.

Access Program I'll be right back. Telephone counselling