Similarly, if one has a wi-fi card in one's PC, it is subject to this limitation, as is the drivers used it access it. If the FCC wished, they could engage in interpreting the proposed rules to prevent drivers from being changed in machines using wi-fi cards. Fortunately, the don't wish so at the moment.
Canada's Communications Security Establishment used to to just that: my boss was building ruggedized PCs for External Affairs, and they helped him with a TEMPEST project. Less so these days, but we also have a very odd government in power (;-))
The IETF lists are concerned that some of the proposals will massively degrade the bands wi-fi uses under the current rules. It came up as a side issue in the bufferbloat discussion, which I follow.
Not at all: in US law, the operator of these devices is responsible, even if the vendor screws up.
That also means they need the ability to fix the software, of course...s
Airport weather radars, which are both stupid and safety-critical, noted in another thread here. Supposedly some vendor was using their reserved channels, possibly by using a hacked DD-WRT
Can you give us a citation or a google search string? Part of the problem is group A is fixing routers, group F (FCC) is changing rules without explanation and group C knows the explanation.
There is no market for a more expensive cheap home router, the market is for a cheaper one. It's been a race to the bottom for some time, which is why the IETF, very specifically Dave Taht, is fixing issues like bufferbload and stuck-on transmitters that the vendor's won't touch.
Unfortunately, the amount of low-level firmware is small, and the majority of the flashable chip is full of Linux and a GUI. The radio bits are the firmware itself, and the device driver that maps it to the routing software. All the latter bits are where we need to do repair, for both compliance and functionality, not often the firmware. Recently one vendor had a driver that on error would tie up a channel mindlessly until it timed out, which was just a tiny bit of a compliance problem (;-))
It's still open, they extended it to October 9, this Friday : go to https://libreplanet.org/wiki/S... and comment!
Especially if you're an American citizen (I'm from Canada)
Assuming no changes were made to the FCC's rules, and if a router manufacture [...] lock down the radio portion of their router so it can't possibly be modified by the end user, but still leave the firmware of their router otherwise ordinarily modifiable as it is currently, would the manufacturer still be in violation of the current rule proposal?
Presumably, but the current problem is the opposite one!
Right now, many vendors prefer to interpret the rules to allow them to ship binary blobs for the radio bits. Much of that is GPL or BSD, and in the process the vendors are neither honouring the GPL nor even allowing the original authors of the software contribute fixes.
They would need a business justification or an FCC mandate to cooperate in that way: in one of the proposals, we ask that the FCC mandate published source, professional source control (github) and verifiable builds, so the purchasers can fix non-compliant devices (which they're legally required to do now, but can't)
The problem seems to be that some few airport weather radars are interfered with by existing home routers on the same frequency. They supposedly fail to detect the channel is busy doing safety-critical radar stuff, and sit there creating interference.
However, we can't confirm that. We don't know the brand of router, the specific frequency in question, the number of airports that have the radars or the prevalence of the problem: we just got a proposed mandate that the vendor “describe in detail how the device is protected from flashing and the installation of third-party firmware such as DD-WRT.”
That can be done in some phones, but the normal approach in embedded systems like home routers is to build and run the entire system from a single system-on-a-chip and it's eprom. The latter is sometime part of the chip.
That make separation physically impossible with existing products, and means future products would have to switch to a new hardware architecture with no extra profit from the change.
If enough countries (Canada, Mexico, etc) find out they've been shafted, the ratification will drag on, and on and on, to eventually be dropped for lack of interest.
Roughly the same as the US, with detail differences. In both countries you can sue anyone for anything and tie them up in litigation. One province and a few states have explicit SLAPP statutes, and sharp judges will hit frivolous suits with costs against.
Slashdot Mirror
Similarly, if one has a wi-fi card in one's PC, it is subject to this limitation, as is the drivers used it access it. If the FCC wished, they could engage in interpreting the proposed rules to prevent drivers from being changed in machines using wi-fi cards. Fortunately, the don't wish so at the moment.
With even the limited current access, the bufferbloat team *fixed* a non-compliant router that had a stupid-retry-constantly loop in the driver.
Canada's Communications Security Establishment used to to just that: my boss was building ruggedized PCs for External Affairs, and they helped him with a TEMPEST project. Less so these days, but we also have a very odd government in power (;-))
The IETF lists are concerned that some of the proposals will massively degrade the bands wi-fi uses under the current rules. It came up as a side issue in the bufferbloat discussion, which I follow.
Not at all: in US law, the operator of these devices is responsible, even if the vendor screws up. That also means they need the ability to fix the software, of course...s
Airport weather radars, which are both stupid and safety-critical, noted in another thread here. Supposedly some vendor was using their reserved channels, possibly by using a hacked DD-WRT
Can you give us a citation or a google search string? Part of the problem is group A is fixing routers, group F (FCC) is changing rules without explanation and group C knows the explanation.
It's reported as interference with safety-critical airport weather radar in another thread on this page
Google will point you the the slashdot articles on Dave (;-))
There is no market for a more expensive cheap home router, the market is for a cheaper one. It's been a race to the bottom for some time, which is why the IETF, very specifically Dave Taht, is fixing issues like bufferbload and stuck-on transmitters that the vendor's won't touch.
That's very true of ham radio with kilowatt power levels, but this *seems* to be a problem with use of frequencies used by weather radars...
That's in a per-country DB in Linux and, as far as I know, BSD.
There is a by-country database of allowed/prohibited channels: I (and the IETF committee) would love to know which vendors aren't honouring it.
Unfortunately, the amount of low-level firmware is small, and the majority of the flashable chip is full of Linux and a GUI. The radio bits are the firmware itself, and the device driver that maps it to the routing software. All the latter bits are where we need to do repair, for both compliance and functionality, not often the firmware. Recently one vendor had a driver that on error would tie up a channel mindlessly until it timed out, which was just a tiny bit of a compliance problem (;-))
Could you join the discussion on bloat@lists.bufferbloat.net: that's the best short description I've heard!
It's still open, they extended it to October 9, this Friday : go to https://libreplanet.org/wiki/S... and comment! Especially if you're an American citizen (I'm from Canada)
Assuming no changes were made to the FCC's rules, and if a router manufacture [...] lock down the radio portion of their router so it can't possibly be modified by the end user, but still leave the firmware of their router otherwise ordinarily modifiable as it is currently, would the manufacturer still be in violation of the current rule proposal?
Presumably, but the current problem is the opposite one!
Right now, many vendors prefer to interpret the rules to allow them to ship binary blobs for the radio bits. Much of that is GPL or BSD, and in the process the vendors are neither honouring the GPL nor even allowing the original authors of the software contribute fixes.
They would need a business justification or an FCC mandate to cooperate in that way: in one of the proposals, we ask that the FCC mandate published source, professional source control (github) and verifiable builds, so the purchasers can fix non-compliant devices (which they're legally required to do now, but can't)
The problem seems to be that some few airport weather radars are interfered with by existing home routers on the same frequency. They supposedly fail to detect the channel is busy doing safety-critical radar stuff, and sit there creating interference.
However, we can't confirm that. We don't know the brand of router, the specific frequency in question, the number of airports that have the radars or the prevalence of the problem: we just got a proposed mandate that the vendor “describe in detail how the device is protected from flashing and the installation of third-party firmware such as DD-WRT.”
Yes, the rulemaking applies to all wi-fi devices, not just COTS home routers, so it will affect wi-fi cards.
That's worthwhile: please make that comment to the FCC
Actually it makes it harder for CSIS and their friends, who have to hack the vendors instead of just the products (;-))
That can be done in some phones, but the normal approach in embedded systems like home routers is to build and run the entire system from a single system-on-a-chip and it's eprom. The latter is sometime part of the chip. That make separation physically impossible with existing products, and means future products would have to switch to a new hardware architecture with no extra profit from the change.
Dave Taht (best known for "bufferbloat") is working on one, as are others.
To make your own comment, go to https://libreplanet.org/wiki/S...
If enough countries (Canada, Mexico, etc) find out they've been shafted, the ratification will drag on, and on and on, to eventually be dropped for lack of interest.
Roughly the same as the US, with detail differences. In both countries you can sue anyone for anything and tie them up in litigation. One province and a few states have explicit SLAPP statutes, and sharp judges will hit frivolous suits with costs against.