Maybe I'm misunderstanding, 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?
> 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.
There are regulations about what frequencies and at what power different devices may broadcast. Currently, those implementations (and hence regulations) are done/enforced in some combination of hardware and software, but mostly hardware. Implementation is moving to software, so updating the OS allows the user to override those regulations. The FTC is not thrilled about this.
Yeah, I understood that, I was just confused as to why he or she mentioned firmware along with software because I thought firmware can't be modified by users like software can. I was wrong in thinking that though.
I've been using Tomato-USB on Asus hardware for several years now... the current Asus firmwares aren't bad though the early ones were pretty horrible. I actually prefer Tomato and similar options, I used openwrt for my home office (routerstation pro) for a few years as well. Being able to run third party software is essential for security updates given that the manufacturers rarely offer more than 1-2 updates and almost never after the first year of a product introduction.
Tomato, dd-wrt, openwrt and the like allow me to control my hardware and use it for the life of the hardware, not the year of updates the mfg gives.
I also like Tomato on ASUS hardware, but as far as updates go, it seems little-to-no better than using stock manufacturer firmware. There is no central development project, and there is no one who ensures that new updates work on existing hardware. It seems like a few people put together some builds that work on what they have, toss them over the fence, and everyone else is left scrounging for what works on their particular hardware.
And are you really going to experiment with building it yourself when you're talking about your Internet router? What do you do if it bricks?
I've been thinking for some time now that the only sensible way forward is a device that runs plain Debian stable, something Raspberry Pi-like, with a USB dongle or two and a plain Ethernet switch. That way, keeping up-to-date is as simple as `apt-get upgrade`. And with a few SD cards, one can easily keep multiple working system images, clone them, and swap between them for testing and upgrades. This situation in which it's even possible to brick a router seems like primitive savagery and madness.
But, not having a DD-WRT/OpenWRT-compatible router, maybe I'm just missing out...?
Dunno... It's pretty hard to brick the router beyond recovery via tftp... That said, I'm no expert on the issue... I've been using the Shibby Tomato-USB releases myself, but tbh don't update as much as I should.
Looks like there's no third party release for the RT-AC3200 yet, though the mfg release is modified tomato.
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.