 Then just welcome everybody. I'm just going to get started since not people in the room. So my name is Marcel Altman. I work for Intel. And for the next, ignore the disclaimer. I just need this for the slides. For the next 30 minutes, I'm going to tell you a little bit about what we have been doing for the Wi-Fi support in Linux, especially with IWD, the iNet wireless demo. Good news first. It's 1.0, as of about 20 minutes ago. So we're done with this one. APIs are stable. So kind of nice. Thanks, everybody. I'm going to the beach now. Not quite. The problem is, even with this release and our efforts that we have made, Wi-Fi on Linux still sucks. It hasn't gotten any real better. We have made a lot of progress. But there's still a lot of areas where Linux lacks behind what other operating systems are actually doing. And it's a little bit, I'm keeping the guy bar steamer going with the talk. It's a little bit when Guy Barsh went to the bar and said he wants to be a pirate. The answer is, pretty much you have to run around and complete a bunch of trials. And that's what currently most people on Linux are actually using when they use Wi-Fi, because it's a bunch of things stacked together. And not really one entity is doing the whole thing. All pieces are doing something. WSyplican is doing something. The kernel is doing something. But you would say, OK, you have WSyplican as some sort of Wi-Fi demon that does the authentication and everything else. The kernel does the basic handling of the hardware, et cetera, et cetera. And you go, oh, that should get you pretty far. No, it doesn't get you anywhere. You will not get it connected. You will not be able to do anything. You have to write a lot of code or tools around it to get this done. That what happened with Network Manager, they built on top of this one. It's the same issue that we had with Konman. We had to build a lot of things on top of this. It's what everybody who built a consumer-grade device that actually has Wi-Fi support, they had to build tons and tons of extra stuff on top of this. And then the Wi-Fi association doesn't stand still. There's new specs are coming, new security. WP3, for example, is coming along, new enterprise methods, and so on and so forth. So there's always something you have to do. You would hope you can fix it in one place. For example, WP3 support, you would assume that you can actually do this in the Wi-Fi demon at support for this one and move on. With this model, it actually never worked this way. You had to actually add support in the kernel. You had support in the demon. You have to add support in Network Manager, because otherwise, Network Manager recognized it as an open network. And sometimes, you even had to add extra support for the UI because you did different keys or something else. This is something that is really not sustainable, and you can't really do this long term. If anything new comes along, you have to change the whole stack again. Well, frankly, I didn't want to touch the UI. If the passphrase is the passphrase, why would I actually have to do this? The other big problem is that some pieces had, are still doing these days, they don't want to store anything. They don't want to keep knowledge. They don't want to never remember your passphrase. They don't want to remember your network. They don't want to remember you've seen the network in time on what frequency, so you can connect back to it quickly. It's all handled, oh, someone else will take care of this one. In case of Linux, in most cases, it's Network Manager was doing a lot of this task and trying to glue this back together. But in other operating systems like Chrome OS, for example, and some others, some of the things go actually are done in the Chrome browser. And it keeps the information for you. So it all ends up, someone else's problem, someone else's problem. At the end of the day, user interface designer has to deal with, or the user interface develops have to deal with actually storing this information and getting the states all right. So if you have six or seven entities that have to keep the states in sync, something is bound to go wrong. A lot of times it goes right, but a lot of times there are also something goes wrong. And then you have other entities. The interesting one is when I draw this picture also, you would expect that the kernel API, the Netlink 8 to 11 API, is really only accessed by the demon that actually uses it. It's for controlling your hardware, for setting up your network, for setting the security console, et cetera. But at the end of the day, these days, pretty much every demon goes and checks that interface for some information. We found that DHCPD, which was pretty much used with Network Manager until last release or something, goes on and dumps all the station information and scan results. And you go, like, why? What does it do with it? Then Systeme Network started looking at this one as well, because no other entity can give it information about the network. Oh, let's put some magic pieces in Systeme Network configuration to actually do this as well. And so on. This bleeds through. So everybody wants to have a piece of it while we think this is actually pretty much not what you want. And the worst thing is you then talk to Stan, and he wants to sell you a boat. And you go, awesome, I'm going to get a boat. Everybody gets a nice boat. But when you're on your boat, nobody's doing the right thing. They're all standing along and waiting, and you actually have to kick them all along the curve. So that was pretty much when we said, OK, look, we have to do something. And that was around five years ago. And the idea with IWD was we need to consolidate the information that are Wi-Fi specific in one piece and only have the UI and the upper entities handle the things that they actually can do best. So no networks. What network I've connected to, what pathways, what last channel it was on, where I've seen it, and so on and so forth. This is something the Wi-Fi even has to control, because it's the only way to actually be smart about this when you open your laptop and you want to reconnect quickly. Every other operating system does it this way, except Linux. If you open your iPhone at ROMs quickly, if you use your Android phone at ROMs quickly, they do a couple of other hacks. MacOS and Windows, they do this because they're all concentrated in one piece. And we only want to have one entity talking to Nettling A211, because it's a radio resource that we are controlling. If six entities in your system trying to control your radio source and trying to scan or do something else with your channel, your throughput goes down. You even get disconnected if you miss a certain set of beacons to the access point. And then you wonder why this doesn't work as stable as you want. We can't have six or seven pieces of software running a system deciding, I want to scan for Wi-Fi networks now. No, that needs to be centralized. And the decision needs to be when to scan and how to consolidate this, especially when you actually want to say you want to connect back, close your laptop, you open it back. You don't need to scan all your channels. I mean, they're getting bigger. We have 2.4 gigahertz. We have 5 gigahertz. They're jumping on 6 gigahertz now. They have 60 gigahertz for certain applications. Tuning a transceiver to 60 gigahertz is expensive. Tuning it in 5 and 6 gigahertz is also expensive. So if you want to scan all channels, you're wasting up easily three to four seconds there by just scanning all the channels. But most case, you already knew where your access point was the last time you opened it. Scanning this one is a couple of microseconds. So this is all centralized now. And with this one actually fully working, we got to the level where we actually have IWD doing a lot of things automatically. So we have the known networks database. It remembers every of your networks. It remembers the last one you connected to. It remembers the frequency it connected to. It remembers the network settings. It groups and joins your networks accordingly to the security settings so that you actually have, you can have mixed combination of WP1 but WP2 and WP3 networks and they will be categorized properly so you really talk about networks and not separate access points. We can provision them with configuration files. So you actually don't have to configure your network if you want to have someone giving you a configuration file you can just dump it in and it will automatically connect to it. So you don't actually have to click three I to do anything. The scanning is fully optimized because the only entity in the system that actually scans is IWD. It takes input from the UI if you need to find your network. For example if you open your icon you want to see a new network then it will actually do proper scanning on all channels. Otherwise it will only do scanning on the channels that it thinks are the best. And in some cases these channels actually don't come from your last seen networks. These channels come from your access point. Since what happens if you actually lose your signal strength to your existing access point with a lot of access points you can actually go and say, look can you tell me what your neighbor is or where your neighbor is? Maybe I just gonna try to jump to your neighbor. And a lot of access points these days get smarter even at home where you can buy 400 bucks a mesh network system where you actually can have five of these one and they can communicate between each other and you lose your signal strength and you actually can ask the access point where's the next one with the higher signal strength. And the access point will do a lot of work for you. So you as a client just go, oh hold on let me check if it's there it's there you just jump and you start roaming. So with that scanning optimized we can actually do roaming and fast transitions really easily without having to do any real credentials. So things like doing voice of IP telephony over wifi becomes possible. We're not really quite there yet but it comes really possible since we can roam super fast right now. We can also participate in this all this radio management by saying look if the access point needs us to scan something because it wants to see how much the networks are utilized or how far you're from another access point we can help this as well. This is also fully integrated and just works automatically. We upgraded when the security issue or the new spec came out for WP3. We upgraded in the background the support internally to support WP3. No change in the UI, no change in network manager no change anywhere was needed. The only thing we had to do if we start an optimized key from the passphrase we had to ask the user again for the passphrase if we didn't have it but that was all automatically done in the background so it all worked out nicely. OW is optimistic wireless encryptions we support this as well that's pretty much if you have an open access point but it supports encryption we can enable encryption as well. The difference is if you use WP3 you have man-in-the-mill protection if you go on an open network and encrypt it you don't have any man-in-the-mill protection but nobody can actually sniff your traffic that easily unless they actually monitor your initial security handshake. Works automatically as well if it's available. The ERP engine we rewrote from scratch so all the authentication methods for enterprise are integrated into IWD with the use of the kernel keyring system as a handling of keys and certificates and signing and authentication there. Recently we added hotspot 2.0 support so actually hotspots that support the standard will be classified properly and you can just connect to them and even roam around as you want with support for Ophono or some other telephony stack that provides your SIM credentials or other credentials. Protected setup and the symbol configuration the push button methods have been working for a long time it's one of the systems since we redid them from scratch as well it's like where we found that actually really works with the majority of the access points we just press a button you connect to it and we'll find it. Recently we have been heavily working on address randomization pretty much every access point you connect to you will get a new address if you enable this one. So access point A from this hotel conference for example and your access point at home they will see you with two different addresses and so they can't correlate who is who anymore. This works pretty well but also needs a little bit more extensions and additions inside the kernel to make this even faster I get to this one in a little bit. We also have access point mode for personal hotspots tethering so you can switch your Wi-Fi card as an access point that works as well. So these ones we have already in there and we have them working stable and they're really nicely and they're working just automatically you don't really do anything you have to do any extra configuration or anything else it's just available to you and most of the times you actually don't see this because the only thing you do is actually oh I want to connect I want to find that network so you scan for it you get the results and then you choose the network then you connect to it and then you move on. After that when you never actually look at IWD again because it just does the work for you in the background. Then again there's a lot of other things where you get run around and have to deal with a three headed monkey and other things. One of these ones is actually the provisioning. We have been looking at this one since the early days they said looking there's some configuration files we actually don't wanna or some settings we don't actually wanna expose to the human and I don't know if it's fully visible I hope so. The top three are pretty much but Windows 7, Linux, Network Manager and Android is doing when you actually want to connect to your enterprise or corporate network. And these are only a few of the screenshots that this instruction manual from this one university has. I think they have like 20 pages of screenshots where they guide you through the setup process how to get into these kind of networks and it's exhausting and pretty much all click here, click there, fill in that certificate in there, put in your username in there and I mean even an expert is kind of lost at some point. The normal user will be even more is to get the setup but we actually do wanna use the WP Enterprise because it's a good security model because you don't share your keys with everybody else you get your own credentials your own encrypted so nobody can actually sniff your traffic even if they're on the same network with you. Windows 10, the instruction is kind of funny they have a configuration file so you can download a configuration file and XML file but then you have to open the command prompt and install it from the kind of funny. So they made the step in the right direction but just actually loading it and installing it properly the UI was missing for that one or something. Maybe that got fixed by now I'm not using Windows 10 so I have no idea. Mac OS pretty much you just click on that file from the website from the university ask you to install it and then you off you go. Sometimes you then have to provide your username and passphrase because that's additionally information or you have to actually accept the certificate and integrate it but that's pretty much all you have to do it's pretty much take the information file and all the nasty details on how the network is working it's handled for you. Same goes with iOS that is stuck okay yes take this configuration file move on and then you're good to go. So I think we want something similar we have something similar with IWD so you can configure your networks top is a TLS example which pretty much corporate networks use the problem is still you have to provide the domain you still have to provide the client certificate you have to provide the client key and you have to provide the CA certificate and you have to put it in the right path in your directory that path needs to be accessible IWD that goes a bit counterproductive that we actually shielding IWD in the sandbox so you can't actually put this in the user home directory and still have the access to this one because IWD not supposed to read any home directories and if you run system D it's actually set up in this way that actually fully protects you and then it gives access to the things it needs. PAP and the same the password ones are the simple ones where you actually have it enterprise network but you just authenticate with a username and passphrase PSK on the bottom is an example where you actually just do this for your home network it's pretty much you just put the passphrase in there and then you're good to go. What we have been working on is that we actually want to keep these files this simple but we want to have one file so I can't have a file and then three other certificate files somewhere else so what we have been doing we extended this any style file format a little bit that you can embed actually TLS certificates in there as well. So you can do this copy and paste pretty much you can get them together you have to add extra header where you name them and then you can reference them from the key files that you actually have on top. So the top is pretty much identical is just instead of a file of reference to an embedded section inside this file. We have a tools that convert from the iOS configuration files to this one and we're gonna add tools more that will convert existing files into this format so you can just dump it into IWD and off you go with your corporate network but fundamentally what this allows is that your enterprise admin can give you a single file or generate a single file for you with your certificates in there with your information in there you install it and you off to go. For example, if you would have to put in a username and passphrase you can put this in this file as well if they are missing and we can ask the user for it you're just gonna ask the user for it and say look your username and passphrase is missing can you just enter this one or if this is a private key and you don't provide the private key passphrase it will be asked from the user when they're actually trying to connect to this network. We spent a lot of time documenting this one so this is actually fully documented in a man page we decided to go with man pages since most of the times you would actually be on a system where you have only shell access when you deal with some of this stuff so you're typing man IW network will be easier than actually trying, oh I have to go back to a website and something else. So we decided to put this all into the man pages including the examples, et cetera. Still doesn't fully get us there because we have no standard. This works for IWD we need to get this adopted more broadly that you actually can take these files have the sysadmin generate them for you and then you just can install them. So this is something where we have to find a standard and hopefully this isn't something we're running around for the next five years and don't get anywhere. I hope, so if anybody is interested in this one talk to me because we actually want to get this some sort of standardize that we can actually put network configuration files somewhere and the different demons even network manager with using w-supplicant and use them and configure them because I think going through UIs is no longer possible these days because networks get more complicated. We did one other thing that when the basic stuff was working is that we actually need to get further and I will get into the detail why we're doing this one in a later slide but we didn't stop with just wifi. So we actually had to say, okay look we have systems where we don't have network manager we have systems where we might not even have system in network D your systems that are so tiny that require wifi but we can't spend all these extra cycles and extra complexity. So what IWD was not doing was actually configuring the network interface with the right IP and setting up the routing and anything else. So we said, okay look, we need the IP configuration inside IWD. The reason for this one is pretty simple because there are actually standards where you get the IP address over the wifi protocols. This is pretty much the Tokyo subway problem where you enter the subway for like two seconds and you want to get yourself set up and get a network and just get a quick update of your messages or something else. You don't have time to actually tell other three demons to get status, get the UI start and anything else. You just need to get the address, configure it and move on. Even with the improvements in DHCP speed that we have been doing over the last five to 10 years it was still not enough and sometimes you just want to get this information in-band early on. So we said, okay look, we have to put an option into IWD that actually does network configuration. I know, we have done for Conman one we have done for system D network D one. We are doing now the third one for IWD. At least we know what we are doing but we had to say, look, we have to put this in there. But when it's in there the system becomes really self-contained. So we can start it up. You can use IWD control or client utility if you don't have a UI which acts like a UI with a command line interface and configure your network and get all the status information and we'll do the network configuration for you. The only thing we haven't done is DNS and time so that needs to be handed off to someone else. We have a full DHCP v4 client in it. We have the full network configuration there. IPv6 routing and DNS is available and we just hand off the DNS information to a system resolve or resolve conf setup depending on your system. Which means if you have a tiny system and you don't have anything else on it but you need Wi-Fi, you can just install IWD and you will get onto the network. It's currently in experimental stall. It's work in progress. You need to enable it if you want to use it but we have been using this for testing quite a while and actually on some system I blacklisted assistant network, DN network measure for actually touching my Wi-Fi because I can configure it completely all by myself. Again, fully documented IW config, how you enable it, et cetera. It's a configuration file because the default config will not enable its one just for security reasons, just for stability reasons since I think in some cases we still have bugs there. Okay, the standard problem. Why are taking a feature away from me that I've been doing for the last, I don't know, 15 years or something? We have to change something and here's the reason why we have to change. The goal is that you actually get connected in 100 milliseconds or less. That's a stated goal from a Wi-Fi association how Wi-Fi networks are supposed to operate and that's from nothing to an IP address. So currently with an optimized system we have to spend around 100 milliseconds for scanning. We sometimes spend 100 milliseconds for connecting to this one, including authentication and setup of the keys and we spend 50 to 100 milliseconds for DHCP. We have put a feature into the Linux kernel that is called PAE over a netlink 8 to 11. So historically PAE runs over an Ethernet port and Wi-Fi has been doing this one as well. So just you set up an Ethernet port and you listen to this one and the packets are then forward to the Ethernet port. The problem is, there are two problems with this one. A, it's low and B, it's actually racy. The kernel will schedule your networking packet queues differently from your netlink packet queues, which means you might get on the netlink a message that says connected, but you're missing the information from the four-way handshake that you actually crucial need to actually complete this or vice versa. If you put them both over the netlink socket, they come in order. They come serialized, you don't have to play any tricks, which is again really important for speed because we don't have to wait for anything. We have been adding this by default. It, you don't have to do anything. You can disable it, but it's on by default and will give you four times faster authentication time on the network. So when you're connecting, it's four times faster. If you do this on a system where it's not supported, bunch of full-max don't support this yet, like a broadband one, you're like four times slower. I mean, four times slower. I mean, you're trying to reach a goal of 100 milliseconds. We're not even there yet. And this one adds another 400 milliseconds to this problem. Address randomization. I mean, we really wanna use this. We don't wanna have our MAC address exposed to the access point so it can start tracking us and cross-tracking us. So every time we connect an access point, we wanna connect to it with a different address. Currently, address randomization, the way we have to do it adds another 300 milliseconds to this whole setup. So every time we wanna connect, add this again. So Android folks reported that the address randomization feature in some cases adds three seconds penalty for the whole setup. The reason for this one is the currently you have to do it is you have to power down the fi, which in results will actually also power down the firmware, then you're allowed to change the address and then you can power up your fi, which then reloads the firmware and restarts everything, which is pretty much, there's all your time wasted. While at the end of the day on the air transmission, it doesn't really care when you pick the different address. You just can't pick the different address, even at runtime. We're working on a live address change feature and hopefully at some point this gets into the upstream kernel so we can use it. Currently, it's not there yet. And I have the feeling that we have to set up different kernel repository for all the people that who wanna try out these extra features that we're adding, but upstream is still discussing it and not really wanting us to do it in a way that we get this faster. I mean, the numbers are pretty obvious. So when it comes to upstream kernel features, we cut down our WSupplicant as the problem area where we couldn't get patches in completely. Network Manager has IW supports that are quite responsive and actually taking a lot of these things in and actually making them work. And you can test this on every major distribution right now, but when it comes to actually putting new kernel features and new APIs in there, we actually have a problem, we're still drowning. It's a long process. It takes a while to get things in. It takes a while to actually get this accepted. And there's always pushback for every kind of feature that we say we're gonna do this because we wanna make this faster and so on as well. Let's push back. We reached a level where IWD with the current existing APIs can't work any miracles anymore. We can't make it faster. We can't make it any more integrated. We actually need to have some changes inside the kernel to get things better going. NetLogator tool needs optimizations. They need optimizations badly because in a lot of cases, their stance is that they don't wanna store any state. I mean, if they don't wanna store any state and don't give us exclusive access, other components in your setup can actually mess with you. And that's bad. If you're actually trying to optimize your scanning and you're trying to connect and then someone else, some other entity decides to scan and it goes off channel, you're losing all your speed that you wanted. So you need exclusive access to make things actually say, look, I'm gonna connect now. I'm having 100 milliseconds to connect to. You can't go off to a five gigahertz channel to try and actually figure out if there's another access point or something else. I don't care. So these things are work in progress and hopefully we get them in. The good thing is we can enable them without actually changing the APIs, hence IWD 1.0 being also stable. The answer from the upstream guys ended up a lot of cases this way, which is not what we're expecting. Again, we're working on it. IWD is 1.0. We'll set this in the beginning. The demon itself is around 40,000 lines of code. I think WSUplicant is 400,000 lines of code, so it's still a fraction of it. By the count yesterday, we almost roughly at 2,500 commits just for the IWD demon. So that's quite a lot of people sending patches and we are 28 contributors as of today for the demon. I think it's 44 the whole repository which includes all other things as well. So 1.0 is out. We declare the API stable. So we can use the DBUS API if you want to test it. If you haven't tested it yet, please toy with us. Please toy with it and report bugs back so we can actually see what's broken, what we need to fix. We have been really happy with this one. We have been internally using it. We have been putting this in Fedora, Arch, Clear Linux, et cetera, testing this out also in enterprise setups and it works really, really well. But I have a little bit more. Back to Stan, because Stan tries to sell you nice things and we have been with the background of the IWD project working on some other things as well. So you might have figured out I like three-letter acronyms. We're trying to cut this down. So EAD, Ethernet Authentication Demon, is already upstream in the repository, is doing what WSupplicant does for wired connection when you have to corporate network where they lock down the Ethernet ports. We kind of have a Wi-Fi demon that actually is pretty much have state machines around how Wi-Fi works, having to do your actually Ethernet authentication. So EAD is actually a clean implementation using the same EAP engine, using the same configuration format that we have for IWD, but actually explicitly doing this for Ethernet. So you can start IWD, it will find your Wi-Fi and network interfaces configured. You start EAD, it will deal with your Ethernet interfaces and configured. The interesting part is that we are currently working on improving this one where you actually don't know what your network is. So you plug your cable in and right now what you always have to do is go into UI and change it. Even in MacOS you have to go into the UI and actually, oh look, this is now an enterprise network. You go back and change it. That's actually strictly not needed. If you're smart enough, you can do this automatically. The networks can tell you which corporation they are, you can pick the right credentials. And in addition, if you actually have a network configuration, now comes back the DHCP support that we're having, you can figure out if your DHCP packets go actually through or if you need an extra authentication. So if you integrate this into a single daemon, you can actually do this really fast and get the right path. So if you connect at home, I will just connect you through a DHCP. If you connect this at your work machine, it will figure out all you need credentials. Please tell me what credentials I want to use or if the network identifies itself to you, either with a certificate from your corporation or something else, it can actually say, okay, I already know which credentials to use, please use them. And you don't have to do anything anymore. Pretty much, EAD wouldn't actually ever need a UI except for asking you the information of what credentials should I use if that network doesn't identify itself. You can test it out. It's a really early stage, but we have been testing this in our own corporate network. It works pretty well, but we need a lot of work on this one to improve this as well. APD, Access Point Daemon, it's one of the other project that isn't public yet is where we started off and say, look, hot spot support, personal hot spot support, tethering support is nice, but some people want to actually build an Access Point, a full consumer grade Access Point or even higher grade Access Point, and they currently have to deal with WSupplicant and work around this as well. I mean, we have all the code there. We have all the enterprise code there. We can actually put this back together in an, say, I want an Access Point Daemon. I have to handle certain things in the right way and don't have to actually then reload WSupplicant or trigger certain things or anything else. So I think there's improvements as well. We're trying this out. I hope at some point next year we can publish the initial code for APD to actually get you testing within a real Access Point. It's pretty much interesting just for the companies that are building routers or the open source project that are building routers and I want to not mess with WSupplicant or hack around it. ISD Resolving Service Daemon is pretty much a replacement for SystemD ResolveD and PackRunner and everything else where you actually have to get yourself network information resolved. So we have the problem that the DNS is pretty much the tricky one and you have to get this right. But you also have the things like proxy configurations and everything else that is going on, which we have split over multiple demons. Someone has to feed the information there, then you have to call them, then you have to call another one. So what currently happens, even in a system that you have set up properly, the web browser would actually then find a pack file, process the pack file with the UL you're gonna have, you get a result or you connect to that address and then you actually resolve that address, then you actually connect to this one. So there's a lot of work going on in the background. If you have a setup that is done properly and your things go automatically, right? You want to connect to the Intel corporate entity, you go through the proxy, if you want to go outside, you have to go somewhere else or vice versa and so on and so forth. The idea is that you can just give it a UL, no matter what UL you give it and it will tell you the pass you have to go out of your system. That means you have a simple call into this one, say I want to access HTTP W Linux Foundation and no matter what network you are in, it will tell you have to go through a proxy, you don't have to go through a proxy and so on and so forth. It will tell you all the information. In addition, that's more like things we actually have to look if this will actually work out. If you go HTTPS, it might can give you already back a socket with an encrypted TLS connection that is running inside the kernel. So you would actually have to use hardware exploration automatically. We are using the key subsystem already, we are using the kernel crypto subsystem already. So at the end of the day, giving you back a TLS socket where you just have a plain socket that's already fully encrypted and authenticated and everything else is easy for us. But this is something we're toying with. I don't expect this to be released anytime soon because it's still in early testing phases and see what we can do, but this is the next step where we say look, this is one part of the network configuration to make this fast for everybody. We have to deal with this one. The initial test works pretty well and we can actually pretty much give you back the IP address if you just give in a UL and we can also hand you the IP socket, sorry, the TCP socket for some parts of the TLS power portion if you have enough and recent enough kernel for this one. With this one, I'm actually done and I think pretty much good on time. Any questions? One over there please. Can I give you the microphone because I can barely hear you. You told that you plan to move some parts of IP configuration to IWD, but is it going to still to work with Konman in this case? That's how they arrange who is responsible for IP configuration. So it's still going to work with Konman. So the Konman support for IWD is a little bit lacking in functionality compared to the network manager support. Wasn't planning this way, just happened this way that network manager got a higher priority. We're going to fix this up and then you will see the same functionality with Konman, with this network manager when using IWD, but Konman has IWD support. It just needs a little bit extra $10 to use all the features that we have put in there. So in the end, they should work together, transparently, for the end user and they will decide among them who is responsible for IP configuration, right? Yes. Okay, thanks. Any other questions? We'll show that. So he said that he had problems with it going back from suspend. So ping us again and we need to figure out where this is lacking. I think the thing I noticed is that you have to restart both of them but in an order and then it just connects instantly. So this is a problem that has been reported. There are some other problems where outloading of RFKill wasn't existing upstream, et cetera. So there's few things we need to fix that this starts properly. But the general idea is you shouldn't be needing to restart IWD. It should run for as long as your system isn't rebooted. If you go to suspend and go back, it should just figure this all out. And if there are bugs, we have to fix them. IWCDL doesn't report any stations known and you can't get it to scan. It's basically like the interface has disappeared during suspend. I don't want to blame the firmware but sometimes it might be the firmware. Oh, you can blame the firmware. It's an Intel card, so you can blame the firmware. So sometimes it's good to test it with a different card if you have the capability to do this. No, I'll try to send a bug report. I just wanted to know if it was known. Over there, please. You said there's an access point mod to do tethering, for instance. How does that interact with your work-in-progress DEMON APD? Is there any link or is it just separate? No, there will be no link. So generally, if you want to run an access point, you would have to have two or three physical network cards anyway because you need a separate 1.2.4 gigahertz, a separate 1.5 gigahertz, six gigahertz, and so on. And if you want to do some scanning or something else, you might actually need another one as a current operation. So access point D is really just if you want to build an access point. Not if you want to, your primary use gets a station mode and every now and then you switch onto tethering. That's the idea behind it. So it's really just for WRT or something else that actually want to run this in access point all the time. Okay. I can tell you router vendors actually want to make access points with two radios where they use one radio both at the same time as a station and as an access point. So I'm afraid it is necessary to have both running at the same time. So at the moment they're running WPA supplicants and host APD at the same time on the same radio, but I don't think it's ideal. Okay, so I know what you're talking about. So pretty much if your backhaul isn't a wired connection and you have to do this over the Wi-Fi interface as well to actually synchronize all your access points or even get the data across. So in that case, the APD would actually get portion of the client as well to do that because it's the only sensible way to do this because otherwise you can't coordinate it. But on a laptop, you would be running IWD on an access point, you would be running APD. And since it's the same code base, we can actually share that code around if we have to. Frankly, I would put another PHY in there because it's way more stable than trying to share PHY. Just FYI. There's nothing, okay, sure. I think we have another few minutes. Okay, yeah, thank you for your presentation. I got a question regarding the scanning. Do you use active scanning for faster network finding? So we stay away from active scanning as much as possible. There's a few cases where you have to do this. Pretty much if you configure hidden network, you shouldn't do this in these days because there's no standard for hidden network. Then we have to do active scanning. Otherwise we're gonna stick with passive scanning while knowing that there's a little penalty that you're gonna get. We encounter the penalty when you say, look, when the UI comes and find all my networks, then we have a little penalty. When we actually do scanning for an access point that we already know where it's supposed to be, the penalty can be neglected because we only pick that channel. And that specific SSID. So that's probably, if you can measure it, awesome. But I think it will be in such a tiny portion of a millisecond that who cares? I mean, it should be with a typical interval of 100 millisecond beacons. It should be in the range of, it could save you maybe 50 milliseconds or so. Maybe, we haven't encountered this as a big issue. Because in most cases, once you actually give all CSSD, the firmware reports the results really quickly. So this can be optimized. The problem is if you take active scanning, you're revealing your MAC address again. So there you have to value privacy where there's that few milliseconds that you're gonna spend. But yeah, we know that the passive scanning takes longer. If there's nothing else, then thanks everybody and have a good day. Bye.