Profile cover photo
Profile photo
Alexander Aring
92 followers
92 followers
About
Alexander Aring's posts

Post has attachment
Driving old vw beetle...
PhotoPhotoPhoto
05.03.17
3 Photos - View album

Post has attachment
Hey +Microchip / Atmel,

I am maintainer of the at86rf230 driver for the IEEE 802.15.4 subsystem and more... This driver supports YOUR rf212, rf231, rf233 transceivers!

Apart of the SPI variant there exists an open hardware which made with some closed hardware parts, Atmel MCU and Atmel 802.15.4 Transceiver an 802.15.4 USB Dongle. See this link: http://downloads.qi-hardware.com/people/werner/wpan/web/

The atusb is supported on mainline Linux. Later on I also got some RZUSB stick. We name it so far RZUSB stick, because it was part of your ravenrz 802.15.4 wireless kit. It has basic functionality becuase it's the rf230 transceiver.

Anyway, the Problem is now... people hit our project which has the NEW Zigbit USB Transceiver! I mean such device: http://www.mouser.com/ds/2/268/atmel-42194-zigbit-usb-stick-user-guide-1065684.pdf

We from the linux-wpan project, see http://wpan.cakelab.org/ , can port also the atusb firmware to your ZigBit transceiver. So it would run on Linux out of the box, if people flash the atusb firmware.

Currently I need to tell everybody that we don't support such stick, but we could if somebody port the atusb firmware on it.

So my question, maybe +Microchip / Atmel can provide us some ZigBit USB Transceiver for free that we can work on it?

I hope this G+ post get's the right people to get such ZigBit USB Transceiver that we finally can add a new supported 802.15.4 Transceiver to the Linux Kernel. Which helps at the end to get 802.15.4/6LoWPAN running on Linux.

So sharing is welcome.

- Alex

Third day of the IETF 96,

The first session which I visited was ACE:

https://datatracker.ietf.org/wg/ace/charter/

I don't stick into the cryptographic stuff, but these are things which need to be done. What I really mean is: I didn't understand the most stuff which was explained there. :-)

The last session was about the ROLL working group:

https://datatracker.ietf.org/wg/roll/charter/

I don't stick into that as well, but I believe I understand more about it than the topics in ACE.

As first +Cenk Gündogan  presented his work about optimizing DIS
"DODAG Information Solicitation" messages in RPL which seems to be used a lot. So far I understand he has some ideas which reduce multicasting of DIS messages and payload.

Then +Michael Richardson  talked about the handling about IPIP with RPI as IP option which sits after the first IP Header. This handling is a reaction only to the 6man working group about their change that the Hop-by-Hop IP options doesn't need to be parsed if configured so. I reported about that change in an earlier g+ post.

Michael also has an RPL open source implementation:

https://github.com/mcr/unstrung

I know there exists some mechanism in RPL which needs to be done inside the kernel if you want to use IPv6 stack of the Linux kernel. So far I know these are the following mechanism/handling: RPI IP option which I mentioned above, non storing mode and 6LoRH (compression format for the RPI IP option). And I am sure there exists even more.

After visiting the ROLL working group I can't wait to hack on unstrung. I know, when I get more familiar with the code and the standard, then I can't stop working anymore on this until all things which are outside are not implemented and may wants to start my working on that after my master thesis.

Also Michael told about "The DODAG root knows everything of the network". So far I understand the RPL builds "logical" a tree, the DODAG root is the top root node. On such device it would be great to running Linux on it.

Post has attachment
Second day at the IETF.

The first session which I visited was about the 6man working group:

https://datatracker.ietf.org/group/6man/charter/

So far I understand they try to fix/changes or making simpler IPv6 standards. Also they try to fit they standards for upcoming 6LoWPAN RFC's.

For example to generate stable IID's. Stable IID's are the last 64 bits of an IPv6 address which based on the mac address. This is used for example by SLAAC (stateless address autoconfiguration). Non stable IID's also exists and I did finally understand some code parts of the Linux kernel which I detected by hacking the short address support for 802.15.4 6LoWPAN. Non stable IID's are e.g. temporary addresses:

