[Battlemesh] What hardware still works?

[Simon Wunderlich]

On Tuesday 01 March 2016 10:51:26 Josh King wrote:
> 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.

The software security requirements have been implemented long before, actually 
2014, and are still effective (details have been updated several times)

https://apps.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm?id=39498&switch=P

This page says:

"All devices partially or completely approved under the old rules cannot be 
marketed starting June 2, 2016 unless they meet the requirements of the new 
rules in all the bands of operation."

and

"New devices will be permitted to be approved under the old rules for until 
June 1, 2015. "

If a vendor creates an updated HW revision, they have to (re)certify under the 
new rules and therefore have to implement the "software security" in one way 
or another. That has nothing to do with anticipation, IMHO. 

If I misunderstood, I'd be glad to be corrected. :)

Thanks,
     Simon
-------------- 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/20160301/f15aa24d/attachment-0001.sig>