Profile cover photo
Profile photo
Alexander Aring
Communities and Collections
View all

Post has shared content
Neuer spannender Job rund um Embedded Linux gesucht? Das Pengutronix Team am Standort Hildesheim sucht Verstärkung! Zur Zeit suchen wir Linux Kernel Entwickler, Grafik Infrastruktur Entwickler sowie Python/Web Entwickler.

Mehr Details gibt's hier:
Add a comment...

Post has shared content

Post has attachment
+netdev conf​ netdev 2.2 flyers at the debconf17 desk.
Add a comment...

Post has shared content
Originally shared by ****
Thank you, #LWN, for the announcement!
Add a comment...

Post has shared content
Originally shared by ****
Add a comment...

Post has attachment
Driving old vw beetle...
3 Photos - View album
Add a comment...

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:

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:

We from the linux-wpan project, see , 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
Add a comment...

Third day of the IETF 96,

The first session which I visited was ACE:

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:

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:

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.
Add a comment...

Post has attachment
Second day at the IETF.

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

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:

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.

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:

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:

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:

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:

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... :-(
Add a comment...

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:

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.

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:

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:

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:

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:

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 ). 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.
Add a comment...
Wait while more posts are being loaded