 I'm Marcel Holtmann and I'm going to have a quick 30 minutes. I just speak a little quieter than you can hear me. A quick talk about what we have done with the wireless daemon and where we are right now and what has been happening over the last year. I went to my talk yesterday, standard disclaimer site, since I work for Intel, so we have all these nice disclaimers, etc. But then I have them out of the way. Before I continue with this one, I have to give a lot of extra credit because I'm not the only one working on this one. It's a whole team with me that actually does a lot of the works. Dennis does most of the major patch handling. Andrew does a lot of the internal work when it comes to the really nasty parts of the wireless subsystem. Tim Raoul, James are pretty heavily trying to get us support for all the other features that we need. And Matt has been working on the crypto stuff, and I will get back to this later. So Wi-Fi is always funny, and I've been working on pretty much everything that doesn't have a cable, mostly Bluetooth, but also Wi-Fi, 50.4, and all the other funny technologies. And the Wi-Fi site has been rubbing me the wrong way for at least the last 10 years. It never really felt right how we are doing it in Linux, and I never really liked it. So a while back we set out to do something different. And the reason why we set out to do something different is because it never felt as a subsystem. You can say the Wi-Fi has a subsystem in the Linux kernel, 802.11 subsystem, they're doing all the work, they have drive abstractions, all great from there. But once you actually try to start using this one, you basically get told use WP-supplicant, and that's the only way to do this. And the problem is it does a good job for certain things, but it never does the complete job. So if you look at this one, for every other subsystem, we over the past 10 years, we actually have built a subsystem, a nice user space, and then we could actually have a connection manager on top of this one using this one. So the logic of what is technology-specific has been kept inside the technology-specific daemon, besides gluesy, Ophono, et cetera. And it worked really well. We have a gap for 1504, but that's just the time we're going to fix. That's a gap that we fixed pretty soon as well. But when it comes to Wi-Fi, we could never do it this way. We could never say WP-supplicant, but my network actually can reconnect this. And always, and it was really complicated, it does half the job. You have to do extra glue on top of this one. It's complicated. It swallows state. So sometimes you actually don't know what's going on, which is really, really bad. So we had to build this whole Wi-Fi support into the connection manager. A network manager had to do the same thing, and everybody else, including Android, Chrome OS, wherever you're going to look, as soon as you use Wi-Fi on Linux, they're using WP-supplicant, so you actually make it usable, and actually have to do it the right thing. So things move up into a layer. They're not supposed to be. And what we were really after is we want this layout. We want a connection when we're on top of this one, and then we actually want separate technology demons that actually does the whole job for you. And this is what we came up with the iNet Wireless Demon, so IWD, keeping it pretty short and don't have a complicated name. And this is what I'm going to give you a quick back, what we have done so far and what we're going to do next. So every time I'm doing this one, it's like, why a new demon? Because I get always told, don't do this. Don't rewrite things. I'm personally a believer doing a second project that gives you competition is a good thing because it brings both projects forward. Initially, we actually didn't want to start from scratch because it was too much work, and we said, okay, let's fix WP-supplicant. I don't really care. We can just fix this. I wouldn't accept it upstream. Some of the ideas were outright rejected. Some of the things were like, oh, you have to do X, Y, Z additionally, and then you say, oh, look, how are you going to do this? Or you can't do this in the current code base. You have to do tons of other restructuring. So it's really complicated. And the main key points were that really struck us were persistency. WP-supplicant doesn't remember a damn thing. You restart, you kill the demon, you reboot, you disconnect from your network. All the information what you have done before are gone. It lives in the moment. So it means you never know what happened. And if you want to keep any kind of state tracking, so this is my network for home. This is my network for work. At this time, I'm connected to that network at work because it's probably between nine and three or four. And I'm going to drive back home. Don't bother finding the work network. It's most likely not there. And these things you have to do by yourself. Nobody's doing them for you. So you have to do things over and over again. And this went in complete contrast to what I was talking about. It remembers all pairings, it remembers all access points, and so on and so forth. The worst part then when you say, look, we can live with this one is that all the management of 802.11, some of the key details you have to redo inside your connection over again. So parsing the information elements that you get for the security information, every single connection passes them again. So it's not you don't get told this is 802.11 pre-shared keys. No, you get a bunch of information elements and you have to figure out, oh, what does it mean? Is it really RSN, personal assist, enterprise, and so on and so forth. So that all trickles up the stack for no apparent reason because in the end, you don't really care. Tell me what you need for me. Do you need a pre-shared key? Do you need a certificate? What do you need? I will give it to you. In theory, these should be all have been hidden, but they are not. And this really, you see this in designs really complicated and it trickles through. And if you look at other things and you want to take this up, some tasks go up into the Chrome browser because they only figure out we can only answer this in the UI because we have nothing in between that actually will do the abstraction for us. One thing that rubbed me really badly is that WSIPCant runs on literary everything. So the amount of abstractions they have in there is unbelievable and I have a diagram that will show you a little bit of it, but that's only a little bit. But that you fundamentally still carry around the legacy stuff for wireless extensions and creating it. One other thing that is really not that critical, but for us it was a really key point that we couldn't live with is that it actually uses blocking operations. So it sends a command to the kernel and waits for the response. The kernel interface is completely asynchronous, so something can happen in between, you can get an event. It will actually swallow that event and only give it to you later, which means you're missing out on doing things in the right way or doing things fast and it can do much to this one. It can do everything. Whatever kind of spec you're going to find, it has support for specs that are in draft form and will come out only years later. You have code for the in there, you can toy with it, you can play with it, but if you want to actually build this into a product, you're kind of lost. And if you break this a little bit down, you get to something, this is still a simplified view, but this is what it actually looks like if you actually do WSIPCant and use it. You have the hardware, that's also great. You have the configuration interface and you have netlink or the wireless extension to this one. We can live with a dual one. If you're running on macOS, you have to do a different version. If you're running in a RTOS, you have a different one. If you want to do this on Windows, you have a different one and the list goes on. And then you have finally the supplicant, but then it exposes like four interfaces that I actually have found lately. It has a control interface, which the developer uses and the developer has a control interface that nobody wants to duplicate because someone might be using it. You have a new one that isn't complete. We actually would have to build a third one to fix the issues of the second one. I think you still have the binder for Android integration and there are probably even more that I keep forgetting. So our biggest problem was really that we had to actually build another library on top of this one to actually get the state guessing into a single place and have a current view on what this thing is doing before we try to actually push the states even higher. So we tried to push some of the states up into the UI. Network manager goes really high and we had to actually build something called G-supplicant that allows us to confine all the craziness that we got from the API in this level. We're still guessing in a lot of cases. If you use this setup, we're still guessing a lot of cases if the state change is from connected to roaming or from roaming to disconnected or if we lost the authentication between. We got pretty good at guessing, but it's still guessing a lot of cases. Oh, and of course it carries around its own TLS implementation. You can use new TLS, open TLS and all the variations of this one. So whatever you wanted. If you think that's bad, it actually gets worse because everybody forks it. I mean, every silicon manufacturer has their own version of W-supplicant because they actually make it hardware dependent at that point which makes it even worse. So really not maintainable and if you think what is currently running on the Android is then running on a Linux desktop, that's probably not the case. It's not the same similar to the Android version because an Android phone from Samsung will have a different W-supplicant than an Android phone from Sony, etc. So it's really, really bad and something that we couldn't live with in the stock. If you want to improve this, we just have to ignore this. It's not maintainable, it's not fixable. We can't do anything about this. So how hard can it actually be to start from scratch? We actually had a really good idea what we were getting into when we started, it was still a little bit blindsided with some of the key pieces where things got a little bit more complicated or where we assumed the Linux kernel was doing the right thing. It wasn't always so, there were little things that were unexpected. But generally we had a good idea going in there and if you take the diagram that I had before we actually set out to do this really, really simple. We don't want to do wireless extensions, they're dead, we don't need them. They're actually also not capable of the things you want to do. We have an embedded library underneath it since we needed basic functionality. We didn't want to use GLIP anymore and we also knew that we needed a little bit extra features like generic that link support and so on and so forth. And then we want our daemon, and then we want a debus interface and then we're going to start Conman on top of it. No guessing, nothing looking absolutely identical like what we did with Bluesy and Ophono. So refocusing on Linux, this was really the part. Forget everything else. We don't want to support Windows, we want an RTOS, we want to focus this or get this up on Linux and use what Linux offers us. The interesting part is that some of the interfaces WSupplicant was the only user and it actually was using it incorrectly and nobody realized it was using it incorrectly and had some fixes in there. So that's kind of bad. If you only have one client for a kernel interface, that's never a really good idea. Examples were hotplug support. They completely forgot about hotplug support that you want to put a new card in there, have a new Wi-Fi device and then say, oh, the kernel tells you you have a new Wi-Fi interface, they didn't and I have no idea hotplug actually worked since you couldn't make this work, but it turned out WSupplicant actually listened to the network interface coming up and once the network interface came up, they said, oh yeah, there might be a new card, so let's look if we find a new card so then ask the kernel to dump the card and so just telling like, why can't it just tell us that there's a new card? These kind of things. There was always a wireless interface bound to a network interface, but that doesn't really exist anymore with more modern wireless technology, so fixing this was one of the obvious things. Some features didn't work, I expected, some features needed to be added and we still have a bunch more, but the majority of them to actually make this work now we actually got all upstream a while ago what I think about eight or nine months ago, so this is pretty nice if you get a recent kernel, all this will work fine. The Netlink library was another pain point since there are still, I think probably six or seven Netlink libraries out there, Lippernel, the most prominent one. It's touted as being fully asynchronous and easy and great, it isn't. It's actually pretty horrible because it's actually blocking when you do the generic Netlink discovery so it actually sits down at weights until you discover the families. There's no guarantee that the kernel returns them quickly. Also the generic Netlink families are dynamic so if you unload a kernel module they might go away and get a different ID so we needed a new Netlink library and there's a couple of other ones and the Lippernel actually is extremely bad in some cases because it uses a lot of memory because it pre-allocates a 4k buffer in some cases. Look, we need like 80 bytes of this message and you are allocating 4k, that's kind of wasteful. So we said, okay, we need something new for this one as well. So we already had the embedded Linux library worked out as more as a pet project to turn the other projects away from GLIP but IWD was the starting point and actually drive this further. So we had to put in standard stuff, main loop handling, signals, ring buffers, hardware, database integration, hash tables, all these fancy stuff that you need no matter what you want to do. But we also put Netlink support in there and once you actually redo the Netlink support not using Lippernel it actually becomes super easy and super small. Same as for the generic Netlink and you can actually discover and rediscover families and will tell you actually your family went away from tracking. In that case it works similar to D-Bus where you actually have services coming and going at the time you want except that's a kernel service at this point. We said we don't want to use Lipp D-Bus. Maybe some people can relate. It's not an easy interface to use. It's one of the things how hard can it be to write a D-Bus client. Pretty hard actually since that protocol makes you want to jump off a bridge at some point. So I don't know, not many people actually have rewritten that from scratch but some people have. You have my sympathies, trust me. Especially you want to do this zero copy. If you want to do this zero copy in some point you use the cases like who has designed this protocol? Why can't I do zero copy over that array? It really drives you mad. I think we managed sort of but it has native D-Bus support and we also don't really rely on anything else. Which decreases our dependencies quite a lot. We did logging while the journal and internal debugging and something like dynamic debug etc. We've been doing kernel docs since a long time. We've done releases on this one so this is all good. We are pretty happy with this one. So with this one, all figured out and all done, we actually were able to do wireless connections really quickly. I think it was two or three days and we had the first wireless connections up including card discovery, creating the interface, setting up, scanning, grouping the interfaces. That was really, really quickly you got it there. You could actually, if you have an open network, you could connect to it, run DHCP but then the fun part came is like so how are we going to do the rest of it? Because we actually have to handle the keys inside the kernel, we have to figure out everything else, we also did the rest of it. And we tried and we actually failed in some cases because the API documentation hinted in a different direction. So I was like look at WSyplacan what it's doing, that makes no sense and it's like how do we figure out what's actually supposed to be done, what's actually okay. So we actually had to make one step back and say look, we need to know what's happening between the kernel and the user space. We actually want to trace the netlink commands that are going into the kernel, what they're doing, what the kernel response is and so on and so forth without having to enter 300 print case or print kf's into WSyplacan and retrying this one. So luckily for us at that point we had the netlink monitor driver available and so you could hook into any kind of netlink message. It sounds really easy but it was rather complicated because it gives you pretty much everything. So you get route netlink, you get netlink, NL211, you get every netlink messages if you're unlucky. So you need to play a couple with filters but at the end of the day we actually figured this out and even without any progress that we actually got a monitoring tool to figure out what's actually going on between the demon and user space and the kernel was already great achievement. We added also E-PAL support for this one so we can actually debug what the four-way handshake is doing which really helped us to figure out okay this is going right, it's going wrong and we're using this one for a lot of development and it behaves badly or client behaves badly and then we can figure out what's going on. It's pretty simple, it looks like the Bluetooth monitoring tool which we copied some code from it. This is an example where you just scan for this one so the supplicant says I want to scan, it says I want to trigger the scan that gives you the frequencies and the SSID it looks for it will tell you okay that actually worked and then it will go the scan completed and now you can go start collecting the results. The interesting part is the notification even if you don't the active demon that triggers it because you get a notification also that someone else triggered the scanning for you. So even if someone just types in a command line IW scan you can actually figure the rest out and actually act accordingly instead of trying oh something else is scanning now don't try this again kind of thing. So with this one in the box we could also debug how some of the keys have been entered what's happening in the right order and so on and so forth. Guess what, in a lot of cases there is no idea of some of these stations that are active or not active anymore and it tries to lead keys that never have been there in the first place it's kind of funny to watch in these things. Anyway, we needed to actually get pre-shared keys at least working so four-way handshake was a mandatory thing dealing with an Ethernet port if your main interface to the kernel is a little bit weird it's something we're actually going trying to fix really soon actually the Ethernet package is a little bit over a netlink so you don't have these race conditions between the Ethernet scheduling and the netlink scheduling. We need to synchronize these ones as I said this is the majority that actually might go away right now we still have to do this so we have to cache some packets and then make the decision later it's a bit nasty. Encryption keys have to go in netlink to 11 but you have to actually track some of them and to make sure this all works out but it's all good. It sometimes works at other times doesn't so I think we have to go back and fix some of the kernel drivers that claim the support key of loading or key refresh of loading and in reality they don't so we have to figure this out and you have to build proper station management but actually it's not that big so once you have this all done you can really easily connect to a pre-shared key network what the most people use at home so it's ready really quickly. We had to make a small detail since we realized the target market for the embedded world where you want to actually push IWD because it's so tiny they all want enterprise security you have the small embedded device somewhere and they want to put certificate in there and that's where they want to connect initially we didn't want to do this that early but we realized okay we probably have to so enterprise Wi-Fi X509 certificates and TLS and it's like oh my god so what do we have to do now do we have to get back to actually track new TLS and open SSL in there my experience with either of these is not good we have to get back to this and open SSL from API point of view and some things but it still has the fundamental problems it consumes a lot of memory and it also has blocking operations for the TLS handshake that really didn't let us the right person say look we don't want to use any of these ones we actually want a non-blocking access to the TLS handshake as well so that means we also need a full E-UP engine and at the end of the day we actually started looking into the kernel crypto so whatever we have to do for the crypto we don't want to actually use an external crypto library but we also don't want to write it by ourselves so AF-ARC and the get-random system calls gets you pretty much every single hash on the planet every single crypto cipher symmetric cipher and that way is we got this pretty well sorted out small minor detail was that Wi-Fi has a few weird key duration functions that drive you crazy as well because they decided to actually use something standard they are actually standard but they have to make the input they get is really from complicated four-way handshakes where you have the MAC address in there and some announces and so on and so forth so if they would just use something standard it would be a lot easier especially since the kernel got a crypto key duration function inside the crypto system you could just handle the input and it would give you the rest of it and you could chain them easily together it would have been easy so with this small Wi-Fi we got this really figured out and it just calls into the kernel since the crypto by itself is really small the performance impact of doing the system calls doesn't really hit you at all they could offload this via hardware but I don't think any hardware will be more fast than just doing this in software if you only have one or two AS operations for example good thing is we didn't have to do this implement them in user space and we don't have to use the next one crypto library for the enterprise one it got a lot more trickier we had no idea what to do with X509 certificates luckily the kernel does so because of secure boot the kernel actually knows how to handle X509 certificates the kernel knows how to actually pass them, chain them together, verify them and so on and so forth we just really needed to actually extend this so you can actually do certain operations that the kernel was doing internally but never exposed to user space so it's all done via the key control system call and it allows you to actually load certificates put them in key rings so you can actually build a CA that the kernel holds for you and use that as CA for your user space there are a few functions missing we have them in external patches and Matt maintains a tree that actually has this all built together because it comes from three different maintainers and hopefully in the next couple of kernel releases we get these ones upstream so they're actually available but then pretty much you can build a whole CA in user space but let the kernel manage it so you can hand it over to separate processes also because the key ring subsystem has a permission control that is really fine you can even have one thread having a different key ring access than other ones so it's pretty nice, works out pretty well it doesn't have container support but I think people are even working on this one with this in place we actually had to deviate a little bit from our original design but really not much it's pretty much we actually use additional functionality and key control that the kernel offers anyway and it's available on most platforms and with this one we have the crypto figured out don't need GnuTLS, don't need OpenSSL or anything alike we don't even need something like libcrypto for basic cryptography because the kernel does this all for us so where did this all end up in most of these we just stuffed into L and say look if you want to use an ASI for, if you want to use a hash there's a function L for it there's a few functions we had to do in user space because they actually are more like file format things so we have base64 encoding, decoding, pm format for the certificates and then we actually added the R as a key and keyring support as well as it's available but right now as of now you need a reason, you need a maths kernel to actually pull this all together the TLS record protocol as of now is actually implemented inside the L library but hopefully with the TLS support inside the kernel we get this fixed as well so that's all good Enterprise and once Wi-Fi we actually have this now so the push button support or the WPS is fully supported and works amazingly quick TLS, TLS sim, even sim support where you actually integrated this with a phone so you can use a sim card for authentication all there works all well so all these things that are really really complicated have been taken out of the equation that's all good but one of the things we had we now had a functional daemon body down there you can control it and this is again a chicken neck problem where you have a people where you give them a daemon but no one knows how to use it so our IW control client is complete as well and you can actually use this with the Python tools together and really use it for actually testing and so on and so forth the interesting part to note here with the W-supplicant you really can only have one user so whatever you put on top of this one has to encapsulate it because any concurrency will completely fail because you stumble on the other so everything had to go through comments you had no chance of just looking what's the Wi-Fi status or get the ASUS iUpdates or anything else with IW you can actually do this now because we actually separate this out and you can have a comment talking to it you can open IW control to see what connected a network you're connected to you can have a separate agent for your passphrases you can even have an ASUS iMonitor and just connect it directly to say look I only care what the current ASUS iStatus is and what my network name is because I want to display this in the status bar I only had a few minutes left so I can try to actually do a demo really quickly to see if this works so you get an idea on what we have so where are we going oh sorry you don't see anything just for fun with so the monitoring is kind of interesting then you see what's going on you're not watching the same time on YouTube how much bigger and let's try this one as well the funny part is you see that route netlink gets even executed when you actually just type a symbol command so the C library executes the crest for netlink interface as well which is funny to see so if you just start the demon it's fully debug mode on right now you get the information it sets the regular information but currently no card is attached to it so if I'm actually plugging one in it finds it and it starts already scanning for it and tries to find the networks so the API interestingly is really really simple on IWD we don't have to do much since it keeps all the states we really only need to give you a way to discover your devices you see it found the wireless interface and we can just scan on it it has tap completion so it's kind of neat as I showed the example before you can just scan on it and it will eventually succeed accidentally I picked a card with 5Ghz support so it will take a little bit longer but you see what's going on and then you can just tell me actually what networks are here and you see we have a couple of networks here, not that many the fun part actually what I like most is that this actually works I can do the push button support so I could really literally just go do this and then we'll start out finding it and it will succeed so you'll have when I demo this one it doesn't work maybe try this one more time so generally this works really quick you see the commands going on you can actually let's try if this actually works manually the only thing we haven't really done yet is the agent hasn't been integrated into the control utility so this is a little bit of a problem that we are fixing really really soon and you see it obviously asks you for the passphrase, you type it in and if you're lucky then it flipped to connect it so it's as fast as I can't even type this in the command bank line it's already done connecting to it one so I'm out of time so but with this one oops do you have any quick questions before they kick me out of stage please go ahead has the ELL library found any other users yet? so yeah that's a good question so we actually have this with some of the multi-pass TCP support, we're actually doing this one there are some other projects in the IT space using it we actually build a version that you can integrate into a phono so we can run this at the same time we run the glib main loop so we can actually use both and we will slowly migrate away from them really quickly in the next couple of months do you aim for desktop support as well? oh yeah so we actually I'm skipping these now so what we really want after is there's a few things we actually really after so we currently have command support last time I said we're not going to do network manager support, that's changed we actually are working on the network manager support you will see this really quickly we have a working prototype where we use this in Chrome OS so we're taking a few things out there, there's a lot of work to do there it's really just a prototype we actually want to drive this even further and see what we can do this one we don't want to do it here in Android but any other distribution could potentially have it really quickly either if they use network manager or if they use a phono or for Chrome OS we actually will make a dedicated version so yes we hope this will be done really quickly we have some fun stuff on the works we're actually going to take the EAP engine out and build this for Ethernet based authentication so that will happen soon and we will create a separate demon so you can actually connect to your corporate network by just plugging in the cable as well but we really need to take this out because we don't want to use WSYPLICAN for any of the cable based authentication as I said before the agent support will be built into the client as well and there are some other advanced features when it comes to roaming, fast transition etc we've all built them in but that's happening pretty quickly oh by the way before I give it's not a vulnerable against crack that has been all fixed we not install a zero key we are not doing this one and never have to we actually don't even reply to the measured three that's happening because we just decided to ignore them because they really only happen if you're super paranoid and have an absolutely horrible link if you have some horrible link a lot of other things go wrong first before you actually see a replay message anyway with that thank you very much find me offline if you have any further questions thanks