Practical Technology

for practical people.

Linux hackers tackle WiFi hassles


When it comes to troublesome Linux peripherals, WiFi takes the cake. Sparked by the Portland Project’s efforts to bring standardization to the Linux desktop, the Linux wireless developer community tackled this problem at its second Linux Wireless Summit last month in London.

The Summit was scheduled as a followup to the January IEEE 802 standards committee meeting, which, among other issues, moved a step closer to making 802.11n a real IEEE standard. As a result of this timing, participants at the Linux WiFi meeting included kernel developers and vendor representatives from Intel, Broadcom, Devicescape, MontaVista, and Nokia.

Once there, according to Stephen Hemminger, Linux Wireless Summit co-coordinator and a Linux software developer at the Linux Foundation, the attendees had a very productive meeting.

Still, it’s been slow going in some critical areas of Linux and WiFi, according to John Linville, the Linux wireless software maintainer. In particular, Linville reported that development work is proceeding too slowly on a new 802.11 stack (d80211); and with a new WiFi API (cfg80211), “development is even slower.” Hemminger described the cfg80211 as “a good start but there are no user interface tools (the iproute2 equivalent of iwconfig).”

As for d80211, a breakout session addressed its technical issues. Hemminger wrote in his report on the summit that most of its problems “are not specific to the d80211 stack but have existed all along in Linux wireless. The problem is that up to now each device was doing its own different implementation. The d80211 stack currently exposes a ‘master’ interface which is only used for reconfiguring the internal queuing disciplines. Since the master interface shows up as a device, it can be a potential point of bugs or user confusion so there was discussion on ways to get rid of it prior to acceptance in the main kernel.”

There was also a discussion of the d80211 stack’s more advanced features that are seeing little use as of yet. In particular, Nokia was interested in QoS (Quality of Service) and WMM (WiFi Multimedia) support, because their existing device uses a proprietary userspace library.

As it is, “D80211 supports WMM based on the IP type of service (TOS) value in the socket API,” Hemminger added. This led to a discussion of whether or not existing glibc header files include the right values for WMM/TOS. It was noted that many existing multimedia applications, like Ekiga, Skype, and Google Talk, are not properly setting TOS.

Another breakout session dealt with regulatory concerns. This discussion led the group into facing the dilemma of proprietary hardware and firmware. According to Hemminger, “Hardware vendors license their equipment under FCC section 15 regulations, even though technically pure software devices could be under SDR (Software Defined Radio) regulations. FCC wants all devices to have a ‘no trespassing’ sign on radio settings but there is no consensus on what that means.”

As a result, “the only solution that can get certified in the current regulatory environment is to have a closed source component either in firmware (good), kernel (bad) or userspace (less evil),” Hemminger continued. The reverse-engineered drivers don’t have this problem, but the developers were concerned about the legal implications of redistributing them. “There is some concern since FCC has already stopped hackers who modify power levels on access points. Vendors are reluctant to address the SDR issues too directly because of the regulatory impact to existing non-Linux products if there was any problem.”

The reason why the FCC takes this position is that the governmental agency doesn’t want it to be easy for users to tamper with radio settings or power levels. Thus, the only WiFi solution that can be certified must have a closed source component. Thus, as distasteful as it is to some free software distributors, legal support for WiFi on Linux will often have to incorporate proprietary elements in one way or another.

Coming out of the meeting, the developers committed to make experimental wireless tarball (and driver) packages available; move faster on the new cfg80211 API; and gain a more complete understanding of the regulatory WiFi situation.

The next Linux Wireless Summit will be this fall, most likely in October, on either the U.S. East Coast or in Israel.

A version of this story first appeared in DesktopLinux.

Leave a Reply