Today’s market for wireless routers, access points, and mesh networks provides an overabundance of choice for consumers. Perusing options online or walking through a local brick and mortar retailer can be a headache inducing experience. Selecting the right solution requires considerable research, evaluation of benchmarks or reviews provided by reputable review sites, and a pinch of luck related to not receiving a lemon or incomplete product. Sometimes, manufacturers may “pull a Volkswagen” with respect to the validity of their test results or operational capabilities. Cheaters never win, and the associated penalty for doing so always incurs some cost.
The level of support by the various manufacturers for remediation of security vulnerabilities, performance problems, and general stability issues can be a sore spot in overall satisfaction when investing in such a solution. If a manufacturer gives up on forward support for a given model, there have been viable open-source alternatives that can be flashed to replace the subpar standard firmware. Solutions such as Tomato, DD-WRT, and OpenWRT can breathe new life and improved performance into legacy wireless routers. Our personal experience with DD-WRT on a Cisco (a.k.a. Linksys) WRT120N router resulted in the remediation of connectivity issues with VPN solutions, operational capability to successfully use AirPrint with a wireless Canon printer, and a lack of daily reboots for the device.
Although the upgrade process and use of the granular controls within these potent alternative solutions may not be everyone’s cup of tea, the fact that they exist and offer up all one could ask for at a prosumer/SMB level is an effective means to avoid the potential to generate e-waste via a “rip and replace” migration strategy. However, there can be unintended consequences related to providing granular control over aspects of a system that is designed or planned to adhere to guidelines established by the FCC.
Back in September, the FCC communicated its desire to restrict open source firmware application due to the potential for modifications to interfere with frequencies that are normally restricted. While it may be solely advantageous to ensure the transmission capabilities of one’s wireless network have enough strength to mitigate neighboring pollution in areas with dense population of people and competing wireless networks, the overreach that is afforded with a modified firmware may introduce the risk of also stomping on neighboring frequencies that are not normally utilized for consumer-grade Wi-Fi.
TP-Link decided to get an early start on complying with the FCC’s requirements and has formally announced their strategy for adherence. Of all of the available wireless solution providers in the market, it is our opinion that they’re not in a solid position to do this. As was noted in the linked Ars Technica article, TP-Link does provide country-specific firmware. Attempting to access the parent tplink.com site within the US (sans any browser protections) will redirect you to tplink.us. Firmware differs considerable between the two, and missing dependencies between the Tether smart phone app and legacy firmware will either not function correctly or result in an unexpected reboot of the router.
The tplink.com firmware has a myriad of fixes that have still, as of this writing, not been replicated in the tplink.us firmware. This same situation exists for other makes and models within their product line (excluding their Google OnHub wireless router for obvious reasons). If there’s any vendor that DOES benefit from the capability to implement a more robust open-source offering, it certainly is TP-Link. Unless they’re planning to turn around their inconsistent nature of firmware support for the devices that will be produced moving forward, there’s a good chance that value-conscious consumers will look elsewhere for their wireless fix.