Re: [Linux-zigbee-devel] Linux WPAN sources for ZigBee porting

Re: [Linux-zigbee-devel] Linux WPAN sources for ZigBee porting

[Alexander Aring]

Hi,

> >
> >> Just now I am trying to define which MAC features required by ZigBee exist
> >> and which are missing.
> >
> > many.
> 
> I know... For now it looks like not using Linux wpan is simpler than use it.
> 

correct.

> >
> >>
> >> Which WPAN sources I need to look into?
> >> Is it official Linux kernel?
> >> Is it in https://github.com/linux-wpan/linux-wpan-next ?
> >
> > Yes it is.
> >
> > master: things which should be mainline.
> > testing: patches for integrating process.
> 
> ok, thanks.
> 
> >
> >> Which branch?
> >>
> >> Is serial protocol v.2 already implemented?
> >
> > No, also v1 isn't mainline.
> 
> Yes, I already found a patch for v1.
> What i definitely need from the serial protocol is ability to do indirect send.
> 

indirect send?

> >
> >> What do you think about its modification if it will be necessary for
> >> ZigBee? It will be, for sure...
> >>
> >
> > mac802.15.4 isn't in an useable state. I am currently try to change it
> > look in the rework branch.
> 
> wpan_rework_rfc?
> 

Yes, but it's not in a mainline state. I disabled for integrating
process the 802.15.4 address family. For ZigBee userspace stuff you need
definitely af802154. I could give you the advice to make everything on
802.15.4 RAW sockets. DGRAM sockets are only for data frames and the userspace
API will be changed eventually.

For af802154 you can use current mainline state.

- Alex

Re: [Linux-zigbee-devel] Linux WPAN sources for ZigBee porting

[Alexander Aring]

On Thu, Oct 02, 2014 at 12:27:17PM +0200, Alexander Aring wrote:
> Hi,
> 
> > >
> > >> Just now I am trying to define which MAC features required by ZigBee exist
> > >> and which are missing.
> > >
> > > many.
> > 
> > I know... For now it looks like not using Linux wpan is simpler than use it.
> > 
> 
> correct.
> 
> > >
> > >>
> > >> Which WPAN sources I need to look into?
> > >> Is it official Linux kernel?
> > >> Is it in https://github.com/linux-wpan/linux-wpan-next ?
> > >
> > > Yes it is.
> > >
> > > master: things which should be mainline.
> > > testing: patches for integrating process.
> > 
> > ok, thanks.
> > 
> > >
> > >> Which branch?
> > >>
> > >> Is serial protocol v.2 already implemented?
> > >
> > > No, also v1 isn't mainline.
> > 
> > Yes, I already found a patch for v1.
> > What i definitely need from the serial protocol is ability to do indirect send.
> > 
> 
> indirect send?
> 
> > >
> > >> What do you think about its modification if it will be necessary for
> > >> ZigBee? It will be, for sure...
> > >>
> > >
> > > mac802.15.4 isn't in an useable state. I am currently try to change it
> > > look in the rework branch.
> > 
> > wpan_rework_rfc?
> > 
> 
> Yes, but it's not in a mainline state. I disabled for integrating
> process the 802.15.4 address family. For ZigBee userspace stuff you need
> definitely af802154. I could give you the advice to make everything on
> 802.15.4 RAW sockets. DGRAM sockets are only for data frames and the userspace
> API will be changed eventually.
> 

Okay, netlink interface will definitely be changed in future. Sorry.

- Alex

Re: [Linux-zigbee-devel] Linux WPAN sources for ZigBee porting

[Alexander Aring]

Hi,

On Fri, Oct 03, 2014 at 08:12:17AM -0700, Owen Kirby wrote:
> Hi,
> 
> On 14-10-02 03:29 AM, Alexander Aring wrote:
> > On Thu, Oct 02, 2014 at 12:27:17PM +0200, Alexander Aring wrote:
> >> Hi,
> >>
> >>
> >>> I know... For now it looks like not using Linux wpan is simpler than use it.
> >>>
> >> correct.
> A while ago, we were also interested in porting our ZigBee stack to use 
> the linux-wpan interface, and we came to the same conclusion. The API is 
> missing too much of the IEEE 802.15.4 MLME components to provide support 
> for a workable ZigBee stack. In the end, we wound up implementing our 
> IEEE 802.15.4 driver in userspace along with the ZigBee stack; It works 
> quite well, but one of these days I would still like to port it to 
> linux-wpan.
> 

mhhh, what do you using right now? The old linux-zigbee kernel sources?
Or mainline state? linux-wpan is mainline state.

But, great I heard the first time that this stack is in some commercial
product (sounds like it).

> The three major compoenents that are missing from the API are:
>      * MLME-ASSOCIATE
>      * MLME-SCAN (and generation of beacons).
>      * Indirect packet transmission.
> 

ah indirect packet transmission. Some part of 802.15.4 which I don't
looked right now at it, because we are far away to support it. ;-)

> In theory, you could cobble something together that does association and 
> scanning from userspace with a raw socket, but there would probably be 
> enough hacking necessary to get it working correctly that it would be 
> much cleaner to implement it in kernelspace with a netlink command.
> 

Yes, this should something like mac80211 association/deassociation. Like
802.11 this is part of MLME. The kernel implementation for looks like
[0]. This can be triggered over netlink. 802.15.4 should have similar
things.

> Indirect packet transmission is something that needs kernel support (and 
> sometimes even hardware support), since it relies on fiddling with the 
> ack packets.
> 

Ack handling via kernelspace... sounds problematic. I need to dig into
this how the phy could handling this ack handling, if possible.




