OSDL Desktop Linux sponsored a second meeting of the Linux wireless developers at Westminster University in London. The meeting was scheduled over the weekend as a follow on to the IEEE 802 meeting so that hopefully more vendors and others would attend. The participants included kernel developers and vendors including Intel, Broadcom, Devicescape, Monta vista, Nokia.
After a basic introduction, the meeting opened with a presentation from John Linville, the wireless maintainer on the key issues. Development work is proceeding on a new 802.11 stack (d80211) but the work is proceeding too slowly. Several problems like locking and transition plans haven't been worked out. There is a also new API (cfg80211) but development is even slower.
Johannes Berg talked about the new cfg80211 API. Unlike the existing Wireless Extensions API which is based on ioctl's, the new API is message based using generic netlink. Devices can implement only the new interface and cfg80211 will provide the backward compatibility for the WEXT interface. The existing old WEXT would be frozen, new features would be cfg80211 only. It looks like a good start but there are no user interface tools (the iproute2 equivalent of iwconfig).
Dan Williams talked about Network Manager plans. The current version uses wpa_supplicant and supports multiple active devices and system wide configuration. Looking ahead, he said they plan to support more protocols like PPP and things like dialup networking over Bluetooth. It looks like there won't be a big impact on wireless drivers if they use standard APIs.
Jirà Benc described the current Devicescape 802.11 (d80211) stack. It is maintained in a separate git tree (git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git) along with the six current drivers that use it. There are a number of the issues that currently block getting it into the mainline kernel. The current code has locking issues especially with USB devices where configuration can take a long time. For PCI devices, this is not an issue. The configuration interface is not finished, cfg80211 support will probably solve this. Regulatory domain control is not implemented, and it is not clear whether this can be done in a generic way. A discussion was started on ways to increase the number of user/developers. Having a separate mailing list (for wireless drivers) and making source packages available for "generic" kernels would hopefully capture more developer/users outside the small netdev group.
Luis Rodriguez described the Rutgers University wireless testing lab. They have a 400 node grid of machines hanging from the ceiling. The boxes are custom with 2 wireless ports, a PCI slot and USB. They use point-to-point cables with attenuators to interconnect. There is also a remote control robot that moves around the floor for testing roaming between nodes. Developers should be able to register and get access to nodes for research and testing.
One breakout session covered the technical issues in the d80211 stack. In addition to the locking issues, a lot of semantic issues were raised such as: firmware loading, signal quality definition, device state, error handling, etc. Most of them 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.
The other breakout session dealt with regulatory concerns. There were vendors (Intel, Broadcom) and open source people so it was very "lively". Hardware vendors license their equipment under FCC section 15 regulations, even though technically pure software devices could be under Software Defined Radio (SDR) regulations. FCC wants all devices to have a "no trespassing" sign on radio settings but there is no consensus on what that means. 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). The reverse engineered drivers don't have this problem but it is not clear what the legal implications of redistributing them is. 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.
On Sunday, there were sessions on packaging up the development code and documentation. The packaging session talked mainly about the software configuration control issue of having two code bases and how to produce a tarball from the tip of the d80211 git tree. Intel has already done work on this as part of using d80211 for the follow on ipw3945 driver. The documentation group decided to use the kerneldoc infrastructure to produce better d80211 API and cfg80211 documentation. The plan is to use linuxwireless.org as a repository for general specs. This group also discussed the possibility of having "certified for Linux" logo for wireless cards, but the details and impact seem undecided.
There was a discussion of the more advanced features of the d80211 stack that probably aren't getting used yet. Nokia was interested in Quality of Service (QOS)and Wifi Multimedia (WMM) support because their existing device uses a proprietary userspace library. D80211 supports (WMM) based on the IP type of service (TOS) value in the socket API. There was some question as to whether non-root users can set TOS (they can), and whether existing glibc header files include the right values. Multimedia applications, like Ekiga, Skype, and Google Talk, are not properly setting TOS. The WMM standard comes out of the Wifi Alliance and is a subset of the IEEE 802.11e standard; many devices are WMM certified but very few implement 802.11e.
Bridging of wireless doesn't work for most users now (only works with single client or using address translation). The d80211 stack supports full Wireless Distribution System (WDS) but it is not clear if any of the devices using d80211 have the necessary firmware support.
The d80211 stack has a master network interface that might be extended to provide a native 802.11 frame format device. This would allow for easier monitoring and tracing and might reduce the number of 802.3 to 802.11 translations in some scenarios. But the idea was rejected because it would cause lots of other areas of the kernel to change: raw sockets would need additional flags (to prevent sending 802.11 frames to applications expecting Ethernet framing); bridging would have to do address translation; and worst of all the destination cache would have to handle variable size addresses and multiple mappings.
Another group discussed how to go forward with media access control (MLME). The existing d80211 stack does MLME in the kernel. With all the new security and other standards, it is desirable to move this into userspace but it introduces a number of locking problems because the actual device state would be shared between kernel and a user space control program. The plan is to keep the existing basic MLME in the kernel and use user space MLME for more complicated functions.
Overall, the summit was very productive despite (or because of) the lack of Internet access. The main new items coming out of it were: a commitment to make an experimental wireless tarball (and driver) packages available; progress on the new cfg80211 API; and an understanding of the regulatory environment that vendors have to operate in. A follow on meeting is planned for fall (October) either on East coast of US, or maybe in Israel.