http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/ipv6/addrconf.c#n2577

Which tries at first to add different ways for non stable IID's, if there are no non stable IID's a stable IID (based on mac address will be given).

So in this working group there as a discussion about to uniform the stable IID generation into one RFC. Because every RFC for IPv6-over-foo describes on his own how to generate such stable IID.

https://tools.ietf.org/html/rfc7217

So far I understand all RFC's gets an update to use this method. This would be also interested for the Linux kernel because the current code is per net_device->type:

http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/ipv6/addrconf.c#n2091

Having a generic method here would reduce some of the code size there. I am not sure how the backwards compatibility is given here, but I think "How to generate stable IID's for IPv6-over-foo", the RFC 7217 will be the future method to do it.

Another topic was about "Header injection" while forwarding. That means somebody adds an additional header not on the source node. E.g. some middle node adds a IPv6 extension header and doing IPv6 in IPv6. This would break some PMTU discovery, which is used by estimate the maximum transmission unit over the network.

The last topic was about a change that a "Hop-by-hop Option" field which is a IPv6 Header option (something like additional information for the IPv6 header) must not parsed if configured so. Currently all nodes need to be parse this header. I suppose the idea is to having some speedup in the internet to not parsing this header always, but changing this would maybe break other current mechanism.

The end of the day I visited the Constrained RESTful Environments working group:

https://datatracker.ietf.org/wg/core/charter/

which doing the CoAP protocol. It was the discussion about the right term of adding something "coaps://" similar like "https://" if doing a DTLS connection to CoAP, so far I understand.

Also there was a presentation about WebSockets and WebRTC to putting these things into CoAP.

CoAP will more and more adapt things from the current web mechanism and make it for constrained applications which we have in the IoT world.

The last working group was about "Thing to Thing" communication:

https://datatracker.ietf.org/group/t2trg/charter/

Which talks about very high-level web based mostly CoAP scenario. For example you could develope your IoT application with a javascript similar language e.g. JerryScript:

https://github.com/Samsung/jerryscript

which is very easy to use and also some kind of thing which is used everywhere in the current web. Over jerryscript and CoAP it's very easy to get your Thing into the Internet.

For me it looks like they do the Web again for the Internet of Things and care about constrained environments.

