Main menu

Tag Archives: WiFi

I recently did a routine package update on my Fedora 24 laptop. I’ve had the laptop for three years and have been running various Fedorae the whole time, so I didn’t think much of it. So it came as some surprise to me when after rebooting I could no longer connect to my WiFi network. In fact, there was no indication that any wireless networks were even available.

Since the update included a new kernel, I thought that might be the issue. Rebooting into the old kernel seemed to fix it (more on that later!), so I filed a bug, excluded kernel packages from future updates, and moved on.

But a few days later, I rebooted and my WiFi was gone again. The kernel hadn’t updated, so what could it be? I spent a lot of time flailing around until I found a “solution”. A four-year-old forum post said don’t reboot. Booting from off or suspending and resuming the laptop will cause the wireless to work again.

And it turns out, that “fixed” it for me. A few other posts seemed to suggest power management issues in the rt2800pci driver. I guess that’s what’s going on here, though I can’t figure out why I’m suddenly seeing it after so long. Seems like a weird failure mode for failing hardware.

Last month, The Register reported on a new OpenWRT release. OpenWRT is a Linux distribution designed to be installed on embedded devices like routers. It, along with other third-party firmware projects like Tomato and DD-WRT, offers users more flexibility than the original firmware. They often get updates long after the first-party firmware, and can provide a more stable system. For example, I had a Linksys WRT-54G that was starting to get flaky, to the point where I had to power cycle it every day or so. After installing OpenWRT, it became much more reliable.

I lay out the benefits of third-party firmware, because the El Reg article brought to my attention a document published by the Federal Communications Commission (FCC). The guidelines, last updated in March of this year, outline the security questions device manufacturers should answer in their Part 15 application. Part 15 refers to the section of U.S. regulations that deals with unlicensed radio frequency (RF) transmission (including WiFi). The document says, in part:

An applicant must describe the overall security measures and systems that ensure that:

1. only properly authenticated software is loaded and operating the device; and
2. the device is not easily modified to operate with RF parameters outside of the authorization.

These requirements are antithetical to the ideals of open source and the user freedom it is committed to promote. As an amateur radio operator, I am sensitive to the concerns regarding spectrum pollution. Part 15 devices can be a pain for licensed portions of the RF spectrum anyway, and allowing devices to be easily modified to transmit outside their intended band presents a real threat to licensed radio services, including public safety and aviation.

Essentially, it comes down to protecting wireless spectrum (by preventing unlicensed transmission) versus protecting Internet users (by allowing for more security updates and external auditing of the code running on routers). These are both legitimate concerns, and I’d advocate for either of them independently. When they’re pitted against each other, though, I have to side with free software.

Regardless of the technological restrictions put in place to prevent unlicensed transmission, they can be circumvented. The entire history of technology is a history of restrictions and circumventions. Additionally, the ability to (responsibly) modify and experiment with hardware is an important part of innovation. The updates and configuration flexibility of third-party firmware provide a real benefit (though I naively assume that a non-trivial portion of devices will get such firmware) against everyday threats. Given the choice, my choice is clear. I hope the FCC will come to agree with me.