[Battlemesh] What hardware still works?

[Josh King]

On Tue, 2016-03-01 at 15:09 +0200, Jonathan Morton wrote:
> > 
> > On 1 Mar, 2016, at 11:02, Simon Wunderlich <sw at simonwunderlich.de>
> > wrote:
> > 
> > How exactly are you going to ensure compliance with the FCC rules
> > in terms of 
> > software security? If you want to use it in the US, you have to do
> > the same 
> > FCC certification, therefore solve the same problem - hopefully in
> > a smarter 
> > way.
> > 
> > I'd be very interested in how your solution looks like, since other
> > vendors 
> > can adopt this idea into their firmwares as well to create open
> > routers.
> In PCs, the wireless radio is typically on a daughtercard which is
> certified separately - even when it’s a softmac like ath9k, and the
> retail product in question is a complete motherboard or even laptop
> with “integrated wifi”.  Obviously, you can easily change the
> software drivers on a PC, including putting in a replacement
> regulatory database (or simply changing the regulatory-domain
> setting), but somehow that doesn’t invalidate the entire PC’s
> certification.
> 
> I don’t see how a router is fundamentally different from
> that.  Indeed, I’ve seen plenty of older routers with daughtercard
> radios - the first Apple Airport Base Station was built around a
> standard, off-the-shelf PCMCIA card.  I assume any trends towards
> greater integration are due to cost-per-unit reduction efforts.
> 
> So my solution would be to use an off-the-shelf mini-PCI or mini-PCIe 
> wifi daughtercard with its own FCC certification (already done for
> us!), and plug it into a motherboard which itself has no radio
> components whatsoever (and thus for which FCC certification as a
> Part-B device is relatively straightforward).  I assume the case with
> its antennae will also need approval in combination with the
> daughtercard, but this should also not be excessively difficult.  Any
> “closed” firmware required by the daughtercard should be stored on an
> EEPROM on the card, wired up in such a way that the daughtercard is
> self-bootstrapping.
> 
> Theoretically, *no lockdown* is then required.  You would put in
> sensible security measures, such as signed software updates, for the
> sake of security, not bureaucracy. You could even provide an explicit
> interface for flashing unsigned firmware, with a captcha that
> simultaneously asserts that a human is present (security), and
> provides fair warning that using modified firmware to exceed local
> regulatory emission limits may violate local laws (bureaucracy) and
> that responsibility for this now falls on the user.
> 
>  - Jonathan Morton

I've largely been a lurker on this list with regards to this issue,
but:

It's also worth noting that the FCC hasn't _actually_ implemented this
order. After the comment period, based on our discussions with them, it
sounded like they were going back to the drawing board. So there is
nothing to be in violation of, and there's not likely to be any
rulemaking on this topic at all before the election. TP-Link and others
are doing this in anticipation of what the FCC _might_ do.

Unfortunately, in some ways this complicates what our strategy might be
around policy issues, because we essentially got what we wanted from
the FCC, in that they listened to the outcry and backed off. It's not
super clear to me what the right tactic is from here on out, and poking
the FCC further might actually be counterproductive.

-- 
Josh King
PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160301/5923d6a2/attachment-0001.pgp>