Status as of 2012/03/14
The following summary as been extracted from IRC meeting log of 2012/03/14. Full log is available on the ML
Mainline kernel tree status
Technical details are referred to linux-3.2 release.
Currently in v3.2 we have some support code. It consists of socket interface (support for datagram and raw sockets; but raw sockets are kind of deprecated.) and some parts of MLME. All management commands are implemented on top of NetLink? messages family. Management commands consists of MAC control code (mostly resembling IEEE 802.15.4 MLME) and PHY control code. PHY control code (see net/ieee802154/nl-phy.c) consists of commands for adding, removing and listing interfaces. For now, mainline code supports only plain IEEE 802.15.4 interfaces. It even doesn't have a notion of "interface type". More on that later.
Raw socket code was meant for capturing/sending raw frames (with header & company, no FCS) over the RF link. However as we faced the HardMAC devices, we understood that we cannot promise that such "raw" handling will work. In fact the major difference between dgram and raw is a call to dev_hard_header in the handling of dgram messages.
BSD socket interface supports sending messages directly to the other node. It can use either long or short address. No association is required at this point. However it is expected that local devices is configured. Binding sockets to specific interfaces is supported (so I e.g. can say that application will send data only through the second radio. Or from the interface that has address cafe:aaaa
No real support is provided for "indirect messages". Also as we don't have a real message queue, canceling messages is not supported. Another missing thing is support for message statuses. E.g. if sending of the message fails somewhere downside, you won't be able to receive error status.
However the code was submitted to mainline at that point in this state, as it actually permits one to play with HardMAC device drivers (ie. for device that implements all protocol handling on its own, various ieee 802.15.4 modems, development kits, etc).
v3.2 contains basic support for 6lowpan, v3.3 will contain more features like fragmentation.
John Smirl has ported 6lowpan code from Contiki OS. Unfortunately code had some design problems, so it stagnated for a while. Later on Alexander updated this code, fixed most if not all design issues and I blessed him on pushing this code to davem for inclusion into Linux kernel. Code still misses stateful compression (WIP), but that can be added later on demand. Code resides in net/ieee802154/6lowpan.[ch].
Other L3 protocols
No other NextLevel? (NLE/L3) protocols are currently supported in kernel.
ZigBee and ZigBee RF4CE are not permitted to be included into the kernel, as the license on the specification is permitted to be not compatible with GPL. WirelessHART requires hardware support for cryptoACK (ACK packet with security signature).
Speculative idea: ZigBee & RF4CE could come in as user-space stacks
RF4CE brings some additional topics, though, as it requires channel hopping (even if actually the channel hopping in RF4CE is not a time-critical slot-based 'hopping'; you can choose to send your data on one of three channels).
linux-zigbee tree status
Technical details are referred to code in our git repo to the date. Check the wiki for details on cloning and compiling it.
After submitting to mainline the simple and reviewable generic parts, we still had incomplete, messy and sometimes working SoftMAC implementation in our pockets. It is fully present in the linux-zigbee tree on the sf.net. It contains one small addition to the generic part - it adds a notion of device types to the nl-phy handling.
In the distant future, this is intended to be an IEEE 802.15.4 compliant MAC implementation.
Pragmatical idea is to follow code-architecture of mac80211 a little bit. There can be different protocols talking on top of simple PHY interface and different usefull things to handle.
In summary, for now the linux-zigbee code knows about:
- monitor interfaces (one that are able to pass frames exactly as the travel over the radio) - PHY headers are not included (and IIRC FCS is also stripped)
- SMAC (simple MAC by Freescale - bare packet with 2 bytes fixed header).
- and the most interesting part - 802.15.4 protocol handlers.
Data frames are supported. Indirect data sending is not supported.
DATA-REQUEST is also not supported. ASSOC and DISASSOC are supported and work.
Sidenote: as DATA-REQUEST is not supported, ASSOCIATION is implemented with a non-standard quirk. In the standard it is expected that device willing to associate polls for the response using DATA-REQ; but our code just sends the answer back.
Beacon frames are somewhat supported.
It is possible for a coordinator to create a standard-conformant frame and send it in response to BEACON-REQUEST. Network nodes receive and process beacons.
Beacons are added to the beacon_hash structure (net/mac802154/beacon_hash.[ch]), but beacons there do not expire. Also there is no code that is able to query that structure yet.
Beacon-handling code is tightly connected with scanning. Scanning is implemented mostly as a hack. It contains code that loops throught the required channels, switches channels, taking pib_lock, and then waits for some time on the channel. Active scan will send a beacon-req after switching to the channel. passive scans wont.
This is one of the places where mlme would benefit from internal synchronization. E.g. it should possible to run some other things in parallel with the scan. Instead frame processing should either wait for the scan to finish, or return -EBUSY. Same goes for the parallel scans. Another problem of scanning code is that ... they don't return results to the caller. Scanning code has to be reworked. The problem is that there is no easy way to return multiple values from single function. And just following MLME "procedures" here looked ugly for us.
At least data frame handling, nl-phy changes and monitor/smac should be pushed to the davem tree soon or later.
Next goal should be either to support data + data-req + assoc on top of d-r + scan, or to run to the MiWi? compatibility of some kind; then should probably come security.