[Battlemesh] IEEE magazine on FCC lockdown

Simon Wunderlich sw at simonwunderlich.de
Wed Apr 20 14:29:36 CEST 2016


On Wednesday 20 April 2016 11:18:03 Sven Eckelmann wrote:
> On Wednesday 20 April 2016 09:42:00 leonardo wrote:
> > via bufferbloat-FCC-discuss...
> > 
> > It seems that the author of this paper in IEEE consumer electronic
> > thinks that Simon Wunderlich did not get things right about FCC
> > intentions.
> > 
> > Really, this is what he says...
> > 
> > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7450774&tag=1
> 
> No, he isn't. The author uses Simon's statements about the possible effect
> (which unfortunately is already visible because device vendors started to
> lock down the devices - not the only wifi chip firmware) to explain what he
> thinks is the actual intention of the FCC. I completely disagree with his
> use of the statement "But paranoia still exists that the FCC is being
> empowered by evil corporations ..." because it pushes the movement against
> the new FCC requirements in the fearmongering corner. Most likely not his
> own intent but this is how it reads for "affected" people.
> 
> There is still a difference between the intention of the FCC and the
> effects. And we should also consider that "evil" is not just an attribute
> which you assign to yourself like in D&D. The branding "evil" is assigned
> by other people based on their view about a topic or an action. If we
> really want to say that this move by the FCC is "evil" (I actually don't
> want it - but just use the words of this author for now) then it is just
> because the effects for us are bad. Vendors already shut down their
> hardware "completely" and we first have to break their "security" to make
> use of the hardware again.
> 
> The author doesn't point out the intent of this session in last years
> battlemesh when he used it to describe the opposition of the new
> requirement. It was to done (please correct me Simon) to discuss this
> problem and to find solutions which would make the operators of community
> networks, the hardware vendors and FCC happy. I would say that this didn't
> succeeded. At least the information about the new FCC requirements were
> spread and let to some projects [1,2,3] that discussed this problem further
> and called for more actions.
> 
> But maybe he just didn't write about this extensively about the session to
> keep his article short. This would also explain why he didn't write about
> the possible (non-"evil") reasons for this new FCC requirement discussed in
> this session.
> 
> And his statement "FCC is calling out in FCC 14-30 is the “firmware” 
that is
> located inside the radio chip or application-specific integrated circuit"
> is rather controversial because they used the term "DD-WRT" (which is a
> device firmware and not a wifi chip firmware) earlier in their
> questionnaire. It was most likely not their intent but they made it really
> hard not to interpret it this way. And right now, WiFi firmware chip
> versions can still be replaced and mostly only hindered the lawful use of
> the devices (e.g. in mesh networks with ath10k). I don't know (but could
> easily be wrong) of any widely deployed wifi chip used in community
> networks which uses some kind of cryptographic mechanism which would stop
> anyone from installing a hacked wifi chip firmware (and wifi chip firmware
> only). But even when it doesn't exist now - maybe this will come and thus
> confirm his standpoint.
> 
> But I doubt that he doesn't know about the background because he already
> links the Wired article [4] about the FCC lockdown. It would also nice when
> he would also quoted the next sentence from the Wired article: "It’s just
> that breaking those locks opens tinkerers up to prosecution under the
> Digital Millennium Copyright Act—a distinction comes with up to 5 years in
> prison and $500,000 fine.". Not that I would know a lot about the legal
> background but at least this statement sounds important in context of his
> earlier quote which trivialized the breaking of digital locks.
> 
> We will not start to being happy and praise the new FCC requirements but I
> think he has the rights to point out the intentions we may (or may not) have
> missed. But at least for me it was nothing new which wasn't written already
> at many other articles.
> 
> Kind regards,
> 	Sven
> 
> [1] http://huchra.bufferbloat.net/~d/fcc_saner_software_practices.pdf
> [2] http://savewifi.org/
> [3] https://fsfe.org/activities/radiodirective/
>     (this is about the EU counterpart)
> [4] http://www.wired.com/2015/09/hey-fcc-dont-lock-wi-fi-routers/

