Slashdot Mirror
FCC Requires TP-Link To Support Open Source Router Firmware
An anonymous reader writes: Earlier today, the FCC reached a settlement with TP-Link over Wi-Fi router interference. Most of the agreement was routine, addressing compliance with radio emission rules.
But the FCC also did something unprecedented. It required TP-Link to support open source firmware on its routers. You might recall that, last year, the FCC caused a ruckus when it mistakenly suggested it was banning open source router firmware. In fact, the FCC only required that router vendors implement protections for specific radio emission parameters. But the FCC didn't work with router vendors in advance to maintain open source compatibility, resulting in certain vendors (including TP-Link) trying to lock down their routers.
The FCC eventually issued a clarification, but the damage was done. Only recently have a couple router vendors (Linksys and Asus) affirmed that they will continue to support open source firmware.
Today's settlement is a milestone for the FCC. The agency is finally doing something, with deeds and not just words, to demonstrate its support for the open source community. It would be better if the agency hadn't created this mess, but they deserve serious credit for working so hard to fix it.
But the FCC also did something unprecedented. It required TP-Link to support open source firmware on its routers. You might recall that, last year, the FCC caused a ruckus when it mistakenly suggested it was banning open source router firmware. In fact, the FCC only required that router vendors implement protections for specific radio emission parameters. But the FCC didn't work with router vendors in advance to maintain open source compatibility, resulting in certain vendors (including TP-Link) trying to lock down their routers.
The FCC eventually issued a clarification, but the damage was done. Only recently have a couple router vendors (Linksys and Asus) affirmed that they will continue to support open source firmware.
Today's settlement is a milestone for the FCC. The agency is finally doing something, with deeds and not just words, to demonstrate its support for the open source community. It would be better if the agency hadn't created this mess, but they deserve serious credit for working so hard to fix it.
That's what I thought, until I bought one (TP-Link Archer C7). The hardware seems decent but when I tried to load OpenWRT I ran into the "safeguards" that the article is talking about. I was finally able to get an alternate firmware installed, but it certainly wasn't easy (or at least, wouldn't have been easy for a less technical user).
Enigma
You can plug any router directly into the FiOS ONT's Ethernet port and it will work. Sometimes you have to clone the MAC address of their router and reset the ONT though. I've done this on several FiOS installations in various states for years, it works.
Don't think any ISP can force you to use their's. FIOS ones i guess could force their's on you but you should be able to bridge it and use your own anyway.
Sure they can:
1. Break the user's feed by reconfiguring things in the company's plant - and do it incorrectly.
2. When the user calls in to get things fixed, tell him that the problem is in his modem and you don't support that modem - or any modem not purchased from the ISP.
3. The user must buy a modem from the ISP before the ISP will bother to fix things at their end.
4. Profit!
I recently had a ONE MONTH! (to the day) AT&T DSL outage. (My town doesn't have fiber to the home, and fiber to the curb got bundled with the U-verse tarbaby and had several other downsides. So I was on legacy DSL. And as an early adopter it was VERY OLD technology - in Internet Time.)
In the process of decommissioning some of the now-nearly-redundant DSLAMs (as they get most of their customers moved over to U-verse), they moved my legacy DSL line to a new box. This box didn't support the modem I had, and they also screwed up the propagation of the routes so the packets didn't reach the new DLSAM. But they didn't bother to tell me (until they finally let me talk to an actual tech, nearly a month later after purchase of two replacement DSL modems) that they'd made any changes.
My legacy DSL modem was old enough that the web configuration interface was an extra-cost option - which AT&T hadn't chosen to buy. They gave me instructions for getting to the interface (IF it had been present) - and we were both convinced that the modem had failed.
I was unable to find the replacement that they recommended at any (silicon valley!) dealership - including the AT&T phone store. So I purchased a Linksys DSL modem at Best Buy that claimed AT&T (non U-verse) capability. Hooked it up, got the web interface. Had ATM sync (yay!) but no ping (boo!).
Called service to get things running. "Sorry, we don't support that modem. We don't support any modem that we don't sell."
So I bought ANOTHER DSL modem - from an AT&T store - that the store claimed was supported. Also a Linksys. An older model with fewer features, but with AT&T approved firmware and from their own store. And about 1 1/2 times the price.
NOW they were willing to debug the problems in their own plant. After another week, being switched to still another DSLAM (becaue the first one they'd put me on was on a router that had also been decommissioned), and having the routes re-propagated, I was able to get ONE of my (changed!) fixed IP addresses live.
And by this time I was past the return date for the modem from Best Buy. So I ended up with store credit, rather than a refund.
And the new DSL connection is PPPoE over ATM, rather than Ethernet over ATM (which the new DSLAM doesn't support). That adds 8 extra bytes to every packet.
And the official modem I bought from AT&T doesn't support a subnet, so I have to run in bridge mode to get more than the router's own address. I won't get the rest of my (changed!) fixed addresses up until I have time to configure a PPPoE daemon on the firewall/router machine (which is currently running software from before the PPPoE standards were finalized...).
B-b
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
If you read far enough into what the FCC has actually required TP-Link to do you'll quickly realize this is worse for free and open source software than TP-Link locking down its routers. Go look at https://apps.fcc.gov/edocs_pub... (the settlement PDF links to this as a source document). In fine print:
"the Commission required . . . device software that controls the RF parameters that ensure compliance with the Commission’s technical rules for preventing harmful interference must be secured. The purpose . . . is to prevent modifications to the software that could, for example, . . . enable tuning to unauthorized frequencies, increased power above authorized levels, etc. The rule is not intended to prevent or inhibit modification of any other software or firmware in the device, such as software modifications to improve performance, configure RF networks or improve cybersecurity.”.
What this means is that the community won't be able to add features like mesh networking support to modern 802.11ac wireless firmware components (I should also point out that we don't even have source code for any 802.11ac wifi firmware... and the people trying to get it are being hindered by these FCC rule changes.. I know. I'm one of these people.). The reason we have great support for Atheros 802.11n chipsets is explicitly because the community has had access to critical bits of code. This code has now been moved to the wireless firmware which is *LOCKED DOWN*.
So no this is NOT good news. It's actually creating a security threat because we will be prevented by gaining access to the complete set of source code running on our devices.