Slashdot Mirror
EU's Plan To Ban Sale of User-Moddable RF Devices Draws Widespread Condemnation (theregister.co.uk)
Reader simpz writes: The Register is reporting that the EU is looking to block users from tinkering the firmware/software of their RF devices. This seems to have been very under reported, with a fairly short consultation period that has now expired. It could force manufacturers to lock down phones and routers etc to stop you from installing the likes of Lineage OS or OpenWRT. The way this is written it could stop devices like laptops or Raspberry Pi's having their software changed. From the report: The controversy centres on Article 3(3)(i) of the EU Radio Equipment Directive, which was passed into law back in 2014. However, an EU working group is now about to define precisely which devices will be subject to the directive -- and academics, researchers, individual "makers" and software companies are worried that their activities and business models will be outlawed. Article 3(3)(i) states that RF gear sold in the EU must support "certain features in order to ensure that software can only be loaded into the radio equipment where the compliance of the combination of the radio equipment and software has been demonstrated." If the law is implemented in its most potentially harmful form, no third-party firmware could be installed onto something like a home router, for example.
I surely hope I'm not being too paranoid but I'm guessing that the damage won't be limited to the EU countries. Anything that's sold in the EU will probably be the same version that's sold elsewhere just to avoid the hassle and potential legal problems with making two different versions and, say, one of the naughty R-Pis getting into an EU country by mistake. So, potentially, no more Raspberry Pis for anyone (well not any that are all that useful for DiYers), locked down laptops that can't run anything but the OS that came with it for fear of violating the new EU law, the list goes on. Another step down the road to banning user programmable devices and allowing only "appliances" to be sold to consumers.
CUR ALLOC 20195.....5804M
Yeah, it's better to live in the US where...they've had similar laws for years now...shit...
"When information is power, privacy is freedom" - Jah-Wren Ryel
This isn't the big bad government trying to take away your freedoms. I fully support the FCC on this (and I'm pretty close to Libertarian so that means something coming from me).
The issue is weather radar. Shortly after the FCC opened up the 5 GHz band for unlicensed use, terminal doppler weather radar was invented in response to several airliner crashes due to adverse weather conditions. Unfortunately, it relies on frequencies smack dab in the middle of the open 5 GHz band. So the FCC took the unusual step of revising their rules which opened up those frequencies
The intermediate 5 GHz channels were reclassified as DFS - dynamic frequency selection. Devices are allowed to use those frequencies, but they have to monitor for TDWR. If they detected weather radar in use, they had to switch to a different channel. A few devices actually do this and check to see if weather radar is in use. Most manufacturers just took the easy way out and blocked out channels 50-144 entirely in the firmware. That's why many 5 GHz devices only support channels 36-48 and 149-165. (This can cause the mysterious situation you might have encountered, where some devices can see your 5 GHz network while others can't. Your router supports DFS and has picked a channel between 50-144. Devices which support DFS can see the router. Devices which have blocked off channels 50-144 cannot.)
Early open source router firmwares completely ignored DFS. They would spam over the DFS frequencies, interfering with weather radar at airports if someone nearby happened to load the firmware onto their router. DD-WRT added support for DFS (it's the "weather radar" checkbox in the 5 GHz wireless settings, although it really should be checked by default).. If you install third party firmware and use the 5 GHz band, do the responsible thing and enable this functionality if you're going to enable channels 50-144. Unfortunately, some idiots didn't do this, degrading the effectiveness of hundreds of millions of dollars invested into TDWR equipment. It was enough of a concern that the FCC began investigating the need to regulate or ban third party firmware. That's what this is all about. The government doesn't hate you running third party firmware on your router, they're just trying to protect people flying in airplanes from needlessly being killed.
This is why we can't have nice things - a few idiots ruin it for everyone else. I had lots of fun with lawn darts as a kid, but we always treated the target area as if it were a shooting range. Here's an example of what happens to TDWR when an idiot blasts their router in the TDWR frequencies. The unauthorized broadcast shows up as a wedge-shaped area spanning a few degrees and extending to the edge of the radar image, completely obscuring any weather in the wedge. Multiply that by a few dozen open source routers near the airport and it becomes a major impediment.
The cleaner solution would've been for the FCC to simply close the 5 GHz band and reserve it entirely for TDWR. But that would've made billions of dollars of wireless equipment obsolete. So the FCC tried their best to find a compromise between the needs of people who already owned 5 GHz wireless equipment, and the flying public. It's the open source firmware authors who were (initially) acting like jerks here, not the FCC.
The thing about DFS that REALLY sucks is the stupid way it ends up getting implemented... when it's time to do the DFS check, the access point just goes dark without warning for a minute, leaving everything that was connected without connectivity in the meantime.
Why can't 802.11 have an optional extension that allows the AP to tell connected clients, "hey, I'm about to go dark for a minute to do a required DFS check... in the meantime, if you really NEED continuous connectivity, temporarily switch over to 2.4GHz channel {n} at SSID="xxx" using the same credentials you used to connect to me on channel 122, and I'll let you know when it's safe to switch back"?
I mean, even the cheapest piece of shit access point that's capable of using a DFS-protected channel is almost guaranteed to have 2.4GHz 802.11n, so why not provide a way to automatically (and rapidly) fail over to it during the DFS check? Even if 2.4GHz wifi sucks, connectivity that temporarily SUCKS for a minute is still a net improvement over connectivity that DOESN'T EXIST AT ALL for a minute.
Likewise, if 802.11 had a way to communicate that upcoming DFS check to wifi-connected clients, they could try to do a better job of anticipating it. For example, if Netflix has been sustaining 6mbps buffered ahead by 5 seconds, it could attempt to crank things up to pre-buffer enough content to get you through that dry minute without glitches if it knew the disruption was coming and had time to prepare.
DFS is important, but the way it was IMPLEMENTED needlessly sucks more than it HAS to.