The rapid expansion of Wi-Fi as the medium of choice for home networking has introduced an explosion of new products from both new and established manufacturers. If you’re a developer or QA testing looking to prove your implementation works, or a service provider testing before deployment, you’ve probably learned that testing Wi-Fi involves more than just physical and MAC layer performance and interoperability. What else should you test to ensure that your devices will work well in the real world?
Watch our video as we show you:
- Wi-Fi testing topologies for gateways, access points, cloud managed Wi-Fi and Wi-Fi mesh nodes
- How Wi-Fi affects and is affected by scalability, performance, and protocol functionality
- How to save time and get better, more consistent results in a repeatable fully automated test environment
What should you test in Wi-Fi/Mesh enabled routers?
Of all of the things about broadband service that is most keenly felt by the end user, it’s the quality of their Wi-Fi networks. Wi-Fi is unique in that it is a complex networking system that users are aware of, and make purchasing decisions for consumer electronics and for broadband service around it.
Realizing this, many companies are building Wi-Fi products that specifically target the consumer rather than relying on the provider to deploy Wi-Fi service, using Wi-Fi mesh technology to deploy quality, reliable Wi-Fi throughout the user’s home or business. Some of these services even set their sights on offering broadband service through wireless means. That means, however, that while the expertise in these products is mostly in the RF and Wi-Fi mesh optimization realm, IP layer technology and applications are still required to work and work well. This is especially important for vendors who are building robust Wi-Fi mesh systems but using open source solutions for their implementation of higher layer functions.
But beyond performance (which is still important), what should you test?
DNS
DNS is simultaneously the most important and most finicky application when it comes to the end user’s network experience. Delays in the DNS network, browser caching, or problems with DNS relay on the home gateway can cause the user to perceive problems even when the Wi-Fi mesh network is working just fine. Since the DNS network is complex and spread over multiple networks, however, it can be difficult to simulate this in a lab environment and get a reliable picture of the subscriber experience.
CDRouter’s DNS test suites allow you to ensure that your Wi-Fi mesh enabled router can handle these intricacies, both both IPv4 and IPv6.
Connection Scaling
Even if your Wi-Fi’s physical layer and MAC are working perfectly, the central router’s IP layer capabilities are not always built well enough to handle the vast number of user connections that are likely to occur, particularly with the advent of more and more smart devices and the Internet of Things.
This is one of the common problems we see in our own lab. Often, a home gateway (even a good one) will begin to either refuse or drop Wi-Fi clients after as few as 10 clients! Obviously, this isn’t good if a user’s home network is now going to contain tens or hundreds of Wi-Fi connections.
CDRouter’s ability to simulate multiple Wi-Fi stations lets you stress the DUT’s capability to handle an increasing number of Wi-Fi clients as they come online. This feature can be combined with a number of CDRouter’s scaling tests, including DHCP, TCP, IPv6, etc. to see at what point your DUT can no longer handle new Wi-Fi connections, or handle them well.
Wi-Fi Association Scaling
Another important aspect of Wi-Fi testing, particularly for multi-AP systems, is the behavior of Wi-Fi association and disassociation when faced with many clients connecting and disconnecting. Read about this kind of testing in our companion article on Wi-Fi association testing.
Security
It’s been said time and again by both white and black hats that hackers are going after the CPE and home networking equipment.
One thing that Wi-Fi mesh vendors who are building routers cannot skimp on is security. Even when using open source, it’s vitally important to make sure that the router properly implements systems like firewalls, Wi-Fi security, port-forwarding, filters based on parental control features, etc. It’s also critical that devices do not contain any legacy vulnerabilities, and it is crucial that they have access to testing that covers new vulnerabilities as they are discovered.
CDRouter has a host of security tests available to ensure that your products are robust in this regard. From heartbleed to POODLE and more, the CDRouter team is always on the look-out for these and other vulnerabilities unique to home and small business network equipment. In addition, CDRouter nmap allows you to perform detailed scans of your product for open ports and other flaws.
Testing managed Wi-Fi in a lab environment
If your Wi-Fi systems are cloud managed, it can be difficult to perform testing in isolation while allowing the devices to connect to the resources they need in order to come online and function properly.
It’s possible test these devices by routing test traffic separately from the management and application traffic needed by the device under test. In CDRouter this is done with an add-on called “ICS”. ICS stands for “Internet Connection Sharing”, because it uses some of the same concepts as operating systems that share their network connections. With ICS, CDRouter is set up just as in closed loop, but any traffic that CDRouter knows that is not destined for itself - that is, traffic that is not part of our usual test cases or startup procedures - is routed through an interface attached to the external network (“application traffic” vs. “test traffic”).
Testing a particular AP in the mesh
From the perspective of the station, a mesh operates with a single SSID that is transmitted over several APs with different BSSIDs (its hardware address). The mesh network can be tested as a whole by CDRouter, or can be focused on a single AP in the mesh as the DUT by forcing CDRouter to connect to a particular BSSID. This is done with the lanBSSID testvar.
For example, if the SSID you wish to connect to was called “qa-net”, but the BSSID of the DUT was “00 11 22 33 44 55”, you could force CDRouter to connect to this AP by setting:
SECTION "802.11 Wireless" {
testvar lanSSID qa-net
.
.
.
SECTION "Advanced Wireless Settings" {
testvar lanBSSID 00:11:22:33:44:55
# testvar lanChannel auto
# testvar lanWirelessMaxClients 32
}
By running several packages with different configurations, each setting a different lanBSSID, you can validate each AP and test for scaling, performance, and more.
