iwd - State of the union
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 44 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/46121 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produzent |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
All Systems Go! 201920 / 44
5
10
17
20
21
30
32
36
44
00:00
AggregatzustandBitComputeranimation
00:32
Physikalisches SystemComputeranimation
00:53
SystemprogrammierungOpen SourceRechnernetzSoftwareGewicht <Ausgleichsrechnung>BitBrowserMetropolitan area networkGraphische BenutzeroberflächePhysikalisches SystemInformationPunktKonfigurationsraumInterface <Schaltung>ProgrammbibliothekVerschlingungTropfenNetzwerkverwaltungAggregatzustandZweiUltraviolett-PhotoelektronenspektroskopieProzess <Informatik>DiagrammFlussdiagramm
02:52
Grundsätze ordnungsmäßiger DatenverarbeitungArithmetische FolgePhysikalisches SystemComputeranimation
03:12
SystemprogrammierungOpen SourceRechnernetzNetzwerkverwaltungPunktPortscannerSoftwareInformationNormalvektorKonfigurationsraumDiagrammFlussdiagramm
04:09
Open SourceDatenbankRechnernetzCorporate NetworkBetriebsmittelverwaltungDesintegration <Mathematik>DatenmissbrauchRandomisierungAdressraumSystemprogrammierungPunktMessage-PassingSoftwareFrequenzDatenmissbrauchAdressraumMultiplikationsoperatorPunktspektrumNetzwerkverwaltungDefaultDatenbankSchnittmengeInformationsspeicherungRandomisierungOSS <Rechnernetz>ComputersicherheitPhysikalisches SystemIdentitätsverwaltungMehrfachzugriffDrahtloses lokales NetzPlastikkarteGruppenoperationInformationSoftwaretestBasis <Mathematik>KonfigurationsraumCodeUnternehmensarchitekturZweiSimulationVerschlingungDatenverwaltungPortscannerGrundraumSystem FPolygonnetzSchlüsselverwaltungVererbungshierarchieChiffrierungOffene MengeApp <Programm>Notebook-Computersinc-FunktionMetropolitan area networkLeistung <Physik>Umsetzung <Informatik>Computeranimation
08:40
Spezielle unitäre GruppeSystemprogrammierungPhysikalisches SystemOpen SourceRechnernetzBitSchreib-Lese-KopfSoftwareKonfigurationsraumServerDefaultPhysikalisches SystemDirekte numerische SimulationNetzwerkverwaltungKonfiguration <Informatik>CodierungResolventeRoutingComputeranimation
09:35
Offene MengeClientDesintegration <Mathematik>Dynamic Host Configuration ProtocolKonfigurationsraumRechnernetzPhysikalisches SystemResolventeSystemaufrufSoftwarePunktDivergente ReiheKonfigurationsraumComputeranimation
10:10
Pi <Zahl>Offene MengeRandomisierungPortscannerDynamic Host Configuration ProtocolZweiMultiplikationsoperatorPhysikalisches SystemPlastikkarteLeistung <Physik>VerschlingungSocketInformationRandomisierungHardwareDifferentePunktAdressraumSchedulingElement <Gruppentheorie>Kernel <Informatik>Message-PassingBitInelastischer StoßProtokoll <Datenverarbeitungssystem>FirmwareGüte der AnpassungUnrundheitRahmenproblemLastEinfach zusammenhängender RaumSoftwareOrdnung <Mathematik>EinsAssoziativgesetzInterface <Schaltung>Gewicht <Ausgleichsrechnung>Selbst organisierendes SystemAuthentifikationRechter WinkelVollständiger VerbandForcingProzess <Informatik>Patch <Software>Overhead <Kommunikationstechnik>InternetworkingDatenmissbrauchVerkehrsinformationMetropolitan area networkMereologieVererbungshierarchieCodeExogene VariableWellenpaketNetzwerkverwaltungKonfigurationsraumSchnittmengeMehrrechnersystemChatten <Kommunikation>WarteschlangeHumanoider RoboterProgrammfehlerComputeranimationTafelbild
13:56
ComputersicherheitDatenmissbrauchBitMAPPatch <Software>Interface <Schaltung>Kernel <Informatik>Computeranimation
14:20
SystemaufrufProgrammfehlerUnrundheitSpeicherabzugPlastikkarteZählenMinkowski-MetrikFahne <Mathematik>Kernel <Informatik>AdressraumE-MailPatch <Software>RandomisierungInformationSoftwareMailing-ListeMathematikComputerspielGlobale OptimierungComputeranimation
15:22
DifferenteStochastische MatrixKernel <Informatik>PunktZeichnung
15:56
System-on-ChipKomponententestPhysikalisches SystemSoftwarewartungCodeZählenMultiplikationsoperatorGeradePunktSoftwaretestZahlenbereichSoftwareDämon <Informatik>QuellcodeEuler-Lagrange-GleichungDatensichtgerätUnternehmensarchitekturSichtenkonzeptRechenschieberVererbungshierarchieCASE <Informatik>MultiplikationWeb SiteComputeranimation
17:53
SystemprogrammierungOpen SourceMultiplikationsoperatorDefaultGeradeNotebook-ComputerKontrollstrukturInformationSoftwareKonfigurationsraumEinfach zusammenhängender RaumInterface <Schaltung>RoutingCASE <Informatik>PlastikkarteElement <Gruppentheorie>ProgrammfehlerProgrammierungsinc-FunktionMathematikSoftwareentwicklerLineare RegressionDisjunktive NormalformPunktFirmwareNormalvektorInformationsspeicherungInstallation <Informatik>AdressraumKernel <Informatik>BitWeb SiteE-MailMailing-ListeDrahtloses lokales NetzPatch <Software>InstantiierungKonditionszahlDateiverwaltungNetzadresseRahmenproblemSynchronisierungDifferenteKontextbezogenes SystemOSS <Rechnernetz>Abgeschlossene MengeRandomisierungNetzwerkverwaltungWikiExistenzsatzBootenBridge <Kommunikationstechnik>MereologieGamecontrollerLeistung <Physik>AssoziativgesetzKartesische KoordinatenUmwandlungsenthalpieSpeicherabzugErwartungswertKreisflächeEntscheidungsmodellVerzweigendes ProgrammPhysikalisches SystemSummierbarkeitComputerspielSicherungskopieNatürliche ZahlGruppenoperationLokales MinimumRechter WinkelEuler-Lagrange-GleichungSinusfunktionMusterspracheFatou-MengeCodeApp <Programm>Notepad-ComputerPerspektiveGraphikprozessorComputeranimationVorlesung/Konferenz
26:56
Web SiteSystemprogrammierungVollständiger VerbandComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:05
Hi, welcome everybody. So I'm gonna talk a little bit about IWD for the next 20 minutes. And I've been doing this a while now, so you've been spent on redoing Wi-Fi for a little bit. The problem is Wi-Fi Linux still sucks.
00:20
It's still not really where we want it to be. We have, if you're still running 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. And same as Guybrush back in the days then asked what he has to do,
00:41
the answer was you have to do X, Y, Z, and X and Y to keep running around and trying to fiddle with things. Everybody else who actually worked on Wi-Fi with the Linux system had to do the same thing. This is from about a year ago. It's still better than it was around five or 10 years ago, it was even worse.
01:00
But you still had the thing where 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 WP-Supplicant, it has to talk to the Netlink interface directly because WP-Supplicant doesn't give you all information, why, nobody really knows, it chooses not to,
01:22
then you have to store your known network somewhere, then you have to figure them out what they were, then you have to pick them back together. Then you have to talk to RTL to do configuration. Interesting enough, around two or three years ago it was still simpler because you basically only fiddle with WP-Supplicant and the Netlink interface.
01:41
But then people wanted more stuff, they wanted roaming, they wanted hotspot setups, 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 GNOME UI, has been gone a lot better. So they've removed some of these hacks, but if you look at a Chrome OS system, the UI, pretty much the Chrome browser,
02:00
still fiddles around your back and does certain things, which is bad. Interesting enough, what we found about a month ago is that DHCP CD, which network managers still used, I hope they're gonna drop this now, at least I saw an announcement, they're gonna drop this and use the DHCP library properly, it still at some point decides to dump your WiFi interfaces.
02:20
I mean, what's it gonna do with it? Nobody knows. We have a tool, IWMON, 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 off your WiFi networks, you really don't ever get anywhere. Even mine that actually might actually fiddle behind your back, behind it, or started a scan, for example.
02:40
You're trying to be optimized and do something, but then, oh, I wanna scan now on all channels and you waste like two seconds finishing 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. 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 gonna have, which is great, unless you end up with a boat
03:03
and nobody's doing anything. And that's where we were stuck around five years ago. We have made a lot of progress, and right now the system actually looks like this. 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.
03:23
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,
03:40
look, don't you have a better access point in your vicinity that we can use? Even if the access point would ask us to do something for it, like scan 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,
04:01
so pretty much up and running. And then we hand the information back out. So network manager becomes really just a shim with everything else. Oopsie, this is kinda nice, so what do we get? We have a really centralized database. So IWD knows about every network you're connected to, it knows what frequency you're connected to,
04:21
it knows what passphrase is used, it knows what security credentials are used, it knows really everything. We store this and can reuse next time. That means if you actually wanna reconnect the network you've been before, you know you last time you saw it on channel nine on 2.4 gigahertz, it takes you roughly around 100 milliseconds to actually find it again. Not like three or four seconds.
04:41
So you can't open that laptop, you're fast and it will be back on the network. It supports WPA personal and enterprise, so all the known enterprise provision networks are supported. Some edu-rooms configurations are still kinda weird, people sending us requests where we can't make this with our university network work.
05:01
We're trying to fix them, I think we're pretty much down to a few of them where it didn't work. I heard some rumors that edu-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
05:21
and when possible, anonymous. That means we don't leak your MAC address when we don't need to. So they're all passive scanings if we can. By the way, hidden network is the promo, you can't do passive scanning so don't use hidden networks. And we only scan what we really have to. So unless you actually have a UI that tells you I need the full spectrum
05:41
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 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 that you asked for.
06:00
So we do roaming, we do roaming internally so you don't have to, from the UI or network, not tell it to roam. If the signal goes down, we ask the access point, where is your next access point? If you have a set of access points that are meshed or you can 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.
06:22
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. We do the resource management as well so we even could scan on the behalf of the access point if they need to find, okay, is the access point closer than the other one, et cetera, and so forth. WPA3 is on by default.
06:40
You don't have to do anything. If your access point supports WPA3, you will get authenticated with a WPA3 with your existing credentials if you have them. If you have to update your credentials because you only stored the pass phrases, you didn't store the pass phrases, we will ask you again to provide the pass phrase but otherwise it's completely automatic. Which is kinda nice and it doesn't have the fact
07:01
that you don't understand WPA3 and all of a sudden your network is considered open or some weird situations. You don't have to update the UI code or anything else. It's all the same operations. OWE, Openistic Wireless Encryption, means you can get an open network but you get it encrypted. You don't have any man-in-the-mill protection if you connect to like a coffee shop hotspot
07:22
but if a coffee shop hotspot will support encryption, at least your link will be encrypted. You can still be spoofed but at least nobody can actually just passively sniff your traffic there. The EAP engine is integrated into IDWD so we ship our own EAP engine with most support for everything. Recently we added hotspot 2.0 support
07:40
so if you have any kind of hotspot networks where you can use your SIM card or any other credentials to authenticate, they will work as well with all the things that comes 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 just works on a Linux side. And we do heavily address randomization for privacy reasons.
08:03
I already mentioned that we always scan passively, we don't scan actively if we don't have to, except hidden networks, but we also can do address randomization on a per access point basis. So if you connect to the next access point, we're gonna make up a new address and use that one. And we store the used address as soon as also next time you connect to that point you will use the same identity
08:22
so you can reuse your DHCP information and don't get a randomly new one. 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. So this is all there as of today, it works really well and you can just use it.
08:41
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 wanna scratch their heads now. So IWD contains network configuration setup. So you can run IWD and bring it all to have your route set up and tell the system
09:01
to resolve what the DNS servers are. This needs to be done for really embedded systems where you don't actually have the luxury of running a 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.
09:23
So it moves the codemas down. Right now it's a configuration option, you choose one side or the other. It does automatic configuration and hands everything off or it doesn't. It's off by default, that's what's used inside when you run this on a fedora with a network manager. It's currently still limited. We only have D2P v4 support.
09:40
The v6 support is coming in. The network configuration is rather limited and we only support system resolve D and resolve conf callouts for the Debian users that actually don't have resolve D running. We don't wanna 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.
10:01
This is experimental. It actually works really well but use with caution because you might actually screw things up if you have something else running on your system. I pretty much see everybody screaming right now because we actually took things away from everybody else. We had to do this for the simple reason because the goal is really we wanna connect
10:24
in 100 milliseconds or less. And if you wanna get to the internet connection fully completed in 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 we have a tool, IW lock,
10:40
which isn't public yet but will be in a couple of weeks that actually you can even use with wsupplicant or system network D or network manager or anybody else to actually check what time is spent at what step of the configuration process and it tells you okay this took like x amount of milliseconds and so on and so forth. So 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.
11:01
If you might even use a newer one where you actually have a better transceiver and where you might get a little bit faster but the scanning is really when you know that 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.
11:23
The connection time by doing the association and the authentication with a four-way handshake is another around 100 millisecond. That's just what it takes. You have to get the data over the air. You have collisions over the air and that's around 100 millisecond as well. DHCP has been really fast since the early days of Conman with system D network D having this also.
11:41
So there was really no surprise that we got this down to 50 here between 50 and 180 seconds. 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 8221. I don't know if anybody knows the difference
12:01
but normally W-Supplicant opens the AF packet socket to run the PAE packets for the four-way handshake. We put a patch into the code that you can run these as part of the Netlink protocol so you get a frame in the Netlink protocol. We did this mainly so they get come in order with the Netlink messages because the kernel schedules the AF packet queue
12:20
differently than the Netlink queue which means you could might get your connect association response earlier or later than the actually PAE packets and then you have this out of order problem that you have to resort 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 four times faster than doing this
12:42
on an 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.
13:03
The problem is on these 300 milliseconds 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
13:20
so wasting a lot of time to just get you back up. So if you have 1.2 seconds by doing Wsupplicant with the PAE over an 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 over the 100 millisecond goal. The Android people on chats and bug reports
13:40
reported that the address randomization can add a penalty of three seconds. If you don't want it, that's fine. I've seen comments on the meetings as well that's like, why are you gonna do this? But for privacy reasons you really wanna do address randomization for every access point you're gonna have these days. So we have achieved a lot but we are still drowning with the last bits and pieces
14:00
to get them right to make this really constantly have privacy enabled, have the full security working and have this really, really fast. We are at the level where we can't work any more magic. IWD has reworked all its magic it can do by having using the existing interfaces with the existing kernel patches that we put in there
14:21
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 ADT optimizations. We need to change the kernel APIs in a massive way where you say look, every millisecond counts. I mean, if you send me a full wifi dump of the network
14:41
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 gonna 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.
15:01
People think that the round trips to the 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 a bunch of patches on the mailing list to actually change things, a 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,
15:20
they support this actually. We are in the situations. We're trying to give them something and so far we have not got taken them. It's, I have currently no idea how we're gonna reach the 100 millisecond goal but we need to go there at some point so we have to see how this goes.
15:41
We 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 gonna continue as it is. IW is currently better and faster but what are you gonna do about this? So IW21, 021 is the latest.
16:00
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.
16:21
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 certain system D is actually larger in source code lines than Wsupplicant.
16:41
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 duplicates 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 a plus 300,000 lines of code.
17:01
I mean, then I said okay let's take IWD. The pure daemon is around 40,000 lines of code. With tools and unit tests and everything around we have 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
17:21
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. Test it and please tell us what isn't working. I mean, we have covered most cases. We have covered most. We have auto tests and unit tests for all the heavy things
17:41
but there's slight and slight variations especially in our own networks, et cetera 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?
18:03
I think you go first. You say that it's so much more wonderful than WPS applicant. What are the current regressions for a normal laptop use case?
18:20
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 package is it now. Them making the switch takes a while.
18:41
Nobody's thinking, oh we're gonna 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 one 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 line in network manager
19:00
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? Do I got the gist right? Thank you. I think there was another one over there. Hi. Thanks for the great software. I've been using it for a couple months now and it actually works very well. For my use cases at least
19:21
I just have a slight regression or bug or problem in like a systemd network D context basically where there's this race condition about naming of, yeah you know it already. So. It's a bit annoying. And do you have any idea how to fix that
19:40
or if that's possible actually? The stuff he's talking about is that IWD is too fast. So normally you have systemd and systemd network D introduced the concept of persistent naming. So the interface names are named at a different pattern or something. Actually udev is too slow. We are fast at bringing this up.
20:01
So once we already started up and running we will have that interface that's active and we own it. IWD on some cards actually gets one step further. We actually take all the interfaces away and regenerate, recreate them. So the existence of a network interface with wifi is a legacy artifact from back in the days
20:20
that doesn't need to be there. You can do all the wifi operations for the control path without having the network interface present. The network interface is just the data pass. And in some situations we actually just remove them all and then put them back together. So any kind of naming that you set up or that you still set up is pointless anyway because we keep redoing it. So for people that wanna have their proper naming,
20:42
for us the only way is to wait until udev actually finished. It's time wasted. I don't have a good answer for this one. I think I looked at actually, because System E Network D can do it because it waits for udev to finish, we actually don't look at udev at all because we don't care.
21:00
Because we're told that the interface is there or from the wifi side. I don't have a good answer for this one. Is it that important? I was just like a kind of a weird annoyance by first using it. All of a sudden your network naming is different again and then a lot of configuration breaks. That's the main issue basically.
21:21
So my personal viewpoint on this one, in two or three years we will have actually IWD do all the network configuration and System E Network D and network name will just follow it. And then these systems, the connection has become only responsible for setting the right route and the route metrics. While the IP configuration of the interface itself, it's something that's so fundamentally wifi specific,
21:41
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 them 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
22:00
within the information elements or some of the action frames. I think that's gonna change really quickly. Just a closing question, because you didn't really cover this in your talk, but do you have any, sorry. Sorry if I hogged the mic. Can you tell us something about the access point? About access point usage with IWD,
22:24
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
22:41
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 expects. I think it's even integrated network manager. If you click on the UI there, say create an access point, it actually does work as well.
23:05
Maybe naive question, but why does MAC address randomization causes so much penalty? Can't you just 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.
23:21
You have to power down the PHY. This unloads the firmware. Then you have to reload the firmware and boot up all your transceivers, et cetera. That's where the big penalty is coming from. With, well, we have patches where you can do live address changes. There, we have a huge discussion, they're not getting accepted.
23:41
And they say, I'll just put down the firmware, so whatever, who cares. Yes, please. Okay, so apart from that bit, my question's a bit of a follow-up on that. You said some cards can do it, as in the card and the firmware can do live address changes.
24:02
Can Intel cards do that? Yes, they can. Excellent. So it's pretty much everything that's run on, there are a lot of things that are Mac 8 to 11 based, so the soft Mac cards can do it. There might be some slight variation, some of them can't. Full max card is always the thing that's like,
24:21
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,
24:41
or how can one find them? No. Do you have a suggestion? 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 or so one can look for, because I guess Linux wireless list is quite high traffic,
25:00
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. Nevermind. 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.
25:24
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,
25:41
which really hurt performance. If you have an idea how to force or persuade developers to not do this, like in review, that they have, for example, to justify everything, which takes longer than 10 milliseconds or so, I'm open to suggestions,
26:00
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 gonna get screwed anyway. IDWD is fully asynchronous compared to WSimplicant, which is a lot of synchronous operation, and that gets to bite you.
26:21
That's why we sometimes get the speed, that's why we're faster than UDEF 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.
26:41
With wireless technologies, it's a little bit differently because they are, by its nature, asynchronous. I think my time is up now if I've got this right. So thanks everybody, have a good day.