<div dir="ltr">I wonder if it has more to do with inexpensive radio electronics using inexpensive software defined radios that out of the box don't prevent typical end users from staying compliant with part 15 device regulations. <br>To me it is similar to secure boot requirements made by a prominent north american software company especially when it involves arm based devices like tablets and smart phones and the end users ability to disable it. It seems a lot heavy handed in my opinion.<br><br>For users of open source router firmware like ddwrt and others, the way I read it is you may not be able to reflash a router/access point with 3rd party/opensource firmware. It sounds like it could also effect devices with WiFi radios such smart phones and tablets, I am not sure if you could reflash an android device with a version of android other than what the manufacturer puts on it. <br><br>For amateur radio operators, it could prevent them from reflashing wireless equipment with open source firmware to operate the devices as amateur radio equipment (part 97) which follows different regulations than standard WiFi equipment (part 15 devices) . <h3 style="text-align:left"><span style="color:rgb(0,0,0);font-family:'Times New Roman';font-weight:normal">The following is a good comparison of the frequencies that over lap. <br>Amateur Radio Allocations and Overlapping Part 15 Bands - An Overview </span><span style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:small;font-weight:normal">And a</span><span style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:small;font-weight:normal"> </span><span style="font-size:small;font-weight:normal"><font color="#000000" face="Times New Roman">Part 97 versus Part 15 and Permissible Power Comparison<br></font></span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-weight:normal"><a href="http://www.qsl.net/kb9mwr/projects/wireless/allocations.html">http://www.qsl.net/kb9mwr/projects/wireless/allocations.html</a> </span></h3><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-weight:normal">-Ed </span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 5:06 PM, Rick Hornsby <span dir="ltr"><<a href="mailto:richardjhornsby@gmail.com" target="_blank">richardjhornsby@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Aug 26, 2015, at 15:32, Ed Liddle <<a href="mailto:ed@someplaceinohio.net">ed@someplaceinohio.net</a>> wrote:<br>
><br>
> The FCC is wanting to lock down wifi and phone devices so changes can not be made to them. This will have a big impact on open source software for phones, tablets and wireless routers such as CyanogenMod, DDWRT and an even bigger impact on AREDEN <a href="http://www.aredn.org/" rel="noreferrer" target="_blank">http://www.aredn.org/</a> and Broadband Hamnet mesh firmware <a href="http://www.broadband-hamnet.org/" rel="noreferrer" target="_blank">http://www.broadband-hamnet.org/</a> which use part 15 WiFi devices and configure them to operate as amateur radio devices.<br>
><br>
> There is a thread about it with some other links on the AREDN forum with some links here. <a href="http://www.aredn.org/content/fcc-rules-change-will-lock-out-your-software-new-equipment" rel="noreferrer" target="_blank">http://www.aredn.org/content/fcc-rules-change-will-lock-out-your-software-new-equipment</a><br>
<br>
</span>I'm not 100% sure I'm following, but from reading that thread and a couple of other things, the FCC seems to be looking to impose new rules for the purpose of "preventing users from using illegal channels on the 2.4 GHz band, using too high transmission power, using DFS channels in 5.3 – 5.7GHz band without having DFS functionality, and avoiding interfering with (airport) terminal-area doppler weather radars."[1]<br>
<br>
The FCC's proposed action "DEVICES CANNOT BE MODIFIED!" seems a bit heavy-handed. As an aviation geek (and former pilot), I have far more concerns about morons with laser pointers and clueless idiots with their stupid toy airplanes ("drones") flying around in controlled airspace. Someone blasting a wifi signal and interfering with radar cannot be that hard to triangulate and track down with the right gear. In a hardware-based radio, with a small amount of knowledge (or a YouTube video), a trip to RadioShack, and a soldering iron, I could accomplish the same thing the FCC seems to be attempting to counter.<br>
<br>
I follow aviation fairly closely - and I'm not aware of any stories involving radar interference from someone's cranked up wifi. Weather radar is extremely important to aviators, the flying public, and weather forecasters trying to tell people a tornado is coming - don't get me wrong. I definitely don't want someone interfering with it. Yet, I'm hesitant* to endorse any more draconian DMCA/DRM complete lock-out type approaches. Is the FCC trying to solve a real issue, or just creating new rules?<br>
<br>
-rick<br>
<br>
[1] <a href="http://www.cnx-software.com/2015/08/07/openwrt-vs-fcc-forced-firmware-lockdown-presentation-video-and-slides/#ixzz3jxJeEu8V" rel="noreferrer" target="_blank">http://www.cnx-software.com/2015/08/07/openwrt-vs-fcc-forced-firmware-lockdown-presentation-video-and-slides/#ixzz3jxJeEu8V</a><br>
<br>
<br>
* OT: Because of the difficulty in tracking down the culprits, I make an exception for enforced geofencing on the toy drones to keep them away from real aircraft and airports.<br>
<br>
<br>
_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" rel="noreferrer" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">-Ed Liddle<br><br>No trees were killed in the creation of this message. However, many electrons were terrible inconvenienced.<br></div>
</div>