A report from the Linux wireless developers meeting

Wireless Summit 2 report
Stephen Hemminger
 
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.
 
More info is available at:
  http://developer.osdl.org/dev/desktop_architects/index.ph...