 Okay. So, hello everybody. So, great to see quite a few people around here. I was somehow expecting most of you guys already on the way back, so it's quite good to see. I will talk to you a little bit about 15.4, so 820.15.4, the wireless protocol, and also about 6.0.0 point, which is an adaptation layer, and how you can add that to your embedded links device. So, let's get started. So, I'll start with a little bit of an integration here. Then I will go into the details of the Linux WPN project. This is basically all the software behind side, which is kernel side and user space side. And then I will have a look at the hardware that's currently supported by our project and other parts that are not supported. And I got a little bit into the hardware configuration. Luckily, these shits are really simple to connect to your hardware, so that's not too difficult. And then I will look into the configuration, so that you need to do to bring it all up and make it working for you. And then I look a little bit into the communication with other operating systems, in this case more for the, let's call it IoT space here. And so, for example, Riot and Contiki, which are devices for microcontroller. And yeah, something really need to communicate with here. Okay, Modation. And so, 15.4. This specification is from IEEE. It was defined as for low rate wireless personal area networks. By now, they completely skip the personal area part of it, which makes a lot of sense because it's not really used for that much. It's not only low rate, but it's also for low power. So, if you have a configuration with an MCU, it's not a filling system, but if you run something like Riot or Contiki on it, and you have an MCU with a transceiver, you can have times where like, maybe months, maybe even a year with a corrective disciple on a normal battery. So that's quite good, compared to something like Wi-Fi, for example. And obviously there are some downsides of that. So the MTU that this network is using is like only 127 bytes. It is quite challenging, if you want to run IPv6 over it, but I'll come to that later. And the bandwidth is also not that fast, but normally it's okay because you're normally just doing types of machine-to-machine communication. You're not going to stream HD videos on YouTube or something like that. So that's okay. And sometimes this is confused with Zipi. That is because Zipi is the same fire neck layer from 800 to 15.4. So they put other things on top of that for the routing and everything and so on. So that's kind of a, yeah, confused thing sometimes. So 6-Lopin, basis on top of these IEEE standard and 6-Lopin itself is specified by the IDF. So the guys who brought us the most of the protocols we're using in the Internet today, they started 2003 with the specification there and then it's still ongoing. So I mean, the main things are done, but they are always smaller items. They are going to specify. And as you can see here on the green part, 6-Lopin itself is really just an adaptation layer sitting on top of the neck, but below the IP layer. So that's not really fitting into the ISO model, but that's really just making sure that the adaptation is there. So why do you want to have this kind of 6-Lopin adaptation? I mean, we won't use IPv8.6 over this kind of networks, which is a bit scary when you first start thinking about it because, I mean, an IPv8.6 packet is 128-byte, or could be. And then you have the empty one on the other side of just 127 bytes. So that really also breaks down to having a real problem with the headers that are normally in place if you want to transmit over this wild of links. So that's a bit of a worst case calculation. And you start off with 127 bytes, and then you have the maximum frame header itself. So if you go for an extended address and you have all kind of options enabled, then you're already down to one or two bytes. And then you want to have a link layer security enabled to make sure that even on that layer there's nobody e-strapping on you. So you want the strongest encryption there and the strongest authentication. So again, 20 bytes down. So you're down to 81. And then you have the normal IPv6 settle. You would use that. That is, again, 40 bytes. And then you would even use something like UDP. And then you have 33 bytes for a payload. And that is out of the whole package. I mean, that's like 25% you can get out of this one package. So that's really, really bad. Okay. So what is the solution here? So the ITF got ahead and specified the 6.0.1 annotation layer to make sure that it's going to reuse a lot of the stuff that's already present in layer 2. And you can use that in layer 3 and IPv6 in that case. And they also start to delete a lot of things that are normally present in the header but are not used in this kind of network. So that's helping a lot. So in a really good situation where you just do link local communication, you could go down to a header size of just 6 bytes compared to the 48 bytes you normally would have with IPv6 and UDP. That's the ratio is a lot better in that case. You can see all the details here. So you still would have the frame header obviously and the security header. But the 6 bytes is that what you condensed really the IPv6 stuff here. You could even go down and if you know that all the application layer protocols you are using are really doing checksumming and everything and you're really sure that that is all fine, you can even delete that one. It's not recommended. So that's not what we're doing by default but it could be done. So why would we do that on Linux? Because most of the people I talk to say that they only would use that on my controller boards and really small things. On the other hand you need some kind of gateway or something like that that actually connects these kind of nodes to the to the wider internet or to your local network or something like that. And that is really where this comes into play. I mean there are all these platforms that are already running Linux or access points and all the other small plastic boxes in your home or we have support for that. So the idea is to really have full support for that in the main line kernel and then you can really just add a bit of hardware support and some transceivers and then you can mostly run it out of the box. And some examples there are the Google on hub access point. They already have a 15.04 transceiver hardware inside this thing but it's not enabled just yet. I mean they have support for or they have plans for that as far as I understand it but they don't have it enabled. And then there's the CR40 board from E-Virgination Technologies which is kind of aimed to be an IoT hub in the home. That one also has a 6.0 15.04 transceiver directly on the board. And then there's also the yesterday I learned there's the Bigabow in Air which is a kind of strange version of the Bigabow from a Korean company and they added 15.04 transceiver and some other bits as well. Research here. Better? Okay. Okay. So the project itself I mean it was already in 2008 some people at Siemens started these at the point they called it Zippy which is kind of confusing for a lot of people. In 2012 the main line effort started for that so and by now we are doing all the work directly into the main line kernel. And we also renamed the project to make it a bit more clear that we are not related to Zippy here. It's a bit of a problem because the Zippy aligns the specification that's available there. You're not able to combine that with the DPL of the kernel easily. I mean you can do some parts in the kernel and do the rest in user space. You might be able to do that but we are not having any idea on any plans for supporting Zippy. So if anybody wants to do that they are free to do but it's not our agenda. And yeah it's a normal kernel development model. You just post patches to the main list discussing there and then they're getting applied. It's a really small community so there are only like two core developers and I'm one of them but I'm really only spending like 10 or maybe 15% of my time on that. And the other one is still a student so right now he has a lot of time to work on that. Not right now but he had a lot of time and maybe we'll see when he's going to get a job how much time he will have left for that. Then we have a few more people that are actually working mostly on the driver space so to support their own hardware. We have almost 100 people on the main list so there is quite some interest and we have normally like 33 people around on ISC. So there's interest in using it but not that many people that are actually working on it. Yeah so the support we have right now is we have a variety of drivers for the different transceivers that are out there. Most of them are soft Mac drivers so that we are doing the whole Mac software stack in the kernel itself so not on the hardware. There are hardware Mac transceivers as well. We support one of them or one is in the process of being supported and we really need to do a lot more work there to get more of these devices into the kernel. We have full support for fragmentation and reassembly for 6Lopin. That's in the old RFC that actually started that and then we have support for the IP header compression and the next header compression for UDP that have been the examples I've shown before. That's in a newer RFC from there and the same stuff is actually also used by Bluetooth by the Bluetooth subsystem because there's also a 6Lopin or by Bluetooth specification from the ITF and there's a lot of other link layers that are either already specified or in the process of using 6Lopin on top of their link layer. There's work on going for DEC, there's work on going for MSTP and some power line communication things and so on so that's really a lot of things. But only Bluetooth and 1504 are the things that are supported in the Linux kernel so that's the only things we are doing there. The support for link layer security which is working but hard to use from the user space perspective because there's no specification how you do rollover of keys, key handling and all the other things. So what is there is the basic plumbing to get the keys into either the hardware or just do it in the kernel side and encrypt the frames and decrypt them but all the handling on top of that is really not there so that's kind of problematic. Here they're testing against other links instances and we're testing against Riot and Contiki. It's a really active project in terms that we are changing things every kernel release if you want to try it out really aim for a new kernel. I know that's sometimes difficult on embedded ports so 4.1 is something we can actually live at with everything before might be problematic. So the current kind of development laws we are working with right now there are these here 40 I mentioned that from the right side down here and the driver for that is in the process of being merged it's not in there yet. The most commonly used hardware platform with the Raspberry Pi together with an open lab shield so that's just this small black thing sitting on top of that. So this thing is just a little bit of extra hardware you need there so that would be basically what you could add to your own board. What I do for example is that I have various Raspberry Pi sitting on my desk and then I have the different transceivers just wired up to the Raspberry Pi because you only need SPI and some other GPIOs there. What you need so on your embedded hardware is support for device trees so if you're running a not-of-tree support for your for your board some some BSP or something without that that might be a real problem but I hope by now that all the embedded boards that are kind of supported even by where no BSP or something have support for the device tree. If you want to go with USB that's also possible I mean might not be the thing you're aiming for but it's really convenient if you want to do the development on your laptop or even just put it in a box that is completely main powered and you want to don't want to have to hold all the hassle and adding a new board to the system. However there's one USB stick over there there are some more but that one here is the best we are supporting right now that's open hardware so you have all the stuff available the firmware is also open source you can even go and hack around on that one. We just did another run of these devices so you can buy them again because they haven't been available for like three years and the yeah it was a bit of pain I mean the original also who did that they did a run of like 120 devices and they sold out at some point and nobody really had interest or the the capacity of of doing that I mean not the capacity of doing a new hardware run that's okay but doing all the billing and selling and all the other things is really complicated so I finally found a company who gladly did that for us so they are now selling them again. Yeah hardware side so what you need on your embedded board if you want to add that it's really simple so you need an SPI port and you need maybe some additional GPIO pins that's basically it it can go down to just one extra GPIO pin for for an interrupt handler for example to just make sure that you're now when there's a packet coming in it could be more depending really on the hardware and what you want to do with that there's an example on the next slide and then you can show us between completely ready made modules that are available you can just hook that up or you can completely integrate it in your own design if you want to have it directly on the PCB or whatever so then you can mostly go with the reference from the from the hardware manufacturer and then go with that. Oh yeah I mentioned that before you can go with those USB maybe even only for prototyping or something that helps but in the end product that might not be what you want to do. Yeah so I mentioned that device pre-binding so all the drivers we have have device pre-bindings the example over there don't know if you can read that so it's really basic I mean you can see though that's just a compatible matching over there though that would be for an admiral transceiver and yes the the SPI speed the clock speed and then you have the SPI port that would be zero in that point of the register and then you have one GPARO being for the interrupt handling and here you have some more GPAROs for this transceiver for example so you have an pin to actually reset the the hardware and one for the for the sleep state I don't know how much we are using that but that really depends on the different transceiver hardware that's available so as you can see that you can really easily add that to your existing hardware designs so the transceivers we support or the drivers we have right now a lot for the for the admiral transceivers they have one for microchip as well we have one for analog devices we have one for TI and the AT USB that's the USB dongle so that's it's actually an admiral transceiver on the thing but there's a different communication because it goes over USB and we have firmware support there's the panning driver for the Cascoda that's the ship that's on the CI40 boards that's ongoing we are yeah hopefully we are getting that in the next weeks or something then there's these XP devices which are kind of problematic to support because I mean on the one side there are hard mac so they're doing a lot of stuff inside the firmware of the of the ship itself and one way to communicate with them is over AT commands which is really ugly I mean if you want to do a drive I mean from the user space it's fine that's really nice you can just have an exterior interface and do it all in user space you're good with that but if you want to integrate that inside the kernel with the mac layer there that's a bit tricky but there's also versions which have some kind of library API and there's a driver out there I never tested it I think it's bit rotted by now but it could be revived so if there would be interested interest in that could be done I guess yeah so the USB thing I mentioned yeah well that's big so that is just an overview I mean the slides are uploaded so you don't really have to go through all of that you can just download them and have a look I just want to give you guys an overview of what kind of stuff we are supporting and what kind of these transceivers are supporting so this column here would be if you have a driver for that so most of them are covered I mean some of the drivers obviously support more than one transmitter a transceiver that would be for the atmosphere for example would be the case and then you can see if it's on the 2.4 gigahertz band or if it's on the sub gigahertz band which is kind of problematic because it's not easy easily usable everywhere so but you can go with that if you want this error that means automatic retransmission that's a hardware feature that's quite quite useful because the timing you have to send out an egg which then would trigger a retransmission or not because it's missing it's really really tight timing and we are not easily able to handle that in software on the next side I mean I hadn't tried this pre-emptive patches or something like that so I really I could look into that but the hardware normally has some extra support for that so acceleration for that once you can really use that if you don't have that that might be a bit tricky for example the CC2520 from TI they don't have that which is completely fine on when you're running it with a mid-time OS on some mic control or something like that because you can just emulate that on the next side that's a bit tricky and then on the other side you have just the specs they are covering there's just what versions they are supporting and whatnot and for example the 15.4G over there that's an extension of the original specification that gives you a bigger MTU actually so that there are specifications that regard as well and we are not really supporting that well right now so that's mostly because you don't have the hardware around to test it actually if you just want to start a little bit and get something started maybe then while you do the software support and the hardware guys are just ramping it up and getting it extended you can already start with just a virtual driver just really a fake Lupec driver we have there really similar to what the hardware simulation driver is from from the wireless group it's really great for testing you don't have to have all the devices around and you can also do some tricks with it like having riot or open sweat as some completely additional stack running on top of this virtual driver so that means that the whole max stack from these different operating systems can really run on the Lupec drivers so it's really nice for testing and so on not really that much for for production yeah so you can see you just load the fake lv module there and then you just add the number of devices as an option and then you're normally done so once you have these hardware supported uh hardware added to your device you really want to start you need to configure it at some point and really make sure that you can communicate with other devices out there so what we have there is the the counterpart of the kernel support we have is the WPN tools so and that the main binary there is the IWPN tool that actually does all the configuration that's really also quite close to the IW user space utility from the wireless group so that's not too far away the net link code actually is also borrowed from their side so what you do there is you can configure the the five options you have on that receiver and you can configure whatever mac layer parameters are available the basic things you have to do to get anything working is to configure the the pen id and the the channel I mean pen id might you can even might drop that but the channel is something you need to make sure that they are really can communicate to so 504th does no channel hopping or anything so really set a fixed channel and you make need to make sure that the other device on the same channel so if you want to have like a bit more a poor man's frequency channel hopping you need to make sure that you have an upper layer that actually informs all the nodes that you're searching channels and stuff like that so but that's nothing that's in the lower levels there um yeah you can set a short address you can power settings and stuff like that so frame retries is also I mentioned that before how often you would retry to send a frame to a node and if it's before you actually you report an error or something like that so yeah so the packages are packaged by some distributions some are a little bit behind and some don't have support for that so if you're interested in helping with that that would be cool if not compiling it from source is really easy so they are the only dependency we really have is the netlink library that's all so once you have the the basic stuff set up you do need to do some testing or you get to see if this device actually can talk to each other and you normally want to do that before you start with the whole ip version six stack on top of it so you what you can do is we have a small utility which is kind of a ping utility on the 15.4 layer it's not the full feature you would know from your normal ping utilities but it's a good start actually so you need to run so the daemon on one side because that's not something we can inside the kernel and the the protocol is not specified or something so we need to have on the other side have a daemon running but that does nothing else but getting all the frames and then sending the same stuff back so the logic is inside the client here anyway so you can just go and ping the other side have different different count or the sizes and stuff like that so you can really do some early manner measurements as well there so the device bring up if everything is right with your device 3 configuration and all the other things are working fine the wpn interface shows up directly um after booting and from there you can go and see if you want to use the six low pen on top of that and configure it so if you go from up to down here the setting the first down for low pen zero would only be the case if you configure the device before normally would not for the first boot up it would not show up um then you set the device down then you use the um the iwp and utilities here to set the pen id and then you are setting the channel as well that would be channel 26 here the zero there's just a page so um at some points there have been more frequencies available for this specification and they started to paging the different frequencies here so that looks a bit off there but yeah normally you really just have to zero that's really seldom that you have a receiver that does something more yeah and then the you have this line here which is actually the meat if you want to get six low pen on top of these interface going so that actually says that the type is low pen so and then you get a new interface called open zero and um yeah you just set the interfaces up and that means if you are doing any um second interaction or communication over that one it would go plain to the 15.4 layer and if you do anything here that would be diode um ip version 6 communication so you really use complete normal um ip sockets for version 6 and you're done um for more debugging or just um to see what what our device are communicating and stuff like that we also have support for monitoring interface this permissions mode um in this case you would just delete the interface that's already there and bring it up again as the monitor type you can view it at the end and then you can set the channel again and bring the monitored interface up and then you can use wire shark, TCP down or whatever you want um on that one and as I said there's no channel hopping involved so if you really want to scan around what what kind of communication is going on in the place where you are at the moment and you can change the channel in the background so that's what I normally do you can just keep wire shark running and then you're on different consoles you'll change the channel and see if something comes in there okay so um communication with other operating systems here I need to speed up a bit here um so there's riot um they self uh say they're the friendly operating system for in terms of things they are lgpl license um they are actually quite friendly so all the people we are we are involved with them it's really nice to you can talk to each other we see bugs in the implementations of the other testing it out and so on that so that's quite good going on there they also have um testing against Linux WPA and in their release process this is quite a nice thing so make sure that it actually keeps working then there's contiki which is a lot older and kind of the the parent of all kind of operating systems that are now in the internal sync space here um the problem is it's a really fragmented project and there's a lot of folks out there either commercial or academic or stuff like that and it's really hard or suddenly happening that they are merging the stuff back I mean nonetheless it's really still an important operating system there's the work going on there so that's also something we are we are testing against so another famous table here um as you can see that the basic stuff that something all of us are supporting like data and act frames are being um communicated something that is not supported on on all of these systems is beacon and command command frames the thing is why we don't support that is that for six low pen you don't need it at all you need that if you want to do real management of an 15.4 network or for stuff like zigbee support or something like that there is where you need beacons and mac command frames and stuff like that there we still plan to support that but there's really no was no priority to do that um link layer security that's something we support and contiki support and we had some initial testing between these two as well riot does not support that yet that might change in at some point um and again fragmentation um and stuff like that header compression um that's all supported by all of them um yeah there's ripple which is a rooting protocol for these kind of lossy networks um on riot and contiki that's directly into the operating system on the link side there's a user space um daemon doing that that's called unstrung there's also a kernel implementation for that but these patches are really outdated i need to go back and talk to the author if he's still interested in getting that into the kernel or not but that's a complete different story yeah there are other operating systems as well that support this kind of protocols there's embed from arm um i tried to look into that but it's completely closed i mean embed or as itself it's open source so most of it but the networking stack at least the parts i'm interested are completely closed so they even have the object files inside the the git repo so there wasn't really nothing for me to test again so check so there's also the file um they just recently switched to a complete they started with the contiki networking stack but they now completely did a rewrite there and they have actually really good support for all kind of beacons frames and macrame frames and stuff like that so that's something i need to test against have some hardware at home that actually should support that i just need to find the time to do that and there's open thread from from nestlets um which is an open source implementation of the thread protocol which is a complete vertical stack using 15046 flow pen but a lot of other things on top of that so um that's something we for example tested with with the virtual drivers we had and we try to talk to them and find out if there's any any chance that we can work a bit together a bit more closely but um there's really not that much we have in common i mean that's friendly from both sides so there's no bad blood or something but they really want to make sure that their stuff is in one central piece and they keep it running in one uh yeah in one piece and not um finding good interface to to act with us so we we need to figure out if there are some some ways for that um yeah a bit of a lookout here uh the missing parts mentions that beacons and macrame support that's something i need to work on um we need to have after we have that we kind of coordinate the support in the in the uh user space utilities and even scanning for networks and stuff like that um but really urgently need is um support for hard mac transceivers so that's something we really need to improve on within the next few months or something because that really blocks a bit of hardware support and that's annoying yeah and then there is other things different header compression techniques are still there and then we need to find out what kind of information to need to expose to all kind of routing or meshing protocols that are using that i mean simple things like a qi or um asses i or something like that that is one thing but also like statistics how many packets have been transmitted over the sling or how many retransmit has been failed and stuff like that so that's something we need to expose somehow but if you are going to do an um interface with your space you really need to be think carefully about that because we need to support that until the hair freezes over on the north side so that's something really you need to make sure for for yeah and just to sum up here um running with 504 wireless network on top of linux is really easy even right now i mean they are missing pieces and stuff like that but just for getting the ip version 6 socket interface on top of these things and then communicate with some smaller sensor device and stuff like that that's already there that's all working um yeah kernel on tooling support is there the most likely scenario it is used in right now it's like a gateway or water router um you could go and have that as your small node even even that i mean i know that intel has been able to completely squeeze linux kernel and bluetooth user space utility everything in within one megabyte so that's something if people want to try to run for that so that might be something you can even run on battery for a longer time yeah that would be from my side so i'm open for questions now go ahead so the addresses are actually um coming from the layer 2 address of the hardware so there are like the automatic address generation ip version 6 you could use dhcp on top of that if you want i mean that's really really up to you you have a normal ip version 6 link but the generator address you get in the beginning that is actually coming from the mac address being auto generated coming up so but on top of that you can use dhcp here i see yeah we actually haven't really thought about that that much i know that at least one or two transceivers that support i know that there's at least one or two transceivers that actually support multiple tenides yeah um on the on the kernel side we haven't really looked into that so that's something we you might actually i don't know right now if it would work or not but i would suspect not at the moment so that's really we need to test it out and find out what what is locking and whatnot so i'm not against that it's just something that we need to look into there was that there yes i never did that um there are different transceivers that are not 15 or four itself um but you can run the mac over it the problem is just something like the hardware serrated features like the um the sending out the acknowledgement frames and stuff like that that is something and we rely on the transceiver hardware on so that if you ignore these parts you might can do that i know that for example um arrived on contigua i'm not sure they also have support for some ti devices that are not 15 or four compliant itself but in just an RF transmitter and they run 15 or four hours so on the next slide we never did that because we really rely on some of the hardware features you could try that out i mean in the end for us it just means having a transceiver driver a hardware driver that brings the stuff in so you can try that out if you want um but i never did so oh there most yeah most of these border router things that are just a small thing they normally run something like contigua it's just a forked version of contigua on it i mean there are different ones i know that but um so that's something we test against there are the border router things for this wooden thread for example that's the same stuff that's something we tested a little bit again i mean we can't test against the whole thread state because there's a lot more but just the basic things to get frames and i think so that's what we did we don't really have tested against all kind of hardware so things running out of time okay yeah so i'm around so um