Thanks for forwarding the article!

I've read the article, but I think there are a couple of things which are at 
least not very accurate:

 * The Wi-Fi community networks I know are not some small networks in 
underdeveloped countries. For example, in Europe we have guifi.net with 30k+ 
APs, Freifunk Germany with almost 30k APs (in total over various cities), city 
networks like AWMN with 6k nodes (last time I checked, couple of years), and 
many more. They all build on more or less modified/reflashed WiFi APs.

 * Add commerical hotspot providers to that, I would estimate also at least 
~100k APs within Europe, which run on firmware-reflashed Hardware.

 * Its a true statement that the FCC only requires to "lock" the radio 
parameters. However this is not what the industry actually implemented. TP-
Link, one of the biggest and most popular router vendors locked firmware on 
their whole Wi-Fi product line, for all APs sold from Mid 2016. Including 2.4 
GHz only routers. This affects all the users mentioned above directly.

 * The article mentions that the radio parameters could be locked in the radio 
chip firmware. For the popular chips based on Qualcomm/Atheros Chips which 
practically all communities used (due to lack to alternatives), this is just 
WRONG. Qualcomms 802.11n chips (ath9k) don't have any radio firmware at all. 
The 802.11ac chips (ath10k) do have a radio chip firmware, but it wasn't 
designed to lock the radio parameters in the firmware. And that firmware is 
also not cryptographically signed, and is stored and uploaded from the router 
firmware - where it can also be replaced. Therefore the only technical 
solution for Wi-Fi AP vendors is to lock down the whole router firmware. I 
hoped to see alternatives, but didn't find any so far. And using modules and 
buying them separately is just a "hack" to work around the FCC certification 
process, which will probably be closed down soon too.

 * It is not about despotic governments or evil companies at all. I understand 
they all consist of humans, and most just want the best for all of us. I 
understand that wrongly using frequencies of weather radars next to airports 
is a serious problem for safety. But I'd also argue that the measures are 
completely out of proportion. You wouldn't forbid knives for everyone because 
someone stabbed someone. And the "just lock the radio" argument is not working 
technically, unfortunately, as explained above. I think the FCC had good 
intentions, but didn't look into technical details and thus we have this huge 
problem now. To go back to stabbing - in the real world, you would just lock 
up/fine the person who stabbed. Why not enforce (high) fines for people who 
actually USE bad radio parameters?

 * I don't understand the white noise argument. Turning an Wi-Fi AP into a 
white noise generator is new to me, and I would doubt that this is even 
possible. The only problem which was/is present, is that people used Wi-Fi in 
5 GHz without DFS, which requires moving to another frequency if a primary 
user (radar) on the current frequency is detected. People just used firmwares 
which didn't implement that, stayed on the frequency, and therefore the 
weather radar readings where garbage. Look at the funny triangle clouds around 
Berlin [1]. But DFS/radar is really the only issue here - a correctly 
implemented WiFi access point is not supposed and will NOT move for a medical 
device in 5 GHz (unless its a radar device). If the medical device has a 
problem with that, its the problem of that medical device and its vendor.

 * One last comment on the world-wide effects of the FCC rules: Thanks to 
that, we now have locked routers in Europe, South America and everywhere else. 
Vendors just don't bother (at least most of them) to open their stuff 
elsewhere. We also have similar rulings to come in Europe thanks to the 
spearheading in the US. And I think also the "unscrupulous radio manufactures 
in Asia" is a funny argument, because they use the Chips and SDKs as provided 
from US companies, mostly based in California. It's a little too easy to move 
the blame like that.

Cheers,
     Simon

[1] http://www.heise.de/open/artikel/Kernel-Log-Was-3-9-bringt-3-Treiber-Netzwerk-1841580.html?view=zoom;zoom=3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160420/ecd7bbd9/attachment-0001.sig>


More information about the Battlemesh mailing list