I don't know if you already know about it but I try to make a full
rework of mac802154 and ieee802154 [4]. The current netlink interface is in
a very awful state, kernel headers which should be uapi have some
"extern" keywords, etc... don't know why. In the rework I will mainly
orient to mac80211/wireless stack, to have the likely frameworks.

Also there exists now three interface types:

- NODE
- MONITOR
- COORD

For running as node, monitor or coordinator. Maybe we could merge NODE
and COORD, but I can't overlook this at this moment so we should offer
to make runtime decisions at kernelspace for node or coordinator.

Also this could be simple handling for FFD and RFD. FFD's could only
create a COORD interface.

Coordinator isn't supported right now, in the rework branch I will add
support like current mainline state, then we can thing about "how to
send it mainline".

Netlink interface will completely new, you as user of this stack will be
shocked right now. But I don't see that we can still use the current
behaviour.

New netlink, looks like [2]. I didn't implement a mlme ops yet but for
bring mainlining and to have a direction how it should work I will try
implement a channel scan, don't know right now which one
passive/active/etc... So we should have some minimal coordinator
functionality.

For the new netlink interface, simple add new netlink ops into
nl802154_ops struct. It's like wireless.

For the rework branch you need wpan-tools, not the lowpan-tools
anymore. [3]

I know, I didn't much documented what I did there. When I will bring
this rework mainline, then I will show the changes. At the moment I am
still try to experiment a little bit to see what we can do better.


btw. mailinglist changed to [1].

- Alex

[0] http://lxr.free-electrons.com/source/net/mac80211/mlme.c#L577
[1] http://vger.kernel.org/vger-lists.html#linux-wpan
[2] https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/ieee802154/nl802154.c
[3] https://github.com/linux-wpan/wpan-tools
[4] https://github.com/linux-wpan/linux-wpan-next/tree/wpan_rework_rfc

Re: [Linux-zigbee-devel] Linux WPAN sources for ZigBee porting

[Owen Kirby]

Hi,

On 14-10-03 08:11 PM, Alexander Aring wrote:
> Hi,
>
> On Fri, Oct 03, 2014 at 08:12:17AM -0700, Owen Kirby wrote:
>> A while ago, we were also interested in porting our ZigBee stack to use
>> the linux-wpan interface, and we came to the same conclusion. The API is
>> missing too much of the IEEE 802.15.4 MLME components to provide support
>> for a workable ZigBee stack. In the end, we wound up implementing our
>> IEEE 802.15.4 driver in userspace along with the ZigBee stack; It works
>> quite well, but one of these days I would still like to port it to
>> linux-wpan.
>>
> mhhh, what do you using right now? The old linux-zigbee kernel sources?
> Or mainline state? linux-wpan is mainline state.
We're just using the mainline kernel without any IEEE 802.15.4 support. 
Our boards are using the AT86RF2xx family of transcievers which we're 
controlling from userspace with the spidev interface. These chips offer 
enough hardware acceleration that the driver runs quite well from 
userspace. The ZigBee stack itself communicates with the AT86RF2xx 
driver using a serial protocol over a pty.

The system looks something like this:

+-----------+             +--------------+ 
+-------------+                     +-------------------------+
| AT86RF2xx | <== SPI ==> | Linux Kernel | <== /dev/spidev0.1 ==> | Wpan 
Driver | <== /dev/pts/XX ==> | ZigBee or 6LoWPAN Stack |
+-----------+             +--------------+ 
+-------------+                     +-------------------------+
>
> But, great I heard the first time that this stack is in some commercial
> product (sounds like it).
>
>> The three major compoenents that are missing from the API are:
>>       * MLME-ASSOCIATE
>>       * MLME-SCAN (and generation of beacons).
>>       * Indirect packet transmission.
>>
> ah indirect packet transmission. Some part of 802.15.4 which I don't
> looked right now at it, because we are far away to support it. ;-)
>
>> In theory, you could cobble something together that does association and
>> scanning from userspace with a raw socket, but there would probably be
>> enough hacking necessary to get it working correctly that it would be
>> much cleaner to implement it in kernelspace with a netlink command.
>>
> Yes, this should something like mac80211 association/deassociation. Like
> 802.11 this is part of MLME. The kernel implementation for looks like
> [0]. This can be triggered over netlink. 802.15.4 should have similar
> things.
Yes, there are a lot of similarities with IEEE 802.11, and I think the 
wireless LAN interfaces have turned into a fairly good example to follow.
>
>> Indirect packet transmission is something that needs kernel support (and
>> sometimes even hardware support), since it relies on fiddling with the
>> ack packets.
>>
> Ack handling via kernelspace... sounds problematic. I need to dig into
> this how the phy could handling this ack handling, if possible.
Indirect packet transmission relies on setting the frame-pending bit in 
the header of the ack packets. Ideally, this bit would be set depending 
on the source address of the packet being acknowledged (which would 
require some address lookups during the ack turnaround period), but it's 
also perfectly valid to set the frame-pending bit globally for all acks 
(though, it's less efficient to do so). Most of the transceivers we've 
seen only allow you to set the frame-pending bit globally.

Doing this without hardware acceleration has often proven to be 
challenging, since IEEE 802.15.4 specifies some very aggressive 
turnaround times.
> I don't know if you already know about it but I try to make a full
> rework of mac802154 and ieee802154 [4]. The current netlink interface is in
> a very awful state, kernel headers which should be uapi have some
> "extern" keywords, etc... don't know why. In the rework I will mainly
> orient to mac80211/wireless stack, to have the likely frameworks.
I've been mostly lurking on these mailing lists, since we opted not to 
use the linux-zigbee framework for our boards, but I appreciate all the 
hard work you've been doing to try and get things into a workable shape.

Thanks,
Owen