 Hi, so my name is Marcel Altman. I work for Intel, and this presentation about the project we've been working on for about a year now, which is a new wireless demon for Linux. So I gave this talk, or a version of this talk, two weeks ago at the System Deconference. I forgot to mention a couple of people that have been working on this one in the background. So it's a bunch of people from Intel that have been heavily working on this. So Dennis Kanzers, who works on it, Andrew has done a lot of contributions. Tim and Rae will work on it, and Matt worked also a lot of extra new kernel interfaces that we needed, or changes to kernel interfaces. So I will walk you through this one during the talk. It's just these guys have been working in the background, so it's just not me, and they've been doing a lot of work to make this project a reality. Myself, I've been maintaining Bluezy since 2004, so that's pretty much a long ride by now. The project is over 16 years old. I've been maintaining it for over 12 years now, and it has been a heck of a ride. I joined Intel OTC, the open source technology center, in 2007. And since I've created Conman, Nofono, Pack Run, and a couple of other projects that I will go through today a little bit, I mentioned them. But when I joined back in the days, we fundamentally had a vision to build something different. So you actually, Linux becomes a more modern connectivity stack and use it for something else. And the vision looked a little bit like this. We wanted proper drivers inside the Linux kernel to abstract everything we needed. We wanted subsystems for everything technology that we have, NFC, Brutus Classic, Low Energy Mesh. Low Energy didn't exist when I started at OTC. Mesh is coming to existence next year. 50.04 existed, but wasn't really used at all, except for some specialized projects. Wi-Fi was around, 3G and 2G was around, LTE came later. So I updated the slide a little bit and said, OK, we wanted the subsystem to break on out, the drivers generic, and then we want to have a connection manager, which we used RodeConment for, bundling these together, and then we have our applications being able to drive them. So that was the vision about nine years ago. And we made a bunch of success in driving to that vision. But it actually looked, when we looked at this one, it looked not really complete. So NFC subsystem, we put in existence. We put a user space demon in there that can drive it. So we can use NFC on Linux pretty easily with card emanation and everything else. Nice and good. Bluezy has been on longer, we did a lot of refactoring to make this work with Buddhist low energy, unified things, make the simpler test cases and so on and so forth. Pretty happy that one as well. Mesh is coming, Mesh is coming also for Linux, so we are really happy with that one. 50.04, we spent a lot of time actually making 50.04 a reality subsystem with break out of 6.0 pound and something else. It is well, but you see there's something missing. We don't really have user space driving it. 802.11 existed, was driven towards moving away from wireless extensions into Config 802.11. We had the W-supplicant on top of it, which you think would fall into the same category as Bluezy and Nerd and actually doing this separation, but it actually doesn't. So it needs a lot of extra code to be able to work as what it's supposed to be doing and it will get into the details on why is that. So what we see there, while we were expecting W-supplicant to fulfill the job of doing the heavy lifting, actually command on W-supplicant is the only one together to actually do the heavy lifting. Everybody copies these codes around, beat network manager being some home run tool in an embedded system, somewhere in the middle of the ocean or something else. The cellular side looks similar enough. It's not completely identical, mainly because cellular isn't really easy to fit in a subsystem since it's a bunch of standards that run on various parts of your hardware. But we got it to the level that we have hardware subsystems for the different manufacturers like back in the days Nokia, Qualcomm, STRX and so on and so forth. And then these drivers made this unified and then Alfonso could just use these drivers. So they have, Alfonso has a little bit of hardware abstraction in there, but that's about it. But it made it nice and clean. So the right side looks good. The left side looks good. In the middle, it's a little bit tricky. So what we hope, what we get to is that we actually can fix the 80 to 11 side. And after that, we're gonna tackle the 15.4 side. So this talk will be about us doing IWD, which is the internet wireless team or INET wireless daemon, that will replace W-supplicant and will be allowing us to actually fit into the vision where we have a tool that actually does exactly what we need to do and it can hook up easily in command network manager or whatever flavor of connectivity management you're actually gonna use. The node manager I put in white here, it's something we will start working next but 15.4 needs something similar as well where your nodes are will be managed and you expose a unified view one way up. So the really important question is why actually do this again? So there's a few problems W-supplicant that we cannot fix and upstream also don't wanna get fixed. First of all, W-supplicant is non-persistent. So whatever you're gonna do in it, it will not remember it. If you looked at the previous diagrams with BlueZ, Nerd or Phono, whenever you configured a network or whenever you paired a device or whatever you did, it got remembered. You can reboot, you can restart. This information is lost. It's fully stateful in that regard so I know what I've done. W-supplicant, you restart it, all the information are gone. That means some other entity has to store it which means for all, for 90% of your service you store this on a level down for the W-supplicant, you have to store this and level up. And they always say, yes, there's some functionality over redo the configuration networks but it's so hackish and problematic that nobody actually uses it. So everybody stores it at a higher layer which makes it complicated since you have an imbalance in how your layers are structured in your system. As I said, or Phono BlueZ, you connect to one network, you put an APN, you put a paired device. It's always persistent, we'll remember it. So ConVan doesn't have to do anything. The other problem is that actually W-supplicant does a lot of work but it doesn't go all the way. You would something, oh, it extracts me from all the details. The only thing I really have to do is find my network and connect to it. You are not really. You have to know a lot of details on how WiFi is done. You have to do a lot of parsing of information elements that come from the network to decide what you do because it's really not giving you any information. It's like, look, read your WiFi specs all by yourself and then figure this one out what you have to do. Which is, look, I just wanted to connect to it and I won't read a 2000 page document to figure out that this information only means that I have to use that passphrase or that I'm using a push button method to actually gain my credentials. These things should be really hidden. And any attempt to actually make W-supplicant is something that actually does any of these things be persistent or has more information exposed got always really blocked because essentially, in not of case, it just hands down what the hardware gives you. So what you get over the interface goes out from the kernel, goes to the supplicant and then it goes to you when you have to do the connection manager. Which goes like, whatever all the previous that I've been doing with this information, the answer is nothing. On the other hand, W-supplicant abstracts literally everything underneath the hardware for I don't know how many different operating systems be it in outdoors, be it Windows, be it Mac OS, be it I don't know what, be it wireless extensions that we all tried to forget and that never existed and have some other support for things that I don't know why and still in there and these abstractions trying to unify everything across which makes a lot of complications when you can't unify things because different hardware or different operating systems work differently. And then it becomes really tricky and these abstractions actually get in your way while being in really great system on Linux where it's used a lot. It has a lot of drawbacks in cases where you actually can't use it. My biggest pain point is with some of these operations it's doing on the hardware because they're not really nicely abstracted. They're doing it in a blocking fashion. It goes really, have you done this yet? Piece of hardware, have you done that? And then it makes a decision. These two pieces might be completely independent have done things differently and we can't really have a system just waiting around and doing something else while just waiting for something to happen. Especially if the interface it's using on Linux is for the other corners where we actually made sure that the hardware reports events as they happen so you can actually pick them up and make decisions based on it. So there's a couple of other issues with this one where it becomes really complicated to work with. Some things we fixed in the past, other things we couldn't fix because upstream didn't want to take this. So at some point if the upstream doesn't want to have your changes then you actually have to do something else. And there's already been forks or forks of WSuplican that we didn't want to take. If you want to fork it then you can also start an on-project. So WSuplican looks a little bit like this. And I don't want to if you carry this around, I certainly don't. So the goal was let's see what we actually need if you want to build this for Linux. And just for reference I'm going to take this diagram to a couple of slides and iterations on what we have done. WSuplican from a simple viewpoint is way more complex than this but it has a lot of complicated things. In the Linux side is you have a soft Mac hardware, you have full Mac hardware. The soft Mac needs a Mac 8 to 11 framework. Config 8 to 11 binds these together and then you have interfaces for Netlink and for wireless extensions. Yes, we're still carrying wireless extensions backwards compatibility code around. That looks rather sane but then it goes to user space. It can use either LibNL2, LibNL3 and if this will be ever in LibNL4 then it will be also have an option to use this one and they have different compile switches for doing I don't know what. It can also alternatively still switch back to wireless extensions if you find some really old hardware or because you like that interface more or have some really nasty hacks in there. And then exposes this to user space in at least four different ways that I know. If it's a control interface with unit socket which is pretty much a bash like interface where you type these things and you might get different strings back on what's happening. Great for doing this programmatically. It's great for a user to do something but programmatically from a demon horrible. And the D-Bus1 interface was absolutely useless. We tried to make this work. We fixed it with a D-Bus2 interface but fundamentally we have to actually get to a third generation where we get things done and where it doesn't swallow states or does something really funky. And I also find lately that they actually have some bind interface before it goes directly over binder and there might be three or four more that I haven't even discovered because the code base is huge. So when we build Conman what we had to do actually to actually get the D-Bus2 interface working we actually had to put supplicant abstractionally on top of this that actually handled all the things that interface didn't give us. We called it G-supplicant because of those G-Lib integrated with the D-Bus or G-D-Bus bindings but it was pretty much we had to put a lot of extra work in there to actually make this fly and then Conman could finally start using it and still had to do a lot of extra work in their plugins or if you compare the size of the plugin when Conman wants to talk to Bluetooth it's like 10 or 20% of what the Wi-Fi plugin has to do which gives us something that's really, really wrong here. So the vision was, let's do this simpler. We need to keep the difference between full max and soft max, so these are on the right side. So we have make it to 11, configure it to 11 and netlink. We don't want to do wireless extensions. They're broken, we can't fix them. Just ignore them, hopefully at some point they get removed from the kernel. Then we want to put a wireless team in there that exposes the D-Bus interface and then we're going to have Conman talking to it. So this is what we thought, okay, this is what we have to do. And that's pretty much where we went, okay, configure to 11, netlink into 11, that's what we want and should be the only API in going to this one. No extra interfaces for something else that should work. We want proper hotplug support, so whatever actually happens, we can actually detect the new hardware comes and goes. Yes, some hardware is built in, but a lot of thing times you have USB dong is where it actually would work. WSupplicant doesn't actually make this work. They hack around this really heavily and hope for the best that they detect hotplug events and every time I look at this one, it makes me really sick. There were a few netlink 8 to 11 features that were documented in a way that's supposed to work. They didn't work this way. We only figured this out while toying with this one. So at the end of the day, I think these ones are all fixed now and pushed upstream so the kernel should be fine. Looking into this one, we realized, okay, we can't use libnetlink or libnl because it's a blocking design. It can't track family changes. So when you actually would do any kind of changes inside the kernel and the family at ease would be changing. You would be out of sudden talking to a different service and nobody knows why. So if you have WSupplicant running and you accidentally try to unload the Wi-Fi driver or the Wi-Fi max layers and reload them, WSupplicant would basically fall over and had no idea what was happening. They might have fixed this by now by just brutefully rediscovering everything, but generic dating works similar in a way that debus works. We actually service gets announced and you can discover them and you can discover changes. So we needed something that can do this as well. With that one realizing, we actually had to go one step back from our IWD vision and say, look, we need something else to actually do first. So introducing that we did a couple of years back, ELL, which stands for Embedded Linux Library, which is pretty much ELIP, but for smaller and IoT devices. So we put in main loops, signal handling, timeouts. Asynchronous IO, done right. We put in strings and hash tables and queues and ring buffers. And also we took the system be hardware database and integrated as well. You will see this later. Why have we done this? We're almost like, yes, we can, it's easy code to do. At this point, this is nothing really shadowing. It's nothing special. That's what you would have to do anyway. Or you picked some other library that would have done this. But since we had the Asynchronous IO, we said, okay, let's put Netlink on top of this one. And we actually put the basic Netlink support and put this in there as well and we included RTNL support in there. So this works really, really nicely with actually having to deal with RTNL and Netlink. That said, Generic Netlink sits on top of Netlink so we put Generic Netlink in here as well and had finally a library that was doing this fully asynchronously and was having discovery and tracking of families correctly. So we could send Netlink messages and receive events and broadcast and multicast really nicely in a really simple way and a nice API. That project is already open source. So have a look at this one. Then we took it one step further and said, why don't we put D-Bus support as well because LibD-Bus has always been bugging me for a lot of things. And systematically it started doing their own D-Bus libraries and said, look, if you put this in there, then A, what are we ever gonna do with K-D-Bus has a second implementation and we can nicely test this. And we also have fully integrated D-Bus support in our D-Men and we will need this for other projects. So we had K-D-Bus support in there. K-D-Bus is dead. We're gonna remove this soon but we had it there as well working. Those first versions of IWD were actually running on K-D-Bus exclusively. Later on we put D-Bus support in there as was full D-Bus support so you don't need Lib-D-Bus, you just need Lib-L and you have generic netling at D-Bus support. The logging, we decided to just go straight to the journal. That can be fixed if you wanna do something else but it can talk directly to the journal without needing anything else in between and we optimized this so it doesn't have too many memory copies there. Sources on L in L slash L dot git on kernel.org you will easily find it. It has been there for a while now. Some other projects have been using it. We're still not on our path to making this stable but I think we're really close in actually putting out the stable version with the stable API on this one. And I will get to back what else we added to L in some later slides. So with that one, I had to update the diagrams a little bit. The left side stayed the same but essentially we said, okay look, we're not gonna stuffing everything in IWD. We're taking L so we can reuse another project and putting the basic building blocks for netling and D-Bus in there so we can use it. So it's just, we push in L in there so we have L and IWD and then everything looks the same. Looks still pretty straightforward as from a stack diagram on what we really wanted. So with this one in mind, we could start it actually programming the kernel interface, bring up the interfaces, start scanning, start collecting networks around, you start grouping networks. We could active passive scanning nicely control this how we wanted it, do the SSI grouping as needed and we just supported open networks. It's pretty much straightforward at that point. You just tell the kernel to connect to it and you are done. Easygoing, great, was a really quick step to get to the sun after having L in place and generic debt link support. So then I said, now we actually have to take this teeny tiny proof of concept and make this a little more useful so let's get to actually making WPA2 work. So we ignored web and I don't have web support at the moment, we said just ignore this. I'll see if someone actually really screams in using this one, use a security and encryption that is completely broken and see if someone actually notices. Anyway, we start with WPA2, so four-way handshake done by an Ethernet port and now we have to open an Ethernet port and do a raw packet handling. Feels absolutely funny and still beats me today why it is done this way because at the end of the day it needs to be fully synchronized with what we have exposed at the States at Configure 11 because whatever you do on the Ethernet port needs to feedback in the handshake completed, the handshake didn't complete and so on and so forth to signal the networking stack what actually happens and what has been done and this is a great pain of source if you're fully asynchronous because you don't know when the kernel schedules what. So if you receive a packet on the Ethernet port you might haven't received the event with a notification about what information elements have been used or what's your encryption and so on and so forth. So WP works around this quite a lot. We have to work around this as well. So I think what has to happen that at least all these Ethernet ports get forwarded through the Configure 11 interface so we have ordered arrival of the events. Right now it's a big mess and I think it's a huge design flaw in the wireless stack that this has been being separate. WSupplicant has a little bit easier because it does the blocking operation for a lot of things, it does polling. So it isn't done with one operation before to receive the other one with all fully asynchronous design we might receive the events at the same time in different orders and depending on what the kernel schedule decided to give priority to. Encryption keys are again reprogrammed into the kernel so they have to go back to Netlink in 11 then you tell you have the keys and so on and so forth and you refresh goes back to user space again we say okay, you can refresh. We can offload this as well and so on and so forth and it requires a little bit of station management code where you say okay I have to manage actually a station now more closely because if anything changes in the Eup configuration then you actually have to redo the key and so on and so forth. All not too much but it went like look we have to do a lot of crypto, we have to do a lot of handling what we really want to do next. So this went us back to we need some cryptographic support libraries. What most people do is they oh if you need cryptographic support we're just going to take open SSL. Every time I have to do this I feel physically sick I don't really want to do it because A the library is huge and B it's not an easy interface and in a lot of cases you need 10% of an open SSL or a libcrypt or something else off us. So we actually went a different route and said okay for the random numbers that we need we could use defu random but fundamentally Linux gained a system call forget random that is done the right way how you want most of these things and solve the problem with the boot up time you don't have to worry about so we actually trying to use all random stuff to get random system call and for all the ciphers and hashes we actually just use AFARG. AFARG is a crypto interface for symmetric ciphers into the kernel that supports hashes, symmetric ciphers and a couple of other neat features that we can use and have been extended over the last couple of kernel releases so we actually have everything from ACB, CCM all the vision, CMAX, HMAX and so on and so forth available with this one. It's not a performance efficient interface so if you think you can shuffle a lot of encrypted details and doesn't have high performance while it can offload this to hardware but you're paying the cost with the overhead of your system calls because it's socket-based interface so don't think you can have high performance with hardware offload on that interface if you use it from user space but since we don't have to do massive operations we do like maybe 10 or 20 this is actually really sufficient and avoids us having to import or audit or include any kind of cryptographic code because we can use just the kernel to do the work for us and it will offload it and be happy and everything else. The HMAX we got a little more recent kernel but I think everything around like 4.1, 4.2 will work sufficiently. If you have a door box that updates the kernel you have definitely everything you need right now. There's a little bit of Wi-Fi specific crypto. I don't honestly don't know why the Wi-Fi specification does some things they do. Some of them has like 20,000 iterations of hash that have to go over something crazy so we have implemented these ones because they're really dedicated to Wi-Fi they're currently implemented inside IWD but they're really limited so it's not really much. There's currently work ongoing for generic KDF stands for key derivation function KDF subsystem for the crypto subsystem so we'll be able to even do the KDFs inside the kernel by just specifying which KDF you wanna do and the kernel will do it for you. It's great if you have to chain certain things together certain operations you can say or do this one and then please generate derive the keys out of this one. We don't know yet if this works for the Wi-Fi ones as well we're looking into this ones. Currently we don't think so because the input parameters into these functions not like you have two keys coming in one key coming out sort of type you have like 20 different parameters coming in and then the key comes out so we have to see what's happening there but I think it's a big progress and these KDFs are all a NIST base so it will avoid people trying to derive keys from existing keys and doing cryptographic mistakes so that's a good thing for easy use. So after doing this one we had this looking like this now so the left side didn't change but we needed a new interface that we're using so Netlink-8.11 to the kernel and AF-ARC into the kernel we added support into L to actually do the handling of AF-ARC correctly there's a little bit funny stuff when you do ARC ciphers yes ARC is still needed for certain crypto like WPA1 is still using ARC and then you actually really only have to I want the cipher or I want this HMAX supported and you basically get the real turnwares back we abstracted this into L so IWD doesn't really have to care it calls the generic functions and all is good and we're all happy so it's a little bit of extra code we had to put in there but we felt it doesn't really blow this up because AF-ARC is already there it already existed and we, bonus, we didn't have to include openSSL or new TLS on acryptographic libraries or even run our own code and keep auditing it because the kernel code is pretty well audited so when we started actually doing the first WP2 encrypted connections we actually run into a couple of troubles that we had no idea how to use the interface why you think it's documented because it's a kernel API it kinda is but on the end it also really isn't and the way you have to put the keys in when you get your forward handshake done and so on and so forth is not really obvious so we said let's see what WSyplicant is doing there and there's two ways of doing this one either we're gonna read the code which in some cases actually will really fail because I still don't get my brain to understand what in some cases actually works and that's spaghetti code or we actually just gonna sniff the interface and there's actually a kernel driver that is called NLmon which allows you to monitor any kind of netlink traffic so you can actually load this driver create a monitoring interface and then you can actually grab netlink traffic and decode in user space you need rule privileges or admin privileges but then you actually can do this so it hooks into netlink and queues and duplicates the SKBs that are queued on netlink and puts them out into that interface as well and you can just start reading them so what we did we wrote a new tool called IWmon that can actually trace netlink A211 and also normal netlink like RTNL and so on we also included an AF packet tracer so you can actually see off the A and pull frames so you can see, okay, we finished the four-way handshake and that event is then coming at what time and so on and so forth so for a simple thing it looks pretty much similar to what we have for Bluezy which BTmon, a little bit of color coding in there and a lot of decoding where it just attracts the request and the scan so what you're seeing here is right now that you have the crest which is the trigger so you trigger the scan the kernel then tells everybody else that the scan has been triggered so it's a broadcast event and then it also sends a dedicated response back to the caller that it succeeded so you put in the SSID you're scanning for test WPA you also have the zero-length SSID in there the kernel then tells you back yes, I'm executing a scan for these SSIDs and by the way, I'm doing this on these frequencies so I shut down the shortcut list a little bit since it's quite a long list and the response is just saying yeah, that succeeded, I'm actually doing this for you so the caller knows oh yeah, the kernel is scanning for me now and what then happens is that the kernel will go oh, I'm done scanning and I have new results now and it tells you oh, I scanned for this SSID or these multiple SSIDs and then these frequencies and then you can go back to the kernel and say can you just give me the results now? so it's you trigger the scan you get the information back that the scan completed and then you can actually dump your information and with this one, you can easily see when W simply began scanning what's happening and you can do this for a lot of other cases we actually decoding all of the netlink or the NLA-211 frames not all parameters but pretty much almost all frames and then you can see what's going on you will also see in a lot of cases we run this W simply again that it has no idea what it's doing because it's hammering that interface and the only thing it gets no such file or directory it means you're trying to do something that actually doesn't exist or you're trying to create a station that actually is not valid at the moment and you're trying to change things which scares you a little bit if you see a demon operating on something and just guessing what it's supposed to be doing it comes back from the wireless extension days where you actually had no idea what's going on and has been triggering through the config 11 interface where the base is just pondering interface and hoping at some point the kernel is ready and get the right information so this tool by itself has been super powerful in just understanding what's going on with your network it spits out all of the information because these payloads are really large but once you actually sit down and you can write them into pcap files and just store them once you actually go to an instance where we can actually bugle out things what goes wrong when something actually really goes wrong So at this point we had a wireless demon we can connect to open access points we can connect to WP2 and WPA1, WP2 access points we had simple roaming working so you can auto connect and reconnect on this one as I said persistence was really important for us and we had an experimental D-Bus MPI and we had D-Bus support we had tools for tracing and we could do extra logging of D-Bus and snag that link via L and just enable this one on the fly so this was really great and we thought that's kind of cool and we would try thinking about releasing this one then out of the sun this whole IoT movement come along and when you actually talk at IoT and actually try to build a wireless demon that works on IoT devices pre-shared keys and open networks are none of your concern most of the time you're gonna build something where you actually deal with certificates and enterprise level Wi-Fi where you actually wanna have devices that really authenticate them so you can actually trust them and not some pre-shared key that you've burned into your hardware because they are not helping you and you can't really publish them and they end up being published anyway so we thought okay let's take one step back again and fix also or figure out the enterprise Wi-Fi stuff so we can do X509 certificates we can do TLS and that one it went like oh we are back again at the question do we include new TLS or do we include open SSL or don't as I said before the large libraries I don't like them I don't like the APIs they're complex they're hard to use and they're still doing blocking operations when you do the handshakes for TLS which is something if you have a fully asynchronous single thread design gets really in your way you really don't wanna do this because this could be events happening that you really wanna react to and you don't wanna waste your time and actually some TLS handshake so we needed a full EAP engine to start with and we needed certificate support and we needed TLS so TLS is actually not that hard the EAP engine is a little bit harder X509 certificate handling is actually really complicated so we took our third step back and said okay we need to figure out something different because we don't wanna use open SSL or do TLS especially with the recent security flaws in these libraries I wouldn't trust any of them anymore so what we ended up is let's look at the kernel key ring which is one of the odd choices to look at when you actually consider doing TLS support but with recent advantages in a secure boot the Linux kernel actually understands the X509 certificate really well and it understands quite a lot of it and it has key rings representing them so you can actually have a chain of certificates loaded into your kernel and you can verify new certificates against them which is like look, that's pretty much what we need so the only downside was the kernel only allows you to do it for built-in certificates of certificates that come from the hardware like look what we actually need we have a couple of certificates lying around somewhere we need to load them we have to create a CA out of them so chain them together as a CA that's a key ring the kernel has key rings and then lock them and say look, there's nothing else being allowed to modify them I'm locking them down and then we can have new certificates added to this one if they pass the checks and are verified by them either set than done but I think the general idea was sound so we started working on torwards the case where you actually can maintain CAs inside the key ring inside the kernel from user space and while doing that one we added sign, verifying, crypt and decrypt RSA operations to the key control interface so you can actually use asymmetric ciphers by when you have the certificates inside the kernel so you can load the certificate you can do operations on this one which means you don't have to implement RSA because the kernel is doing it for you so this is still all work in progress Matt is actually maintaining a kernel tree that combines these subsystems together because one thing you find when you work on this one is that it's basically maintaining three different subsystems or three different kernel trees not three different subsystems but the patches are spread around because one goes in a crypto subsystem one goes in a key ring subsystem one goes into another subsystem and if you want to test this you need to have a tree to actually get this nicely pulled down and built from I think in a couple of months that tree will not be needed anymore but right now it's the only way to do this until we have everything upstream so history has the patches for user space sealable key rings so you can build your CA the interesting part really with the key rings is that they actually can be inherited by any user process you can fundamentally create your CA once as PID1 as system D for example and then you can tell every new process here's the key ID for my key ring and by the way that's the CA if you want to use it that's fine I already see that you can't do anything with it but you can create a new key ring you can clone it, you can reference it and you can add extra certificates to it if you like and you can do temporary ones and destroy them so what we're trying to do is actually we're going to take one of these master CA's and then when we get a certificate from the remote side maybe it includes CA and something else we actually put these in there, we chain them together they get verified by the kernel and then we know that the certificate is valid and then we use that certificate with the key control sign and verify operations to actually make sure that this is a valid operation and that way we can then have TLS minimally implemented by just implementing the TLS record protocol in user space and have all the CA handling and the X5.9 handling moved into the kernel and we don't have to drag and open as a cell for this one our long-term goal would be to put TLS also in the kernel that's definitely something that will happen it's just a little more tricky since there's also enterprise side to think about this way, actually open a socket that already has TLS support in there and how that can be done but getting the key ring side and the CA side sorted out is definitely one step to get this closer and the TLS inside the kernel has also wanted to be the data centers where they don't want to offload this into user space they want to have this actually offload in the kernel and we have hardware, Intel Quick Assist for example that can offload RSA operations so if you use this interface and you have a Quick Assist card in your system it will actually offload the RSA operation onto actually hardware instead of just doing this in software it's a nice benefit of doing this way because then you can actually have also hardware keys where you say your key is in the TPM and the TPM comes with an RSA implementation and say like if the key is in the TPM I'd never see the key I don't want to see the key because I actually don't care just do the operation on it so it puts it nicely together where we don't have to actually write a lot of user space code because the kernel is already doing this for us so we did this and we also updated L so it has base 64 encoding and decoding because certificates come in different formal shapes like PM so that one support we as well some of these ones are supported by the kernel but a little bit extra work you need in user space it's not much so we felt kind of fine doing this one then you can have RSA keys so you can do RSA asthmatic site operations with this one and you have key ring support we can actually load your keys into the kernel and then we put TLS record protocol into L and have that one working as well so we actually have TLS support inside L without having to use open SSL or new TLS or any of the other variants and without everything to re-implement all the certificate handling and everything else we just implement the TLS record protocol so taking the diagram again one extra piece we actually needed the key control is a system call it's a multiplexer system call that allows you to do the various operations on key rings it's wrapped up behind L so we can actually use it so IWD just uses L L uses the key controls and we have a full CA support inside IWD that we have at our disposal for doing the enterprise stuff so when we put this together we have TLS support we have TTLS support and while this is not really enterprise but the WSC support for WPS the push button and pin stuff has been also implemented as an EF method so there's a couple of more then we have to go through step by step but we now have the nice building blocks actually to build the Wi-Fi enterprise support into IWD and it's already done and we already have this working nicely obviously now it gets a lot more complicated and we actually want to test and verify this as all keeps working so we went one step back again and said look we need something more we also have all the protocols that we implement by ourselves either in L or IWD and there are real protocols we can easily unit test them we have unit tests for them so WSC is a good example we can now unit test a lot of it some of the crypto stuff it's a lot easier to unit test them in the sample certificates and so on and so forth so when we do a mistake there or bugcaps and we find them really quickly but we wanted to go one step further as well and look we need some automated testing where we actually can simulate an access point and more importantly simulate a bad behaving access point so what we have so far is we use the A2-11 HW SIM which is pretty much a virtual Wi-Fi card that just combines virtual air together so whatever packet you send there ends up on all the cards it's like broadcast medium with no latency and perfect transmission so it's completely lossless which doesn't help you so you have to introduce some packet losses there but it has a provision for there for doing so we built a tool to actually manage this one so you can actually do this from command line if you want to test with it we don't really use it that much but it was initially good to do because the only other demon using it was WMediumD and that was the only example of that interface we built a test runner tool pretty much bought from Bluezy it's a tool that can inset itself into a running into a new kernel and keep your user space the same and with that one we can actually have no Wi-Fi testing and we currently use end-to-end testing with hostAPD from WSypliCant because we haven't worked on the AP support for IWD yet once that happened we were dog-fooding ourselves and can even build more test cases where we have wrong behavior and wrong payload in four-way handshakes or ERP, et cetera and there's as usual a bunch of Python test scripts we actually can ponder on the debug interface to see what's going on so pretty well going so what we have today open Wi-Fi support WP1, WP2 as that we left web out because we think it's completely irrelevant and should not be used at all it's pretty much using open Wi-Fi and honestly if someone was connected in ERP sorry ERP, a web-based access point we can crack the password on the fly if we really wanted to there's really no difference between open network and web encrypted network EF-TLS, TTRS is working wireless protected setup is working we have an EF engine by ourselves with full EF overland support we have persistence storage and we have a Debas API we have a tracing utility and we have a test framework so all nice things that we can actually work so there's a lot of improvements to do but the next steps will be pretty much getting us a Debas API that we like and say okay this is the API we want to move forward and I give you a quick look at how this actually going to look like it's super simple right now because we really didn't need more since all the heavy lifting we do inside the daemon and conman or any other network manager would be pretty much enough to write a simple plug-in to actually get this going and hope someone will actually do this so you have to scan you can disconnect and you get a list of networks it will audit for you by metrics that you find documented then you will give you the first one the first object will be most likely the one you are actually looking for so it goes by as designed other signal strength information to find it and then it just has a bunch of properties like the name, the address and the state and so on and so forth pretty straightforward it tells you a state of it's scanning or not if you want to do this one so you know what's actually going on on the hardware the more interesting stuff is that our network hierarchy pretty much just has a connect method so you can connect to that and it tells you what name it is and that's pretty much about it you also have an agent because with all our products we actually need an agent when you actually have some user space entity to answer something for you like what's your passphrase we always push this into functionality we can call this out in a third party binary that allows you to do this not work pretty well with BlueZ, Nerd, Ophon and everything other projects so we copied this one around as well and we have an interface that gets you accessing the known networks you can actually access the ones that you actually have been connected in the pass and stored even it's not around anymore so it allows you the ability to remove them so how this is going to look like if you would use it if you start the daemon and you just do one of the test scripts like list devices it will actually just list you the physical device you have in there it will list you the interfaces on these ones and then it will list you the networks it found because once IW starts and it finds a new network card it will actually go background scanning for you in a passive fashion so you actually can have these lists populated as you see we even go fancy they'll include the vendor and models of these ones I just picked a Sony USB stick that I had around that has pretty much reliable if you want to USB testing and it takes us from the hardware to database that system these ships or you definitely is shipping and then it populates its information so I did this about an hour ago or two hours ago so you have the Linux Foundation Events Network here SignalStrengths you see the security it's a PSK so it's WP2 encrypted network you see one funky SSID and then you see the telecom has a EAPSIM network with 1x so that's talking EAP and you have to open one here from the hotel and the other one the telecom hotspot there was nothing much there I'm not even short cutting in this one nicely fit on the slide so it's kind of nice that's pretty much when you start IWD and you call this test script actually we will just show you this one what you can then do is you can take this path these test scripts are really random and very for testing the UI would do this all for you or Conman would just integrate this nicely so you can literally just go connect to this network and you pick the one I would have picked the Linux Foundation one since I know the passphrase for it and in case you would start an agent on the other side on another terminal or somewhere else and then once it tries to connect and need the credential actually can you please input the credentials you go like here that's my credential it's pretty much on your badge in case you didn't know this password and then it will connect to it it will succeed and then at some point right away it will show up in your known networks and then you can just go or list your networks and it will show up oh yeah this is the Linux Foundation Events the last time I connected the last time I saw this and so on of course and that's all it does IW is not supposed to give you an IP but you could now run Conman Network Manager or whatever and the DHCP test tool from Conman is actually doing exactly that one so 20 is 20 or 28 20 is actually the interface index number because that tool only works on interface indexes and not names it doesn't do a name resolution so that would be WLAN 0 in this case and then you can say go can you just get in the IP address and you go like sure I try and within a second you get the IP address on the Linux Foundation Network and you get the IP the name service and so on and so forth and so on now I can program the IP address and then you can start using this one so this would actually work and I might going to try this for just for the kicks of it I haven't done a live demo in a while I might just going to try this live and see if it actually works if I describe this with this one you can also then see the IW1 sorry you don't see this hold on mirror I think I need to increase this a little bit don't tell me when this becomes readable is this big enough some nodes okay the switch no RTNL is quite important because if you actually want to listen to the RTNL you get a lot of extra traffic from various applications that will just send you random stuff you don't believe how many tools that you just execute just dump the list of network interfaces first yes please oh you have demoing something that's different for having a Linux channel but this is not for Linux I don't want to break it oh sorry it's not obvious that I'm transitioning into a Linux machine okay I thought that was obvious yeah this is otherwise that would be amazingly trick right and you would like to know how I'm doing that actually I've done that well you can do this Hoistain has a hypervisor framework that allows you to do this as well if you want to be nifty but then you don't get any hardware access visible now so it's pretty much just going to go start it and it gets a little bit chatting but you also see then at the same time that this is what I talked about where you're going to trigger the scan it will dump them and then you get all these informations and they're quite a lot but the nice thing is you can actually save these traces for offline processing and then look at them what actually happened when you see all this vendor specific stuff and it keeps scanning and so on and so forth if you do the list devices you get one what a phone earlier shout it's the same device in the end and you find your next foundation at work here that you have right there and the monitor idd to that i'm running in the background here is pretty much everything that goes on the bus broadcast it will actually that you know so you can see what we're sending out on the bus another terminal case you wonder as an agent and this would be the nurse registering the agent so i can actually enter the password connect network and then just give the object pass on this one once we have a comment plug in that would do this all for you and you see that the request comes up there at that point that it goes okay i'm finally connected and this over the magic once we have the station management where it goes from authorized now and at this point you could just and then dhp will start even this one is really fast and doing this live on the conference network and even bother take my access point out and then you have an IP address on this one as well that would just work and this is pretty much as simple as it gets and the code is built in a way that you actually have literally no dependencies so if you would actually do this or ldd on idd even l is technically linked into this one so you literally have nothing you don't need open s l you don't need to do it you don't need nip and l you don't need anything else it's all built in and optimized and you can shrink this down as much as you want and have this nicely built together and you see the re keying events and does the re keying offload so on and so forth and you see you can really debug this now quite nicely i think iw1 by itself is such a helpful tool if you have to do anything wifi and see what's going on that alone will make a huge difference it actually works on a live network as well so i'm actually trying to get my access point out and fake this back to the presentation if i find my cursor so this is where we at there's a few things missing sadly the slides already starts with the ones with a few more things missing so what we currently are missing is an iw control tool that we've built for like tools like conman or bluzy we actually have control tool from user space or system we carry around with all the control tools they're easy to use we have a skeleton for this one but we don't have any code for this one yet we're trying to actually now start building the tool and use the debuff API inside the tools you have actually the first real user of this API besides the test scripts the test scripts are nice but at that point we haven't really gained anything once you actually built this all together our big one the conman integration is missing it's on our to-do list and i already got a couple of offers from people trying say they will actually happily work on this one and get this done in mergers upstream so we're actually going to put conman support in there next our network manager not planned from our side anybody happy to do it it will be just not on our task is to do this but we're planning to do actually system re-network the integration so system re-network can utilize wifi network as well besides ethernet and everything else uh... we haven't really agreed on how we do the handshaking on this one in the interaction because as you see with some of the things we have to deal with link up link down and transient links and uh... state changes of these things uh... where system re-network you might actually have no idea what's going on and they need to be a little aware what's happening uh... especially since the interface will most likely to stay the same but if you connect to one access point you might have to run DHCP on the other SSID you might have to run a static IP and so on and so forth so there's a lot of extra work uh... the talks have been started on this one we just haven't reached any conclusion yet uh... the big thing on our list is getting proper roaming at access point steering working uh... because these days with more and more 2.4 gigahertz and 5 gigahertz access points popping up you need this is the band steering that is allowing you to actually pick the right band at the right time because otherwise you're either overloading access point or you're scanning in wrong areas and it will take forever to find a new access point conman and w-supplicant has a little bit support for it thanks to the next guys working on this one but we want to make this a first-class policy that we have proper band steering uh... working on this one so we pick the right networking people have to stop putting 5 gigahertz on one SSID and 2.4 gigahertz on another SSID because that's really not helping we need to be able to roam between 2.4 and 5 gigahertz operations with the same access point many people know that actually it's a separate radio and all these access points support both frequencies and if you take the newer ones they're actually putting 4 or 5 radies in there to actually have more capability for the high performance but it will really only work if you allow band steering we want to offload certain features because some hardware can actually offload passive scanning, background scanning and some other key operation that you have seen so we actually have to build a little extra work to be able to offload these ones so we actually don't wake up it's really important when you have power savings in mind and have some IoT devices that run Linux and you actually want to run i-w-d so you want to be off as long as possible the D-Bus API is not stable yet we are heavily doing API review and common plug-in will be the first dogfooding, i-w control will be the next dogfooding so once we're happy with this one how we can program it and use it, I think we're going to declare the stable fancy Wi-Fi features Passpoint 2.0 is definitely on the list on things to look at but especially with more access points coming up that actually support enterprise Wi-Fi authenticated with your SIM card that's interesting P2P I find interesting I just don't know if it's the it's a big technology anymore we're trying to do this, I don't know if you get to mirror cast doing it one but we're definitely going to look into doing P2P and maybe someone finds it a nice use cases for doing P2P properly Neighborhood Aware Networking that's getting pushed into the kernel right now as a support feature frankly I have no idea what to do with it at the moment mainly because Bluetooth Low Energy does a way better job in doing this one, discovering devices and services and they even specs for this one so we have to see what the future of neighborhood aware networking is and then see if we're actually going to take this in as well there's a couple of other features pro you have to do and feed something in there where you have to be a lot smarter than WSupplicant is right now but we now have the framework to actually do so the source code is not yet available we have to be working on get this out of the company I assume this will happen in the next couple of days or weeks so it's really ready to go out and people have toying with it one the L code is public and the kernel crypto trees are available as well so we managed to get these ones out already but the IWD code has to wait another couple of days I hope by the end of the week or sometime next week we get this out of the door it's pretty much ready to go and with that thank you and any questions yes please it's not on our immediate radar but we actually definitely want to do it and you will need it for P2P anyway if there are no further questions then thanks everybody and have a good day