The reason they want to regulate the software is because regulating the hardware is soon not going to be sufficient.
Hopefully one day we can use extreme versions of beam forming (e.g. the pCell) to replace the need for RF regulations and switch to space based multiplexing as opposed to frequency based multiplexing.
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.
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...?
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.