4 ms·

As far as I remember FCC about 8 years ago didn't liked OpenWRT, and even enforced on TP Link to lock it.

SoftTalker 3y ago
IIRC the main objection was that it could be used to do something with the radio (boost power?) that caused the device to exceed FCC limits for a consumer radio? Something along those lines?
- PhilipRoman 3y ago
  For those out of the loop these documents have a good introduction to how free software interacts with radio regulations https://wireless.wiki.kernel.org/en/developers/regulatory/statement https://wireless.wiki.kernel.org/en/developers/regulatory/st... https://wireless.wiki.kernel.org/en/developers/regulatory https://wireless.wiki.kernel.org/en/developers/regulatory TLDR manufacturers and "serious" companies won't touch anything that could potentially be configured to emit signals that your local government doesn't like. So Linux has to pretend it doesn't allow to do that (even though anyone with 2 braincells can patch it)
  - dtaht 3y ago
    As these regulations change frequently, I am glad that linux makes it possible to update this database and the devices in the field. For example a portion of the 5.9ghz spectrum became available. https://www.computerworld.com/article/2993112/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html https://www.computerworld.com/article/2993112/vint-cerf-and-...
  - codedokode 3y ago
    So Linux takes government's side, not user's?
    - chupasaurus 3y ago
      I'd call it "safe defaults".
- RF_Savage 3y ago
  It was about the radio and being able to modify the radio firmware. As many modifications would void the FCC certifications of the device, due to changed parameters (more power, disabled anti-interface mitigations, out-of-band channels, etc.). This was avoided by making the radio firmware separate blobs, but there was a real danger of the whole device having to have signed firmware.
- pgeorgi 3y ago
  The main issue these days is the 5GHz band that might interfere with radar. That's mostly an issue outside near an airport, that is, it affects practically nobody, so the solution is to snoop the problematic bands and disable them when detecting radar signals, and use them otherwise for a bandwidth boost. These days this seems to be mostly done in wifi chip firmware (that is then signed and under lock and wrap to make it tamper proof), but back in the day it was too easy to circumvent the mechanism.
tzs 3y ago
There was no requirement that firmware be locked down. The requirement was that consumer radio transmitters could be too easily made to use frequencies and power levels that violate FCC regulations. If a device had a transmitter where firmware could control those things, and the firmware for the device was one blob that contained everything so letting the user replace firmware meant letting the user control those restricted parameters, then the manufacturer might have to lock the firmware. There were other possible approaches. One would be to split the firmware into two parts. One part for the radio hardware and the other for everything else. Make it so the firmware update process only allows the manufacturer to supply the first part.
- Y_Y 3y ago
  Isn't that a bit overreaching? I can make you a device the spews garbage on any wavelength you fancy, so they're really only preventing accidental radio pollution. Even in that case it's pretty unusual to prevent a consumer device (other than a radio) from being used in an unlawful way, Part 15 notwithstanding.
  - zamadatix 3y ago
    I believe the regulation applies to such a device you make as well, not specifically consumer Wi-Fi products. I.e. if you make a transmitting SDR it's not supposed to allow certain things. The prevention all comes down to enforcement though, the law doesn't physically stop you from making a device it just means you could get in trouble for intentionally ignoring it and selling a lot of those devices.
    - Y_Y 3y ago
      You're totally right. I'm trying to make a moral argument, I think if it were unfeasible for an individual to make something (e.g. modern CPU) then you could make an argument for producers limiting them on the basis that it would effectively prevent anyone from doing the banned thing. The fact that it's roughly as easy to reflash an IoT device with custom firmware as it is to make an antenna that produces noise in a forbidden frequency means that you are adding a technical measure to prevent just some of that illegal action and not stopping a determined hacker. I'm not claiming it wouldn't be an overall social good, but other areas of law and regulation don't seem to function like this (with notable exceptions like photocopying banknotes).
dtaht 3y ago
Vint Cerf and I shot that proposed anti-dd-wrt regulation down thoroughly: filing here: http://www.taht.net/~d/fcc_saner_software_practices.pdf http://www.taht.net/~d/fcc_saner_software_practices.pdf Substitute IoT for router in everything we wrote there on page 12-13 and that seems to be a starting point everyone around here has come to think is necessary. I would prefer not to summarize such a large filing here. Also Dan Geer wrote extensively on these topics at the time. Of late I have been strongly suggesting that software be at least "built in america": https://blog.cerowrt.org/post/an_upgrade_in_place/ https://blog.cerowrt.org/post/an_upgrade_in_place/ I care most deeply first - that the front doors to our houses, the home gateways, are properly secured, kept up to date, and have ipv6 and bufferbloat fixes on them. IoT devices belong on their own vlan...

