Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown

* Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown
@ 2016-03-14 14:02 dpreed
  2016-03-14 14:14 ` [Cerowrt-devel] [Make-wifi-fast] " Jonathan Morton
  2016-03-14 19:13 ` [Cerowrt-devel] " David Lang
  0 siblings, 2 replies; 7+ messages in thread
From: dpreed @ 2016-03-14 14:02 UTC (permalink / raw)
  To: David Lang; +Cc: make-wifi-fast, bufferbloat-fcc-discuss, cerowrt-devel

As a software guy who can solder SMT chips and design PCBs, and a licensed amateur radio operator, let me add a couple observations.

The FCCs concern is not to lock up all software on  routers. All they call for is that at certification time and in users hands, radio emissions are restricted  to the rules of Part 15 operation.

So one can manufacture a router that can be certified, but with the ability to operate outside the legal 2.4 GHz channel and 5 GHz channels, and power limits and that quirky radar protection rule locked in via some difficult to break lock. It needn't be a perfect lock... If it requires the ability to solder or unsolder SMT chips, or spending $1000 for parts and services per device, that could satisfy. After all, just R-SMA connectors were sufficient for antenna mod prevention to be certified.

The WiFi protocols themselves are not a worry of the FCC at all. Modifying them in software is ok. Just the physical emissions spectrum must be certified not to be exceeded.

So as a practical matter, one could even satisfy this rule with an external filter and power limiter alone, except in part of the 5 GHz band where radios must turn off if a radar is detected by a specified algorithm.

That means that the radio software itself could be tasked with a software filter in the D/A converter that is burned into the chip, and not bypassable. If the update path requires a key that is secret, that should be enough, as key based updating is fine for all radios sold for other uses that use digital modulation using DSP.

So the problem is that 802.11 chips don't split out the two functions, making one hard to update.

Router vendors should like having this feature, in the standard chipsets, actually. Why? Because it makes their own products easier to certify, the same way a secure microkernel makes security properties easier to certify, in, say, L4. And because the rules about channels and power are different in each national market. Who wants to submit all their source code to each country's regulator?

So I personally would be frustrated that I would not be able to mod any router to operate under Ham rules(part 97 allows hams to operate in much of, but not all of, the two 802.11 bands with equipment we can make modify and operate with only self-certification, and the operator following Amateur operating rules, which are different, but allow 802.11 outside the unlicensed bands also, at higher power, too). But that matters less, because I can solder and validate my transmitters.

Perhaps there is common ground to be found. Dave Taht and I made the first move on this, with Dave's DC meeting with the FCC.

But it will take working with both the FCC and the chip vendors, and the home access point vendors with a common purpose and agenda. That agenda needs to be to find the minimum lock that will satisfy the FCC, and a sufficiently cheap implementation that, along with the cost saving on design certification, it is cheaper to make a router that is otherwise open, than to make one whose certification depends on review of all the code in the router.

This is a common design pattern. The DAA for phones is now purchasable as a single module, FCC precertified, so one can make any kind of cordless phone be certifiable, merely by using that part. That part is more expensive than one I could design myself, but it saves on certification cost, because the rest of the phone or modem doesnt need certification, so one can innovate.

Hope this helps. Happy to advise, and also help get the FCC on board when there is a need to. Before that, I'd suggest convo with Atheros, Broadcom, Marvell, etc. Or even Intel, which may want it for its WiFi embedded businesses.

^ permalink raw reply	[flat|nested] 7+ messages in thread