TP-Link agrees to allow third-party firmware in FCC settlement

Err, it pretty specifically requires that open source firmware be allowed - it just can't be allowed to modify the radio settings to move them outside of the region locked limits. The WHOLE POINT of this action is the FCC moving to prevent a company from blocking third party firmware. The FCC said they had to find a way to allow third party firmware while meeting one condition.

So, no, you can't make third party firmware do things which are illegal - but you are allowed to have third part firmware. And in fact companies (or at least this one) can't legally prevent you.

I don't think they are restricting the radio, as such. You can still put whatever bits on the airwaves you want.

All they are restricting is the power you can transmit at. That could literally just be a burned-in dB value or a set resistance on a circuit. There's no need to configure that as, by law, tweaking it beyond normal parameters is illegal anyway. It's like saying that a TV card isn't "open-source" because you can't tune it down to receive at 0.5MHz.

There's also nothing saying the radio power can't be adjusted, just that the MAXIMUM must be respected. As I say, if they do this by putting a certain resistance into a circuit, that still lets open-source firmware dial the transmission down, like managed Wifi systems do, to increase global throughput.

Open-source is not about "you need to be able to do control every possible theoretical function of the system". It's about "if proprietary firmware can do it, so should we be able to". And the maximum transmission level is not something that proprietary or open-source firmware should be able to exceed, because of the laws around this.

Historically, the maximum transmission level wasn't even implemented. Now it will be implemented in hardware or at least outside the scope of ANY firmware. That means proprietary and open-source firmware are back on a level peg again.

Sure, it means you can't exceed the maximum transmission level, but control of the device for any legal purpose isn't hindered at all.

Sometimes OS-evangelism goes too far. Even if you were to make an OS router yourself, you wouldn't be able to get it FCC certified without literally removing the capability for users to tweak the maximum transmission power level. So restricting that isn't about removing your software freedoms as much as making devices that are legal to use, buy and sell.

...and a good thing handling RADAR is implemented in software -- two of the devices I have running right now keep reporting RADAR pulses while running in the 2.4GHz band -- which is nonsensical.

The main thing the FCC is concerned about is out-of-band emissions. Within the legal bands, very few devices on the market come anywhere near close to the in-band power limits .

The thing is, unless the wifi chipset has some sort of onboard flash/efuse/etc holding parameters (and reads them without any software assistance) then the software can always muck with things. (I should know, I've written code to do said mucking with many times now)

To handle the radar detection while allowing third-party firmware is going to require a solution similar to what Ignition Design Labs is doing with radar detection and channel management in a separate dedicated CPU in their Portal router. Unfortunately, they don't seem to support third-party firmware, at least at this point. But, that dedicated CPU would never be changeable. The extra CPU is also unlikely to make it particularly inexpensive.

One reason for having things configurable via software is allowing users who travel taking their equipment with them not to have their equipment operate in violation of local regulations in the countries they visit. Because of this, even if some specific limits need to get hardwired in devices sold in the US, I believe it should remain possible to further reduce via software the capabilities of the device, to assure that it can be safely employed abroad. So the rules are not incompatible with CRDA. For instance, already "Linux allows changing regulatory domains in compliance with regulatory restrictions world wide, including the US FCC. In order to achieve this devices always respect their programmed regulatory domain and *a country code selection will only enhance regulatory restrictions*"

Indeed, this can result in devices that have a reduced functionality when used abroad (namely, they may end up operating well below what the local rules allow).

That is exactly what CRDA does, yes. By default the kernel restricts wifi devices to "worldwide-safe" settings; with the CRDA userspace software installed it only allows legal settings for the configured country (or the intersection of those and what's hardcoded in the hardware/firmware). This is all cryptographically signed and verified by the kernel and used by every in-tree wifi driver, so it's painfully obvious if someone's tampered with Linux to enable running their hardware out of spec.

In this case, that someone is TP-Link... they had all these free safety belts and chose to ignore them and write NIH crapware instead. The $200k seems justified.

"That's one that the FCC get dragged in to, not one that they started ..."

Actually, according to last Battlemesh talk on the subject, the radio lockdown was started by an European Commission advisory committee (based on a study on wifi 5Ghz and radars interference). There is one american expert speaker who said the FCC did not not had enough man power to make scientific studies on this issue.

As someone who helped put together one of the biggest filings with the FCC on this matter, with 260+ other people (including our grumpy editor!)

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_prac...

(in addition to 1300? 1700? filings from other orgs)

And later met in person with many of the top people there:

https://www.fcc.gov/ecfs/filing/60001306685

I am inclined to put this result in the "win" column, provisionally.

June 2 came and went, tp-link's router firmware returned to field upgradable, and other manufacturers did nothing to make flashing other firmwares any harder than it already was. Hopefully, our arguments buttressed the legal case ongoing at the time against tplink (I knew there was one, but not against whom, or over what, I hope to get more details).

This does not mean the war is won, however. Certainly binary blob firmware that completely controls the radio remains a problem - but progress is being made with the very thin firmware in the 802.11ac mt76 chipset, I am not aware of 5ghz ath9k chips requiring blobs, and other binary only firmwares are improving to support APIs that fq_codel on wifi needs.

http://blog.cerowrt.org/post/fq_codel_on_ath10k/

(Recently a few new *major* chipsets had wifi drivers submitted to the linux kernel, but I haven't looked at what, exactly the firmware controls. The state of most wifi drivers and firmware is thoroughly depressing - and a very smart and fast co-processor is seemingly needed to run at very high rates)

Five things I learned from this exercise:

1) If a legalistic solution can be vague, it will be. It then can be spun many ways for many audiences. Read Ed Bernays.

Still, sometimes what is said publicly, continues to matter, and the FCC has said some very nice things.

2) The FCC was not the enemy, but a harried organization attempting to fulfill its mandates. As minimally outlined, their problem was the FAA complaining about wifi interference with weather radars. The first solution was overbroad. They have a much better understanding of the roles of open source, third party firmware now - after the keruffle - of the usefulness of user control, better security, and more frequent updates.

The FCC has WAY bigger problems than linux wifi. The number of wireless capable devices requiring certification and testing is skyrocketing, among other things.

https://twitter.com/FCC is a good source for the FCC's other concerns.

3) If you really want attention in D.C., it is a good idea to make a good argument, with a lot of well known people, file it somewhere inside the agency's process, and then issue (buy) a press release, and make the biggest stink you can.

As it turned out many of the recommendations we made above cannot be implemented inside the FCC's mandates, but the FTCs.

4) Chipmakers can now no longer hide behind an argument that the FCC will not let them open up their firmware.

5) The best "proof of the pudding" I can think of would be to push through a new product with much more or entirely open wifi firmware through the FCC processes, using the CRDA library to enforce the rules. Lining up a vendor willing to try that has so far not happened, although I expected a few mt76 chipsets to enter the US by now, I have not been actively watching their RSS feed for progress.

All in all, honestly, I do think we moved the dial a few notches in the right direction, and I'm going to sleep pretty well tonight.