 Hey, welcome everybody. So, I'm gonna talk a little bit about IWD for the next 20 minutes. Um, and I've been doing this a while now, so you've been spent on redoing Wi-Fi for a little bit. Um, the problem is Wi-Fi Linux still sucks. It's still not really where we want it to be. We have, if you're still wanting WP-supplicant, I feel sorry for you, but even with IWD, we have not really fully achieved where we wanted to set out. So, around five years ago, we set out to just redo it. Um, and same as Guybrush back in the days then asked what he has to do, the answer was you have to do X, Y, Z and X, not what you keep running around and trying to fiddle with things. Um, everybody else who actually worked on Wi-Fi with the Linux system had to do the same thing. Um, this is from about a year ago. It's still better than it was around five or ten years ago. It was even worse. But you still had the thing where, um, if you're in the shoes of network manager or con man back in the day, so any kind of system that actually needs to manage the Wi-Fi, you're running around and picking up bits and pieces. So it has to talk to W-supplicant. It has to talk to the Netlink interface directly because W-supplicant doesn't give you all information. Uh, why? Nobody really knows. It chooses not to. Um, then you have to store your neural network somewhere. Then you have to figure them out what they were. Then you have to pick them back together. Um, then you have to talk to RTNL to do the configuration. Um, interesting enough, uh, around two or three years ago it was still simpler because you basically only fill it with W-supplicant and the Netlink interface. Um, but then people wanted more stuff. They wanted roaming. They wanted to hotspot set ups. They wanted something else. So the UI got involved and actually tried to even circumvent a network manager. I think the state right now is that a lot of things in the UI, especially in the UI, has been gone a lot better. They have removed some of these hacks, but if you look at the Chrome OS system, um, the UI, uh, pretty much the Chrome browser still fills us around your back and does certain things, um, which is bad. Um, interesting enough what we found about, uh, months ago is the DHCP CD, which network manager still used. I hope they're going to drop this. Now at least I saw an announcement. They're going to drop this and use the DHCP library properly. It's still at some point decides to dump your Wi-Fi interfaces. I mean, what's going to do with it? Nobody knows. Um, we have a tool IWM on that actually monitors everybody who's doing something. So you see that a certain request come in. So if every process in your system at some point starts to dump certain information of your Wi-Fi networks, you really don't ever get anywhere. Even mind that actually might actually fiddle behind your back behind it to start to scan, for example. You're trying to be optimized and do something, but then, oh, I want to scan now on all channels and you waste like two seconds finishing into a five gigahertz scan while you start to roam. Bad things happen if you mess these things up and don't have the self-contained. So you feel like talking to Stan and he tries to sell you everything and God knows what. It's all the great things you're going to have, um, which is great, um, unless you end up with a boat and nobody's doing anything. Um, and that's where we were stuck around five years ago. Um, we have made a lot of progress and right now the system actually looks like this. Um, you can run IWD. Our network manager has an IWD backend. You can just switch it on with a configuration file. I think it even lands in most distros. Um, and then IWD takes care of your Wi-Fi. So network manager, all the support in network manager for Wi-Fi stays pretty much dormant. It doesn't do anything because we do everything for you. We remember the networks. We automatically roam for you. We know when to roam. We know when to scan. We know actually how to talk to the access point when your signal goes weak and say, look, don't you have a better access point in your vicinity that we can use? Um, even if the access point would ask us to do something for it like scan on, on his behalf, we could do this as well. So a lot of things have gotten a lot easier and a lot simpler. So at the end of the day, you can trust IWD to do everything. It's pretty much, I give you the passphrase. You remember it and you reconnect. So pretty much up and running. Um, and then we hand the information back out. So network manager becomes readjusted shim with everything else. Um, oopsie. This is kind of nice. So what do we get? We have a really centralized database. So I really know about every network you're connected to. It knows what frequency you're connected to. It knows what passphrase is used. It knows what security credentials used. It knows really everything. We store this and we can reuse next time. Um, that means if you actually want to reconnect the network you've been before, you know you've last time you saw it on channel nine and 2.4 gigahertz, it takes you roughly around 100 milliseconds to actually find it again. Not like three or four seconds. So you can't open that laptop you're fast and it will be back on the network. Um, it supports WPA personal and enterprise. So all the known enterprise provisioning networks are supported. Some edo rooms configurations are still kind of weird. People sending us requests for we can't make this university network work. We trying to fix them. I think we pretty much down to a few of them where it didn't work. I heard some rumors that edo room wants to actually use a more streamlined approach to this one. Hopefully they get to this one and then this becomes all a problem of the past. Since IWD is the only entity that actually scans, all our scans are completely optimized and when possible anonymous. That means we don't leak your MAC address when we don't need to. So they're all passive scannings if you can. By the way, hidden network is the problem. You can't do passive scanning so don't use hidden networks. Um, and, uh, we only scan what we really have to. So unless you actually have a UI that tells you I need the full spectrum because you have to find a new access point you will never see it trying to scan the full spectrum unless you close your laptop, go to another country, open it up there and actually don't know it finds everything and doesn't find anything it used to have before. Otherwise it's really optimized. If you roam or if you do any operation where you have to scan it really only scans that particular channel, um, that you ask for. So we do roaming. We do roaming internally so you don't have to, uh, from the UI or network and tell it to roam. If the signal goes down, we ask the access point where is your next access point. If you know if you have a mesh, a mesh, a set of access points that are meshed or you have multiple access points together or corporate network, they mostly will tell you where the next access point is. And we know this then and we can scan for this one. So our transitions, you can pre-authenticate them so meaning all the transitions go really, really fast. So you don't really have to waste time. Uh, we do the resource management as well so we even could scan on the behalf of the access point if they need to fight, okay, is the access point closer than the other one, etc. and so forth. Um, WPA3, um, is on by default. You don't have to do anything. If your access point supports WP3 you will get authenticated with a WP3. With your existing credentials if you have them, if you have to update your credentials because you only stored the uh, the passphrases, uh, you didn't store the passphrases. We will ask you again to provide the passphrases otherwise it's completely automatic. Um, which is kind of nice and it doesn't have the fact that you, oh, you don't understand WP3 and all of a sudden your network is considered open or some weird situations. Um, you don't have to update the UI code or anything else. It's all the same operations. Um, OWE, uh, Openistic Wireless Encryption means you can get, you can get an open network, but you get it encrypted. Um, you don't have any man-of-the-mill protection if you connect to a, like a coffee shop hotspot. But if a coffee shop hotspot will support encryption you at least your link will be encrypted. You can still be spoofed but at least nobody can actually just, uh, pass away sniff your traffic there. Um, the app engine is integrated into IWD. So we ship our own eApp engine, uh, with most support for everything. Um, recently we added hotspot 2.0 support. So if you have any kind of hotspot networks, uh, where you can use your SIM card or any other credentials to authenticate, uh, they will work as well with all the things that come with it. I don't think anybody has managed to set this up with WSupplicant. It's all manual handling and manual testing. This is the first time I think it's a fully integrated system where this, uh, just works on a Linux site. Um, and we do heavily address randomization for privacy reasons. I already mentioned that we don't, uh, we always scan passively. We don't scan actively if we don't have to accept hidden networks. But we also can do address organization on a per access point basis. So if you connect to the next access point, we're going to make up a new address, uh, and use that one. And we store the used address and so on and so forth. So next time you connect to that point you will be, uh, other with use the same identity so you can reuse your DHCP information and don't get a randomly new one. Um, that's all handled internally. So network manager when it uses IWD doesn't have to do anything of this for you. It will just be done. And it can be on by default. Um, so this is all there as of today. It works really well and you can just use it. Um, we didn't really quite stop there because we needed to go a little bit further. And a little bit further is where people might go to scratch their heads now. So IWD contains network configuration set up. So you can run IWD and bring it all to have your route set up and tell the system to resolve what the DNS servers are. Um, this needs to be done for really embedded systems where you don't actually have the luxury of running network manager or anything else and where you really only have Wi-Fi. So why bring another three or four systems that are trying to manage this one. So it can do this everything internally and actually set up all your network configuration as well. So it moves the code and it's down. Right now it's a configuration option. You choose one side or the other. It does automatic configuration and hence everything off or it doesn't. Uh, it's off by default. That's what's used inside when you run this on a fedora with a network manager. Uh, it's currently still limited. Uh, we only have DTPV4 support. The V6 support is coming in. The network configuration is rather limited. Uh, and we only support system resolve D and resolve conf callouts for the Debin users that actually don't have resolve D running. Um, we don't want to mess around with ETC resolve conf writing directly or anything else. Then I mean at that point it's like, whatever, hack this together by yourself because you're running on a really dedicated system anyway. Um, this is experimental. Uh, it actually works really well but used with caution because you might actually screw things up if you have something else running on the system. Um, I pretty much see everybody screaming right now, um, because we actually took things away from everybody else. Um, we had to do this for the simple reason because the goal is really we want to connect in 100 milliseconds or less. And if you want to get to the internet connection fully completed at 100 milliseconds or less, you have to do things differently. You just can't go and oh I spent another second here, I spent another second there. So right now, uh, we have a tool, um, IW lock which isn't public yet but will be in a couple of weeks that actually you can even use with WSYPLICN or system in network D or network manager or anybody else to actually check what time spent at what step of the configuration process and it tells you, okay, this took like a X amount of milliseconds on a force. So in a, in a good setup at home, you have around 100 millisecond that you just need for scanning and it's not really an optimized piece of hardware if you might need to use a newer one where you actually have a better transceiver and you might get a little bit faster but the scanning is really when you know you can only scan one channel on 2.4 gigahertz to see if the access point is there and get the information element back from it. That's what you need right now. The only way to make that faster is by have a better firmware or have a better transceiver in your hardware. There's nothing IWD can do about it. Um, the connection time by doing the association with the 4-way handshake is another around 100 millisecond. That's also what it takes. You have to get the data over the year. You have collisions over the year and that's around 100 millisecond you need as well. DHCP has been really fast since the early days of call man with system D network D having this also. So there was really no surprise that we got this down to 50 year between 50 and 100 milliseconds. You still have a 300 millisecond that you need to actually get from, I have the card up and running and actually connect to the network. We are not there at the 100 millisecond time. Interesting enough IWD runs PAE over a netlink A2 to 11. I don't know if anybody knows the difference but normally WSIP opens the AF packet socket to run the PAE packets for the 4-way handshake. We put a patch into the kernel that you can run these as part of the netlink protocol so it gets you get a frame in the netlink protocol. We did this mainly so they get coming order with the netlink messages because the kernel schedules the AF packet queue differently than the netlink queue which means you could might get your connect association response earlier or later than the PAE packets and then you have this out of order problem that you have to re-sort them back together and you really don't know what it's doing. So this one actually makes sure that it comes in order because over the air it's in order as well. The interesting artifact of this one is it's 4 times faster than doing this on AF packet socket. So if you want to do this set of AF packet socket you end up instead of 300 milliseconds you end up with 1.2 seconds. That's a massive difference by just how AF packet works and how much overhead it actually consumes by installing the BPF filter and so on and so forth. So there's a big speed up already there. The problem is on these 300 seconds if you want to do address randomization you have to add another 300 milliseconds as well because the only way to do address randomization is you power down the interface and you power it back up with a new address. It's the only way to do this right now. The problem is most hardware unloads the firmware and have to reload the firmware so wasting a lot of time to just get you back up. So if you have 1.2 seconds by doing W-supplicant with PAE over AF packet socket you're doing address randomization by power down over RTNL at another 300 milliseconds you have 1.5 seconds. 1.5 seconds is really far away on the 100 millisecond goal. The Android people on Chats and bug reports reported that the address randomization can add a penalty of 3 seconds. If you don't want it that's fine. I've seen comments on the web as well that's like why are you going to do this but for privacy reasons you really want to do address randomization for every point you're going to have these days. So we have achieved a lot but we are still drowning with the last bits and pieces to get them right to make this really constantly have privacy enabled, have the full security working and have this really, really fast. We're at the level where we can't work any more magic. IWDU has really worked all its magic it can do but we have been using the existing interfaces with the existing kernel patches that we put in there with the existing things we actually took out and put somewhere else. That's pretty much as fast as we can go right now. So we need Netlink 802 optimizations. We need to change the kernel APAs in a massive way where you say look every millisecond counts. I mean if you send me a full Wi-Fi dump of the network and then I have to dump it again because you're missing some important information because I need that flag to decide how I'm going to operate. Something is wrong and that's how it works sometimes because of some legacy reasons and some bug fixes that are problems but they're not really problems because all user space has moved on and we have to do a lot of round trips to the kernel. People think that the round trips through kernel don't matter because system calls are really cheap but if you have a tight goal of 100 milliseconds these round trips matter. So bunch of patches on the mailing list to actually change things. Bunch of patches to actually do address randomization based on the connect so we can give you the address on the connect to use and some cards do live address changes. They support this actually. We end the situations. We're trying to give them something and so far we have not got taken them. I have currently no idea how we're going to reach the 100 millisecond goal but we need to go there at some point so we have to see how this goes. We'll try to make this better but currently it's a fight to get the things into the kernel that we actually can make things differently. WSupplicant is going to continue as it is. IWD is currently better and faster but what are you going to do about this? So IWD 021 is the latest. We haven't got to 1.0 release. I think I promised this for Christmas last year. I ended up doing, it's just a number at the end of the day but we haven't sat down to actually say look this API is totally fine. Now someone is working on P2P support so they're putting P2P support in there so we get this as well. Someone can toy with this one. The API looks really easy and simple so if anybody wants to go back and work on wireless display they can. Yesterday I talked to Leonard and he said his measuring point for how big system D is is still WSupplicant and I was a little confused by that statement. It's like okay I was pretty sure system D is actually larger in source code lines than WSupplicant. So today I did a count. So WSupplicant with everything in it counts around 400,000 lines of code. I was like okay what? Okay they have a lot of stuff in there and a lot of things that duplicate and they're on every OS on the planet and so on and so forth but even if you just look at the supplicant pieces they end up still with plus 300,000 lines of code. I mean then I said okay let's take IWD. The pure demon is 140,000 lines of code. With tools and unit tests and everything around we had 70,000 lines of code. That's still a portion of what WSupplicant actually provides. I said okay that's not too bad. So we did 2,500 commits roughly in the last five years and we ended up with 27 contributors. So I feel pretty happy that at least from a maintainability and code review point of view I think we have done the right thing there. So anybody wants to actually go out and test this. There's an easy switch in Fedora and probably most other distros where you can just install it. Please tell us what isn't working. I mean we have covered most cases. We have outer tests and unit tests for all the heavy things but there's slight and slight variations especially AdoROM networks etc. where things actually don't work. Enterprise network setups if you use them please tell us if they don't work because we're really trying to make this rock solid and workable. And with that one I'm even this time under my 20 minutes. Thank you so much. Questions? I think you go first. It's so much more wonderful than WPA's applicant. What are the current regressions for a normal laptop use case? Since it's so much good I wonder why everybody's not using it yet. So I think why it isn't actually on every distro by default is why we haven't pushed for it. So I think every distro packages it now. Then making the switch takes a while. Nobody's thinking oh we're going to ship something different by default then we have to do with these kind of bugs again if we have some. We have to start pushing for that when it actually gets changed as default in the major distros. But I think everybody has packaged it right now so you can pretty much do an up-get install, yum install or DNF install and then switch the one-liner network manager to make it use. But there will be other bugs coming. We try. That's the next step. Or was there something more to your question? I think there was another one over there. Thanks for the great software. I've been using it for a couple of months now and it actually works very well. For my use cases at least I just have a slight regression or bug or problem in a system D network D context basically where there's this race condition about naming it. It's a bit annoying and do you have any idea how to fix that? The stuff he's talking about is that IWD is too fast. Normally you have system D and system network D introduce the concept of persistent naming. So the interface names are named at a different pattern or something. Actually UDef is too slow and I'm bringing this up so once we already started up and running we will have that interface active and we own it. IWD on some cards actually gets one step further. We actually take all the interfaces away and re-create them. The existence of a network interface with Wi-Fi is a legacy artifact from back in the days that doesn't need to be there. You can do all the Wi-Fi operations for the control path without having the network interface present. The network interface is just the control path. In some situations we actually just remove them all and put them back together. Any kind of naming that you set up is pointless anyway because we keep redoing it. For people that want to have the proper naming for us the only way is to wait until UDef actually finished. It's time wasted. I don't have a good answer for this one. I think I looked at actually because system D network D can do it but it's for UDef to finish. We actually don't look at UDef at all because we don't care because we're told that the interface is there from the Wi-Fi side. I don't have a good answer for this one. Is it that important? It was just kind of a weird annoyance by first using it. All of a sudden your network naming is different again than a lot of configuration breaks. So my personal viewpoint on this one in two or three years is actually IWD do all the network configuration and network D and system D network and I will just follow it. These systems the connection has become unresponsible for setting the right route and the route metrics while the IP configuration of the interface itself it's something that's so fundamentally Wi-Fi specific especially with the new specifications that are coming in where you actually get your IP address already based on the association. So we don't actually need to run DHCP to actually set the interface information. So what we would have to do, we have to pass that back up to the stack so the stack gets then to get it passed back down. It's like why? We already knew what it's supposed to be because the access points give you the IP address within the information elements or some of the action frames. I think that's going to change really quickly. Just a closing question because you didn't really cover this in your talk but do you have any, sorry if I hog the mic but can you tell something about the access point usage with IWD because that you didn't really cover and how that's compared to host APD for instance? So we have the basic access point support so you can switch IWD in a way that it becomes an access point. It's a really rudimentary setup, same as network manager uses, same as everybody else uses. The work on actually having a host APD replacement is ongoing but there's nothing substantial there. That's actually another completely different branch, different ballgame somewhere. We are working on that one as well. So right now you can just set up an access point and then you have to attach it to a bridge and then run your usual stuff. So that works, same as what network manager expect. I think it's even integrated network manager. If you click on the UI there say create an exploit, it actually does work as well. Maybe now you have a question but why does MAC address ram demization causes so much penalty? Can't you just like regenerate them and use one out of the pocket and it should be the same as the native one. So the way you currently have to do it, you have to if down the interface. You have to power down the PHY, this unloads the firmware, then you have to reload the firmware and boot up all your transceivers etc. That's where the big penalty is coming from. We have patches where you can do live address changes. We have a huge discussion, they're not getting accepted and they say I'll just put down the firmware. It's not whatever, who cares. Yes, please. Okay, so apart from that bit, my question is a bit of a follow up on that. You said some cards can do it, as in the card and firmware can do live address changes. Can Intel cards do that? Yes they can. Excellent. So it's pretty much everything that's run on a lot of things that are run on Android 11 based, so soft Mac cards can do it. There might be some slide variations, some of them can't. Full Max card is always the thing is like do they do it or don't they do it. You can always have a new firmware that can do it. It's really no problem. On your website is there a site where all your kernel patches and so on is linked or how can one find them? No. It's on Linux wireless mailing list. Our goal is to get the patches actually into the kernel. But is there like a tag in the patch line also one can look for? Because I guess Linux wireless this is quite high traffic, so it's hard to find those. It's not high traffic, but it is traffic. Okay, my definition of high traffic is kernel mailing list. Never mind. No, I don't think so. We can make this happen. If someone wants to toy with this one, we can see if we get this on the Wiki of the IW Wiki and say look, these are the patches you can test out. And the second thing I want to note that from the core boot perspective or booting Linux fast, I think there's the same problem that there's a lot of parts in the Linux kernel where there's a lot of sleeps and so on which are much too long especially in graphics cards which really hurt performance. So if you have an idea how to force developers to not do this like in review that's for example to justify everything which takes longer than 10 milliseconds or so, I'm open to suggestions but I hit these problems a lot in storage and in graphics especially. So the way with any connectivity technology is that if you don't program it asynchronously, you're going to get screwed anyway. IWD is fully asynchronous compared to WSimplican which is a lot of synchronous operation and that gets to bite you. That's why we sometimes get the speed, that's why we faster than UDF actually to grab the interface and just own it. So the most you can make asynchronous, the better you can make any decisions and get this going. So that's my only recommendation. It doesn't work always. With file systems and storage you have blocking operations that need to be blocking because they need to be synchronous. With wireless technologies it's a little bit different because they are by its nature. Awesome synchronous. I think my time is up now if I've got this right. So thanks everybody have a good day.