Today is the third day and I am not feeling well, I think I got the conference virus... :-(

Post has attachment
News from IETF.

I finally met +Michael Richardson  which is a really cool guy. We had a long time discussion with some "Berliner Currywurst" meal (inclusive beer) at the hotel bar. We talked much about 6LoWPAN and I he let me understood what we need to support in Linux kernelspace. For example the RPL, which needs to handle a IPIP (IPv6 in IPv6) with RPL IP Option, I googled I think it's described here:

https://tools.ietf.org/html/rfc6553#section-3

So, this Option need to be added somehow in kernelspace and we have no support for that right now.

Also we talked about possible topics for me to handle them in my master thesis. There exists so many ideas what I could do, at the end we talked about MLE, which has nothing to do with kernelspace stuff (not so much, than I currently doing most the time). But it is a topic which could be very useful and openthread implementation already use some parts of that, which I could test against it.

https://tools.ietf.org/html/draft-ietf-6lo-mesh-link-establishment-00

https://openthread.github.io/openthread/de/d97/group__core-mle.html

I never did some userspace stuff yet for 6LoWPAN use cases, but I think it's good for me to not doing kernelspace stuff all the time. :-) ---

The first IETF day was cool, I thought such conference would have more commercial stuff everywhere with some booth at the conference rooms. But this isn't it, you feel that all people which coming there wants to make the internet better.

The first session which I visit was from the "6lo" working group and I finally understood that the "6lo" working group makes the "IPv6-over-foo" standards, where foo is your link-layer. This working group is identically with the "6LOWPAN GENERIC" branch inside the Linux kernel which combines all the shared mechanism which every "IPv6-over-foo" specified. For example IPHC, NHC compression formats. See:

https://datatracker.ietf.org/wg/6lo/charter/

http://lxr.free-electrons.com/source/MAINTAINERS#L153

I wasn't aware of that and did the 6LOWPAN GENERIC branch without knowing that there is a working group for all "IPv6-over-foo" outside. Good to see that doing this branch was the right decision.

In this session there was many presentations about other link layers for example NFC or BTLE.

NFC is interesting for us because there exists already NFC support inside the Linux kernel. Because the GENERIC 6LOWPAN branch it should be easily to add a 6LoWPAN handling to that.

About BTLE, there exists a new draft for running 6LoWPAN over the new BTLE mesh stuff, see:

https://tools.ietf.org/html/draft-gomez-6lo-blemesh-01

I didn't looked into that right now, but we have already much issues with the non-mesh BTLE 6LoWPAN inside the Linux kernel and so far I know there exists now hardware yet which supports the new BTLE mesh stuff yet.

The third thing which I already heard about was the 6lowpan over BACnet, they name it so far I understood "MS/TP" but there exists two mac layers where one of them is BACnet. There was some little status updates for the drafts, but I never worked with BACnet before. Running 6LoWPAN on BACnet would require a PHY/MAC subsystem inside Linux kernel which doesn't exist yet.

The second session was about "6TiSCH" working group:

https://datatracker.ietf.org/wg/6tisch/charter/

It's about 802.15.4e standard which I am currently not expert on it. The TSCH mode is about channel hopping and then you need to deal with some "cells" handling, which are some slots to send/receive data. So far I understand.

In Linux kernel this becomes maybe problematic to support such channel hopping feature, we need at last real time support or moving right parts for mac handling to a co-processor which can do the job besides Linux.

The last session was about the LPWAN working group:

https://datatracker.ietf.org/wg/LPWAN/charter/

This working group is about Low Power Wide Area Networks and the complete room was full, I didn't got a seat to sit. There exists a lot of Link-Layers like LoRa or 802.15.4g and all wants to run 6LoWPAN over it. A wide are network has ranges about 15-40 km and some kind of low power is included as well. :-)

Well, there was some guy at the linux-wpan mailinglist before to support 802.15.4g (because atmel has already a transceiver for that, see http://www.atmel.com/images/Atmel-42415-WIRELESS-AT86RF215_Datasheet.pdf ). On the mailinglist we figured out issues with different MTU handling between 802.15.4 (legacy devices) and 802.15.4g. So far I didn't heard anything anymore about supporting 802.15.4g into the Linux kernel, well we need to see what the future brings.

This was my last session of my first day at the IETF. I am getting more and more scared about that what's outside there and how much work we have to implement everything inside the Linux kernel. Well, we need to see if we really wants to implement everything what's outside there.

Last day on #RIOTSummit,
I talked with people from +Nordic Semiconductor  about the BLE 6LoWPAN mainline implementation and what's wrong with it.

In summary: It's broken but I have patches to make everything better.

I explained my work and they was interested to get the new things into mainline. I will try to get my fixes fast into the mainline kernel. Maybe this becomes a little bit difficult because the new implementation will not work with the old implementation and the +Zephyr Project isn't compatible with the new version as well. To see that Zephyr (a Linux collaboration project) has no compatibility with Linux anymore sounds weird and all people behind both projects doesn't really want that. :-)

What I see outside in the Open Source World e.g. RIOT-OS, is that there exists a pull request to adding BLE 6LoWPAN to RIOT which is bug compatible with the current mainline version. So I am more on that track to getting BLE 6LoWPAN fixes to mainline really fast, otherwise more implementation will testing stuff against current broken Linux BLE 6LoWPAN.

Maybe I want to try to get some ugly Kconfig entries into BLE implementation "USE BROKEN 0.1 VERSION" which use the old stuff again. Of course, default disabled.

Another people from kickstarter project Ci40 https://www.kickstarter.com/projects/imgtec/creator-ci40-the-ultimate-iot-in-a-box-dev-kit from +Imagination Technologies 
presented me their IoT-Kit which was very nice. They told me that they want to send Patches the next days for they 802.15.4 transceiver which they using. This is one of the rarely 802.15.4 HardMAC transceivers outside. Well, we don't have any supported HardMAC transceiver yet but we should be prepared mostly to handle HardMAC transceivers, because the 802.15.4 subsystem is much oriented according to the 802.11 subsystem which has the same paradigm to supporting SoftMAC and HardMAC transceivers. I think with this transceiver the 802.15.4 subsystem will make a big step forwards to handle SoftMAC and HardMAC transceivers. For example, we could use the HardMAC transceivers to test MLME-ops implementations from SoftMAC side.

At the end of the day, the IETF Warmup, much beer and food which tasted very well.

The next day the IETF Hackathon started, cool thing that everybody could present shortly in a ~3 minutes presentation about their work.
The lunch was good as well.

Post has attachment
Greetings from #RIOTSummit ,

Stefan Schmidt, one of the linux-wpan developers, presented about "Introduction to Linux-wpan and Potential Collaboration".
He talked about collaborations between RIOT-OS and Linux to get both open source projects straight forward to reach our final goal which is a bugfree and RFC compliant implementation of 802.15.4 and 6LoWPAN subsystems.

At first he talked about the history of linux-wpan project which started from the linux-zigbee project. As next he talked about the raw802154 driver.

To have a nice testing environment for interoperability, I wrote myself the native RIOT-OS 802.15.4 raw driver, which can be found at https://github.com/RIOT-OS/RIOT/pull/5582 .
The raw802154 can be used to reproduce stack interoperability very easy without any hardware requirements.
For example your command-line steps can be provided to your interoperability issue that every user can recreate the non-working setup easily.

At last he compared the current state of supported parts of RIOT and Linux and he explained what he would like to see in RIOT as next.
For example the 802.15.4 security layer which was introduced by Phoebe Buckheister to the Linux kernel some years ago.

The next RIOTSummit day and I like to show some Demo stuff of RIOT-OS raw802154 native driver and new BTLE 6LoWPAN implementation for the Linux kernel.

Pictures will follow soon.

Post has shared content
The Linux Foundation has startet Zephyr, but I'm still not decided if this is a good move or not.

First of all, there is already a variety of other operating systems, with existing communities, for devices in the Cortex-M class: RIoT, NuttX, Contiki, TinyOS, FreeRTOS etc. I'm wondering if they have evaluated them and decided they are not good enough? I'd expect that we aready have enough operating systems for everything, so the world didn't exactly wait for yet another one.

One of the biggest problems in the industry is finding good abstractions for complex technology problems. Linux is quite good in doing so, but with Zephyr being Apache 2.0 licensed, it is illegal to copy Linux code over, of course with no guarantee that every company will play after the rules (remember, devices can and will be closed source). So the Linux Foundation now hosts a project which is not license compatible with Linux, but has the potential for further GPL violation cases.

And last but not least, any new realtime operating system should be developed following a safety process these days. There is no such public process for Zephyr, but are we sure that WindRiver doesn't have one internally, and, as they can take from the Apache licensed code what they like, they won't take the contributions and make sure they will be the only ones with a safety product for this codebase? If I were a contributor, I wouldn't be amused.

The Linux eco system works because companies are forced by the GPL to give back their contributions to the community, so everyone using Linux has the same rights and obligations. That's a good thing, both technology wise and when it comes to establishing a healthy and balanced community.

However, let's see what happens in the future. It's definitively worth a look at Zephyr from time to time and follow its development. 

Post has shared content

Post has shared content
Yes, thank you!
Very big thank you to +Analog Devices, Inc. for open technical documentation and a newly pushed Linux kernel driver for the ADF7242 IEEE 802.15.4 transceiver over the weekend!
Wait while more posts are being loaded