IIRC the main objection was that it could be used to do something with the radio (boost power?) that caused the device to exceed FCC limits for a consumer radio? Something along those lines?

PhilipRoman 3y ago
For those out of the loop these documents have a good introduction to how free software interacts with radio regulations https://wireless.wiki.kernel.org/en/developers/regulatory/statement https://wireless.wiki.kernel.org/en/developers/regulatory/st... https://wireless.wiki.kernel.org/en/developers/regulatory https://wireless.wiki.kernel.org/en/developers/regulatory TLDR manufacturers and "serious" companies won't touch anything that could potentially be configured to emit signals that your local government doesn't like. So Linux has to pretend it doesn't allow to do that (even though anyone with 2 braincells can patch it)
- dtaht 3y ago
  As these regulations change frequently, I am glad that linux makes it possible to update this database and the devices in the field. For example a portion of the 5.9ghz spectrum became available. https://www.computerworld.com/article/2993112/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html https://www.computerworld.com/article/2993112/vint-cerf-and-...
- codedokode 3y ago
  So Linux takes government's side, not user's?
  - chupasaurus 3y ago
    I'd call it "safe defaults".
RF_Savage 3y ago
It was about the radio and being able to modify the radio firmware. As many modifications would void the FCC certifications of the device, due to changed parameters (more power, disabled anti-interface mitigations, out-of-band channels, etc.). This was avoided by making the radio firmware separate blobs, but there was a real danger of the whole device having to have signed firmware.
pgeorgi 3y ago
The main issue these days is the 5GHz band that might interfere with radar. That's mostly an issue outside near an airport, that is, it affects practically nobody, so the solution is to snoop the problematic bands and disable them when detecting radar signals, and use them otherwise for a bandwidth boost. These days this seems to be mostly done in wifi chip firmware (that is then signed and under lock and wrap to make it tamper proof), but back in the day it was too easy to circumvent the mechanism.

tzs 3y ago

There was no requirement that firmware be locked down. The requirement was that consumer radio transmitters could be too easily made to use frequencies and power levels that violate FCC regulations. If a device had a transmitter where firmware could control those things, and the firmware for the device was one blob that contained everything so letting the user replace firmware meant letting the user control those restricted parameters, then the manufacturer might have to lock the firmware. There were other possible approaches. One would be to split the firmware into two parts. One part for the radio hardware and the other for everything else. Make it so the firmware update process only allows the manufacturer to supply the first part.

Y_Y 3y ago
Isn't that a bit overreaching? I can make you a device the spews garbage on any wavelength you fancy, so they're really only preventing accidental radio pollution. Even in that case it's pretty unusual to prevent a consumer device (other than a radio) from being used in an unlawful way, Part 15 notwithstanding.
- zamadatix 3y ago
  I believe the regulation applies to such a device you make as well, not specifically consumer Wi-Fi products. I.e. if you make a transmitting SDR it's not supposed to allow certain things. The prevention all comes down to enforcement though, the law doesn't physically stop you from making a device it just means you could get in trouble for intentionally ignoring it and selling a lot of those devices.
  - Y_Y 3y ago
    You're totally right. I'm trying to make a moral argument, I think if it were unfeasible for an individual to make something (e.g. modern CPU) then you could make an argument for producers limiting them on the basis that it would effectively prevent anyone from doing the banned thing. The fact that it's roughly as easy to reflash an IoT device with custom firmware as it is to make an antenna that produces noise in a forbidden frequency means that you are adding a technical measure to prevent just some of that illegal action and not stopping a determined hacker. I'm not claiming it wouldn't be an overall social good, but other areas of law and regulation don't seem to function like this (with notable exceptions like photocopying banknotes).

dtaht 3y ago

Vint Cerf and I shot that proposed anti-dd-wrt regulation down thoroughly: filing here: http://www.taht.net/~d/fcc_saner_software_practices.pdf http://www.taht.net/~d/fcc_saner_software_practices.pdf Substitute IoT for router in everything we wrote there on page 12-13 and that seems to be a starting point everyone around here has come to think is necessary. I would prefer not to summarize such a large filing here. Also Dan Geer wrote extensively on these topics at the time. Of late I have been strongly suggesting that software be at least "built in america": https://blog.cerowrt.org/post/an_upgrade_in_place/ https://blog.cerowrt.org/post/an_upgrade_in_place/ I care most deeply first - that the front doors to our houses, the home gateways, are properly secured, kept up to date, and have ipv6 and bufferbloat fixes on them. IoT devices belong on their own vlan...