Hello,
On Fri, Mar 7, 2014 at 4:16 PM, Phoebe Buckheister
<phoebe.buckheis...@itwm.fraunhofer.de> wrote:
> Hi,
>
> the 802.15.4/6LoWPAN stack on Linux is pretty usable as it is now, much
> due to the recent 6lowpan fixes by Alex. We can drive different radio
> chips on different frequencies, IPv6 works well and we interoperate
> just fine with RFC compliant stacks like the one implemented in Contiki.
>
> There are, however, also a number of sore points, which I want to
> outline in this message and for which I want to propose possible
> solutions. These sore points range anywhere from minor annoyances to
> what I view as major integrity problems. I'll list what comes to my
> mind here, in no particular order. If you have any idea how to fix
> something, if you have something to add to the list or merely want to
> tell me where and why I am mistaken, please do so.
>
> 1) header handling in the stack
>
> We currently have three points in the stack that parse or create
> 802.15.4 headers, where two of those are already duplicated code - in
> the same source file no less. Header handling for mac802154 is
> cumbersome, and for upper layers entirely impossible without
> duplicating more code at the moment. I have a patch that attempts to
> rectify this by adding structs for the 802.15.4 header and its
> components, but that was shot down by davem due to some endianness
> issues. I am reworking the patch to fix all of this and will resend it
> soon, but it doesn't end with that.
Strange. I don't remember issues with headers code, but that was looong
time ago. I was puzzled by header-related code in 6lowpan. For the headers
there is a simple requirement: dev_hard_header() should work for both
SoftMAC and HardMAC drivers. That means that before calling
dev_hard_header() the frame does not contain header at all.
> 2) endianness in the stack
The stack was tested on PowerPC boxes, but that was some time ago
(at least before 6lowpan work). If you need an access to PowerPC box
to run tests, I can think about arranging that.
> We really never use network byte order on purpose, and inside of the
> stack we should really change that. Ideally we'd also change it in the
> userspace API if we ever got the chance to do that, because
> AF_IEEE802154 is the *only* protocol i know that uses all byte orders
> in it's sockaddr struct *except* network byte order.
This can be hard and davem would probably disallow it :(
Sockaddr for 802.15.4 should have used native byteorder, if I'm not mistaken.
> 3) the mac802154_priv slave list
>
> This is one of the biggest problems I think the current stack has. For
> HardMAC, every netdevice corresponds to one specific WPAN (made up of
> PAN ID, channel, and page) and it is pretty much guaranteed that
> multiple HardMAC netdevs will always function as intended, even if they
> are backed by the same piece of hardware.
>
> SoftMAC, on the other hand, takes a single PHY chip and adds an
> *arbitrary* number of specific WPANs on top of that PHY. No real
> hardware can support an arbitrary number of specific WPANs, and no chip
> I have yet come across can even support more than one. As far as I've
> been told and was able to reconstruct from documentation and standards
> documents, this was implemented to allow for ZigBee frequency agility,
> but that was never implemented. What we have, though, is a means for
> unprivileged users that can run socket(), write() and ip(8) to
> effectively DoS a node that uses this feature.
This was done to support different kinds of devices accessing the radio.
Compare to 802.11 stack, which has phy & device conception.
It really helps to separate between the radio-related parts and functional
(MAC) things.
1) 802.15.4. At the moment of writing there was no difference between
plain device and coordinator. (It was expected that the need to
differentiate between device and coordinator may arise in the future.
Compare to 802.11 AP and Mesh devices.)
2) Monitor. A device returning a frame with _all_headers to userspace.
W/o any processing. Again, compare to 802.11 stack - they added
monitor devices.
Left over or not implemented:
3) SMAC - Freescale's 'Simple MAC'. Broadcast frames, two-byte header
to identify SMAC, no addressing. Used mostly for their demonstrations
and for hobbyist simple devices. It is present in linux-wpan kernel and
I think it's worth adding it to mainline
4) MiWi. Microchip's 802.15.4 variant. While it shares lot's of commons
with main 802.15.4 standard, it has some simplifications in the
areas of address negotiation and association/removal. Not implemented,
but it might be worth looking into it - it is a 'baby 802.15.4',
so implementing
it would also help main 802.15.4 stack.
5) MiWi P2P - Another fancy from Microchip. Don't remember the details.
6) _anything_ else. This band and these radio modems are used for lots
pf hobbyist devices. Moreover, the notion of 'WPAN device is a device
supporting transmission of frames <= 127 bytes with 2-byte CRC16
at the end of the frame' should allow implementing other fancy devices
through this stack. In Siemens we were contacted by a French company
that developed powerline devices. They are not 802.15.4 devices,
because standard defines no powerline phy (yet). Those guys were
interested in transmitting 802.15.4 frames on top of these devices.
Or a custom frames. Another example: 802.15.7 Visible Light
Communications look very similar to 802.15.4. Very but not equal.
So it is possible to support 'VLC' drivers on top of 'WPAN phy'.
The driver would share lot's of code with 802.15.4. And still
allow to support VLC peculiarities.
Note. I did not say a word about ZigBee or 6lowpan. Those are next-level
protocols. They are not to be implemented as wpan phy slaves. Instead
they use low level protocols (802.15.4 in this case) and operate them
through protocol-related interface (netlink + data), be it a userspace
implementation or a kernel-space one.
I think I have said enough to convince you (and other developers) that slaves
are important part of the stack and phy <-> dev separation should be
supported. Just stop living in 802.15.4-only world. This parts of universe
centers around 802.15.4, but is not limited to it.
Regarding multiple 802.15.4 devices per single phy, switching channels, etc.
At the time we did this, stack contained (and it still contains) areas
requiring more attention. To make multidev configurations work safely
one just needs to add several checks in the code and several error codes
around.
In fact (yes, I'm not joking) the ability to add several devices and to
switch channels from each of the device was considered as a feature,
not as a bug. If you did this, you certainly knew what you are doing.
And why. So if the driver fails, it's your problem (note: fails, not crashes).
On the other hand, it allows running several interesting experiments
and to deploy interesting configurations.
> I thus propose to remove this feature entirely and instead have a 1:1
> correspondence between PHYs and netdevs. If a driver can support
> multiple specific WPANs per chip, it can register multiple PHYs. If
> anybody actually needs to reconfigure the device to a different
> specific WPAN, we already have an interface for that: the netlink API.
> The netlink API also has the benefit that it does not impose arbitrary
> delays before the switch, as switching by sending a packet does when
> reordering/shaping Qdiscs are configured on the WPAN.
It's your community-based choice now. However I'd suggest to leave
that in place. See 802.11 stack - there are much more similarities
that one would have expected.
[skipped]
> 4) our *drivers* are expected to *sleep*
>
> This is just wrong. Our RX/TX path invokes the scheduler at least once
> for every packet on the assumption that drivers might sleep, which may
> entail arbitrary delays even after the Qdiscs of the system have run.
> Especially when somebody wanted to use latency sensitive Qdiscs, this
> is a disaster, but also for general system throughput once you have a
> certain number of packets going through your node.
I'm not sure about RX path (I just don't remember details at this point).
There are netif_rx and netif_rx_ni functions.
For TX path things are really simple. ndo_start_xmit can not sleep.
at86, serial - all require sleeping in the tx path. For at86:
Change the state, wait for the change to finish, program the buffer,
toggle the gpio. Lot's of waiting and sleeping there.
It would be possible to move the schedule&company to the driver
itself. I don't remember if we tried that or not. However we felt that
it would be simpler to handle all scheduling inside mac80154 core.
You can shift schedule_work & company to the final drivers,
You won't get rid of them completely.
--
With best wishes
Dmitry
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
