<div dir="ltr">Hello,<div><br></div><div>I am considering trying to pull together a submission to the FCC about this rule if anyone is willing to help out.  We need to start by enumerating the problems we see with it.  Here is a starting list:</div><div><br></div><div>1. Prevents reflashing equipment for use in other jurisdictions.</div><div>2. Prevents innovation and repurposing equipment, such as to respond to humanitarian situations, including for projects such as the Serval Project and others who are being funded by USAID or other US government entities to accomplish exactly this goal.</div><div>3. Prevents update of firmware on equipment to close security vulnerabilities.</div><div>4. Increases cost burden for manufacturers, resulting in higher costs to consumers.</div><div>5. Will be of questionable effectiveness (but we need to explain why)</div><div><br></div><div>Any other thoughts? Anyone willing to help craft a submission to the FCC on this?</div><div><br></div><div>Paul.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 4, 2015 at 6:50 AM, Paul Fuxjaeger <span dir="ltr"><<a href="mailto:fuxjaeger@ftw.at" target="_blank">fuxjaeger@ftw.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On 03/09/2015, Amelia Andersdotter <<a href="mailto:teirdes@gmail.com">teirdes@gmail.com</a>> wrote:<br>
>> Dear all,<br>
>><br>
>> I fail to see how the EU directive hinders anyone from putting in<br>
>> their own software on a radio device.<br>
>><br>
>> Could someone update me? It's being implemented in Sweden with a<br>
>> deadline for comments in October.<br>
>><br>
<br>
Article 3, point (i) of [1]:<br>
<br>
"radio equipment supports certain features in order to ENSURE that<br>
software can only be loaded into the radio equipment where the<br>
compliance of the combination of the radio equipment and software has<br>
been demonstrated."<br>
<br>
My current interpretation is that for all devices using SoftMAC radio<br>
chipsets this necessitates a lockdown of the complete software stack.<br>
Because on such devices the code that sets the regulatory rules is<br>
executed in the same context as everything else.<br>
<br>
AFAIK, the majority of APs currently on the market is based on such an<br>
architecture. Manufacturers have an alternative: switch back to more<br>
complex (e.g. FullMAC) architectures that allow to lock down the radio<br>
subsystem separately [2].<br>
<br>
To me this FCC document [3] indicates complete lockdown:<br>
<br>
"ENSURE that only properly authenticated software is loaded and<br>
operating the device [...] manufacturers may consider applying existing<br>
industry standards for strong security and authentication. It is<br>
suggested that manufacturers follow existing security standards and<br>
definitions: X.800, RFC 2828, and IEEE 802.11i."<br>
<br>
-paul<br>
<br>
<br>
<br>
<br>
[1]<br>
<a href="http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32014L0053&from=EN" rel="noreferrer" target="_blank">http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32014L0053&from=EN</a><br>
<br>
[2] Enforcement of local regulatory differences is still an issue as the<br>
radio subsystem cannot reliably detect where it is located without the<br>
help of the host system.<br>
<br>
[3] <a href="http://www.heise.de/downloads/18/1/5/7/9/4/3/6/GetAttachment.pdf" rel="noreferrer" target="_blank">http://www.heise.de/downloads/18/1/5/7/9/4/3/6/GetAttachment.pdf</a><br>
<br>
_______________________________________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" rel="noreferrer" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
</blockquote></div><br></div>