> So, in urban areas of the US at least, it really is just a matter of software.
and, if you're really zealous about it, the firmware. there was a high-priority FSF project a while back for free wireless router firmware. that listing mentioned something called "orangemesh," which now appears to be on hold. what are some of the other options out there on the software side?
However, I'd argue that the use of open source firmware in this case is a means to an end, since proprietary firmware generally sucks. But since this is an article about how to have a quality Internet connection, rather than how to get started in router OS development, it might be more than suitable for many of his readers.
> It's not like there are going to be millions of different people causing interference
Why not? When someone has trouble with wifi in their apartment because there are a zillion other wifi networks in their neighborhood, and they Google for "boost my wifi signal" or similar they are going to get several articles that suggest installing open source firmware so they can tweak performance parameters that they cannot with the stock firmware, including tweaking transmit power.
> Enjoy your 12 year old ThinkPad with external Wifi dongle!
I'm curious why that Wifi dongle you casually refer to runs firmware that is MIT-licensed and available on Github.
According to Wikipedia, it didn't require any reverse-engineering. So what was the business use-case for FOSS firmware here? And in the category of Wifi chips, why hasn't there been another such use case for modern hardware?
> There aren't enough end users who know how to modify the firmware code themselves to matter, even if you make that "easy."
This is just a silly statement. Go to an apartment complex sometime and browse the available WiFi networks. You'll see a huge number of them because everyone has the output power on their router set to the max value. There's plenty of places the 2.4GHz band is simply unusable because the noise floor is so high from a hundred base stations blasting out at full power.
If WifiBoost.exe could in tease that output power enough people would do it that WiFi or Bluetooth in some places would be completely unusable.
Modern radio basebands are largely software defined. The modulation/keying, power output, and transmitted bands are all defined in software. In order to sell that silicon as a Part 15 compliant device to end users the firmware needs to be locked. It's the digital equivalent of a fixed function radio. A manufacturer of a fixed function radio couldn't get a Part 15 license if it had a potentiometer on the back allowing you to dial up the output power, even if that potentiometer was locked under the case most people wouldn't open.
With an SDR the hardware plus software is considered the "device" for licensing purposes. If it supported unlocked or modifiable firmware it couldn't be easily/at all sold as a Part 15 device. It would be a different class of device and would require the end user to have a license to operate it.
> According to them, there are unfortunately no baseband modems on the market that can legally have their firmware distributed as free software.
What is the legal restriction here? (It sounds like you're referring to some restriction beyond simple copyright protection on some of their components - are there FCC regulations regarding the firmware?)
EDIT: Ah, of course, the FCC needs to certify devices before they can actually be used.
> Doesn't that seem to make this point moot? If they're not responsible for what users do hacking around, then there's not really any need to keep firmware closed source or locked down.
To sell the device the manufacturer has to make sure the device follows regulations and normal usage will follow end user regulations. The easier they make it for regulation-violating user modifications the more likely the product is to not get a license for sale of the device.
In something where the radio baseband is a physical circuit layout conformance is easy. Without modifying surface mount parts that circuit will always conform to its license.
For complicated basebands (WiFi etc) with software control having a fixed/closed firmware is the easiest way to get a license and not get it pulled after the fact.
The WRT54G is a fluke because it ended up using Linux/GPL code in the firmware. It was then obliged to release the source because of that. You can buy devices that allow firmware development and modification but not at retail and you can't offer them for sale without an FCC license covering them.
> You'll see a huge number of them because everyone has the output power on their router set to the max value.
None of these people are firmware developers. They used the setting that existed from the factory in their router or in something they downloaded from the internet, and in the vast majority of cases it wasn't even the second one.
> If WifiBoost.exe could in tease that output power enough people would do it that WiFi or Bluetooth in some places would be completely unusable.
Then WifiBoost.exe would be illegal and the developers would be subject to penalties.
It would also be ineffective, because you can't remove interference by increasing power. The "highest allowable power" setting is often the default because it gives the best range, and the purpose of allowing it to be set at all is so that the user can reduce interference at the expense of range by lowering the power level so fewer devices are overlapping.
It's hard to get people to avoid doing illegal things when breaking the law benefits them. It's not that hard when breaking the law is pointless and maladaptive regardless of whether or not they get caught.
It's notable that there have existed routers with completely open firmware and there is no epidemic of ordinary users installing shady firmware on them to violate regulatory limits. There is likewise full software defined radio hardware on the market, for which a license is required to transmit but not to buy it. Applying a different standard to consumer hardware which is available to exactly the same set of people makes no sense.
> With an SDR the hardware plus software is considered the "device" for licensing purposes. If it supported unlocked or modifiable firmware it couldn't be easily/at all sold as a Part 15 device. It would be a different class of device and would require the end user to have a license to operate it.
I'm not arguing about what the law currently is but rather about what it ought to be.
But I also think your analogy is flawed. If the manufacturer sells a device with a potentiometer whose maximum setting was within the regulatory range, or with a fixed power output, and then the user modifies the device to install one that can increase the power output, that should be on the user. So why is it different if the user modifies the device to install firmware that increases the power output?
You're essentially arguing not that the device can't include a potentiometer, but that the case has to be sealed so the user can't install one.
Which in turn prevents the user or any other third party from repairing the device or supporting it past when the vendor stops caring about it, inducing widespread security vulnerabilities as users commonly continue to use operational devices even after the hardware vendor stops issuing updates.
> why is it an issue if the signal processing is done in firmware? Isn't the idea of firmware that it's factory set and read-only?
There are multiple levels to this, and it varies with chipsets. Take for example, a very basic crappy chipset like the TI WL127x transceiver series. This chipset would be the lowest level. It is what implements the lowest level of radio signal processing above the hardware. That chipset has its own firmware. That's very small. Typically, less than 128kbytes. But it is rarely factory set or read-only. Rather, it is a binary blob that is loaded on to that chipset by a linux kernel wifi driver. The driver is typically not a binary but source code that is part of the linux kernel. That blob, driver, kernel, and rest of the system are then part of a "firmware image" that is flashed on to your router/phone/embedded device. It is reasonably common to want to modify and customize that firmware image. Hence forums like xda, cyanogen, etc. The binary blob is the only part that isn't very common to modify, but even then, given the high rate of implementation defects in that blob, one wishes source were available for that as well so that it could be better controlled.
It's on fcc.gov, so it's probably legit. It dates back to March, so it's conceivable that it's been modified or superseded since then; I haven't been able to find anything to indicate so, but I'd be happy to be wrong.
Basically, there seems to be a lot of confusion stemming from blogs that heard about the document that I posted, but only linked to the document that thejosh posted. I found this doc via the CNXSoft post that appeared on HN yesterday [1], which mentioned the "protected from flashing" line and linked to Etherpad notes from a presentation, which linked to the U-NII Device Security v01r02 document that I posted above. It's kind of a ridiculous chain, so I can see why people were confused. You're right that none of the documents directly linked in this thread talk about blocking custom firmware; when people are talking about that, they're thinking of the U-NII Device Security document, not the "Equipment Authorization and Electronic Labeling for Wireless Devices" proposed rule.
> Is this a case of some documents describing preliminary consultations and others a final situation that differed from what was contemplated originally?
Possibly. They may also be describing different aspects of the FCC's evolving wireless policy. I haven't followed the rabbit hole deeply enough to determine for sure whether the FCC is still currently on track to block custom firmware, but it appears that they were as recently as March.
> For that matter, is it actually the case that some routers don't fully isolate the radio control software as intended by the regulations, in which case installing custom firmware like DD-WRT or OpenWRT really would be a risk
Oh, yes, certainly. Most of these firmwares are designed to be useful for users all over the world; IIRC, the one I use (Tomato) lets you select your region from a pull-down, and then enables the channels appropriate to your claimed region. (You can achieve the same thing by downloading the manufacturer's firmware intended for a different region; custom firmware is not required.)
I think this was well-meant on their part, but I agree that it is a problem, and it makes sense for new routers to block access to block access to unauthorized channels on a level that custom firmware can't touch. I just think that blocking custom firmware entirely is throwing the baby out with the bathwater.
Using open-source firmware won't get you much in the way of performance benefits if it's not using recent Linux kernels and well-maintained in-tree drivers.
And it was only recently that any routers started including CPUs that are powerful enough for high-speed packet processing. Prior to 802.11ac, basically everything was based off '90s-era single-core MIPS and the only hope of 100+Mbps throughput was to use hardware offloads that severely curtail the kinds of packet processing you can accomplish (and usually isn't supported by any open-source driver). Now we've got 1+GHz multi-core ARM processors in wireless router SoCs, but no mature drivers for them.
>>The GSM/LTE/whatever radio runs very closed source firmware.
>This seems like a problem that could be fixed.
The problem is that it's illegal to reflash the firmware, because the Radio Frequency Giveaway Committee* is scared that people would abuse that to send on frequencies that they haven't permitted.
> I don't see anywhere in the regs where banning alt. firmware is a goal of the regs.
It's not an explicit goal. But the article argues (and I tend to agree) that the practical result will be manufacturers locking down their devices to prevent alt firmware from being loaded, since that will be the easiest and cheapest way for them to demonstrate compliance.
> I am hopeful that this will change the way that WiFi manufacturers lock down their radio firmware - and that is exactly what the FCC wants.
Are you saying the manufacturers will come up with some way of locking down their radio firmware that still permits something like OpenWRT to be installed on a router (or Linux on a laptop, for that matter)? Why would they bother when they could just lock the device down completely?
and, if you're really zealous about it, the firmware. there was a high-priority FSF project a while back for free wireless router firmware. that listing mentioned something called "orangemesh," which now appears to be on hold. what are some of the other options out there on the software side?
reply