 Well, welcome everyone, and thanks for coming to my talk. I'll be talking about NetCon, revamping up the daily network configuration system today. But before I do that, I'd first like to thank Keith Packard, because he's actually the man that made me do this on my own laptop. I had problems yesterday, I was continuously freezing, so I gave my laptop with the root console to Keith, then wandered off to the hospital, did laundry, slept for 20 minutes on the couch, came back, and Keith had already submitted the pass-up stream. So then, very productive, thanks Keith. So what is NetCon? Some of you may have heard me talk about it, and I've explained it to some people, but I try to do a rather comparing picture today. I guess the existing network configuration system didn't really fulfill my needs, and the needs of users whom I had to administer computers. So I sort of came up with an idea of how it could be done differently. I was about two years ago, or something like that. Since then, a lot of things have happened, but my idea has sort of like kept solidifying, and I'm here to present it today. NetCon is a modular, demon-based network configuration system. It's policy-driven, flexible, and extensible. I'm kind of talking about stuff that isn't really done yet. So when I say this, it's more of a wish list, but I guess I can promise you that I'm keeping these words in mind, not sort of as a marketing type of thing, but because I really want that system to be something that can be used on a devian system, and therefore meets up to the high devian standards in terms of flexibility and extensibility. I wanted to be backwards compatible, so that you can actually replace it about down with it. But also super suitable for servers and laptops alike. It should be just a one-for-all system with the extensible bit added so that you shouldn't have to be afraid that I'm just going to install a 20 megabyte package that does everything network-related on your computer. And currently it's actually prototyping Python. I know a lot of people have complained about that so far, but it's chicken-treating me while that language. It's a good prototyping language. I guess the final goal is to support it to see if there is a question. But I guess if you want to have a network configuration management... Sorry, the question was what the complaints are about Python. I guess if you want to have a network management system which is a rather core component of your operating system, you don't really want to have a dependency on Python. So if the final goal, wherever, is to get Neton into devian base, it's going to be a lot easier if I do not depend on Python. Okay, this is what I'm going to give you today. I'll give a little bit of an overview of my wish list and also the wish list that we assembled together with a couple of other people over the last year. I'll show you the design that we came up with during this last dev camp this week, what the current implementation status is and an outlook, and then, well, hopefully we have enough time for some discussion and some input from you guys. So I had a wiki page up for Neton, and it's been up there for about one and a half years and people have been contributing stuff. So from this wiki page, I can give you a couple of points from the wish list, what Neton should be able to do. And one of the most important points has so far been that it's stateless. We do not want to keep an additional state value about whether an interface is up or configured or not, because the kernel knows that stuff, so we don't have to keep track of it. And I'm sure you guys know if up can sometimes get rather confused about what its interfaces are actually doing. It should be policy-driven so that you can be very flexible in what you allow, what you don't, and what you depend on and what should happen if that happens and so on and so forth. It should have an interface for user interface that can connect to it. I think network even. I love you have probably seen that and now I'll get to network. Network manager, sorry, network manager in just a second. It should be sensible because we are actually working on a devian system here, so if you install a package such as OpenVPN, ideally OpenVPN should provide a file that teaches Neton how to deal with OpenVPN as part of the main network configuration so that not every maintainer of anything network related has to win the wheel. Results from management will be nice to integrate. Stuff like that, you know. PHP is an extensible protocol. It can give you print information, stuff about your S&P relay or even the next app's mirror. Why not start using that? There's more. I want non-package integration with non-package I mean two-way like the stuff being integrated can communicate back to Neton not only stuff being integrated is called upon by Neton. Features such as linked status and environment detection, firewalling, zero-pun or linked local networks, Wi-Fi configuration VPNs in the bridging, and there's a bunch of other things that could be added to that list but I guess let's not do everything at once wrong with building the thing after a leader. And I'm the most important part, of course, I don't have ponies. But don't be afraid, I'm not looking to design the non-unixie I'll do everything type of tool. There's Network Manager for that. I like the Unix way and we should, I should definitely go by it but the way that EPUB down-currently does it with hooks it's just not suitable for every single task and I'm sure you've seen the problems with it. Even though it does work, it just doesn't do it all the time. So I've been like slaying Network Manager a little bit here. How many people have used Network Manager? So that's about half. Network Manager's... I want to point out you used the past time. Why is it still not in my hand? Well, half used doesn't necessarily... It's like... Yeah, yeah, good. How many people do we use it? Exactly the same number. Sorry, sorry. Alright, so Network Manager is a known sort of UI or GUI-centric network configuration daemon that sits up there in your known toolbar and allows you to very easily connect to static networks and also will list all the Wi-Fi networks so then range and let me select them and then pick a passphrase. It's rather easy to set up and it works in the simple cases like for various users that basically only ever go to the local coffee shop for Wi-Fi connection or have a wired network at home. It works really beautifully but if you try to actually extend Network Manager or try to fix a bug or something like that you'll find that everything behind that pretty UI is sort of like... And there are certain problems with Network Manager. So it's not here actually to complain too much about it because I hope I was clear about it and it does work and it does the job beautifully. It's just not for everything. But for instance you can only ever configure a single static IP if you want to road between work and home and you have static IPs in both you would have to continuously reconfigure you can't just simply click and point. Policies are art coded. If you want to use wireless and cable at the same time you can because if the cable is plugged in the wireless is turned off. Makes sense for most people but just not all for all. So I guess given that 50% of the people in this room have used or are currently using Network Manager it is definitely a goal for Network to provide Network Manager in such a way that the UI which is very nice can still be used just the back ends are replaced with something that is a little more flexible. Well just for to be complete about this I also want to highlight two other packages that are related to it up down which some of you are using for instance who of you have used or are currently using it up down scripts-zg2 Alright, zero. These are actually this is a package you might want to check out if you are doing more advanced type configuration written by our very own work major and supports stuff like SIDR like non-class ABC type of netmasks for your network configuration VLAN type and renaming of interfaces and so on and so forth and it has a very very nice feature which definitely serves as sort of inspiration for an iPhone that it actually remembers the code that was generated to bring down an interface while it's being brought up so you can go ahead and change and still get the interface down consistently at times with it up down that used to be a problem. There's another package who of you have used or are currently using it up down next drop. Here we go. Did you say you used that? No. Alright. Okay, so JFS our very own JFS implemented that mixture of link detection and location detection network testing trying to make people you plug in and just go figure out what went wrong if it doesn't work. So I'll definitely call that a sort of inspiration especially the script network test although I'm not entirely sure whether that's part of NetCon or just a simple add-on. Alright. And that's about it. I already have any questions up to this point. Good. Then I'll continue with NetCon's design and I'd just like to point out that these slides and what I'm telling you right now is actually based on a design document that I wrote and it's available online so the slides will be linked from the NetCon home page which is down here and you can also find the design document link from there. So the demand is actually an event based framework. Everything that happens within NetCon happens in response to an event. Events can include user requests that come in on control seconds whether that originates by a call to if up or through someone clicking into the network manager UI that doesn't really matter. There is one control socket that is designed to handle all of these sorts of interactions for the user. NetCon also talks to the kernel or listens to the kernel to find out about interface state changes on the netlink socket so it can find out that there is a new interface that appears and then decide whether it should actually bring it up according to the policy and get to that in a second if what the user currently does that. It's also quick get events from application specific application helpers such as phbind and WPA stuff like that. For instance if you are losing a lease on php or you are leaving the network and WPA stuff like that can't keep up the association then there is an event generated and NetCon can react to it. All the events are queued with the central demon and they can be chained so that you can actually have a rather complex series of events build up and eventually yield an action to be taken which you couldn't take in a response to a single event because you have to gather information or figure out more details about what you are supposed to do. So the central demon I affectionately call it the brain has this event queued and simply processes the entire time that the main loop is very simple and in response to an event it may take the appropriate action such as getting configuration details in response to something like an up request it may actually in response to receiving configuration details invoke a method to do the dirty work of bringing up or configuring the interface or it may take appropriate action on the receipt of an event such as if the BHCP server can't be contacted and you are actually stuck on without an IP address but it's a very, very dumb brain actually, a very dumb queued processor because all the decisions that are ever made are delegated to the policy broker and the policy broker is sort of more and more as I'm developing this things tend to change around them in the beginning the policy was this little blob in the design image in the top corner now it's rather big so it's starting to become a more central component what the policy broker does is that it gives you a way to define interface specific policies as well as a default policy to find two interfaces that don't overwrite it where you can say things such as does the user have the privilege to bring up this interface right now you have to call it up as the user root but sometimes the actual main user of the machine should be able to do that just from the command line why the root we can delegate in this part what should I do in response to receipt of configuration details such as the BHCP client getting all the details should I now bring up the interface or should I, what should I do with those data policy broker will be able to answer that what should I do if there is no static configuration for this interface part should I go with the BHCP or if the BHCP fails should I power off the interface or should I get a link local address with zero point it should also be able to define dependency chains saying that for open VPN to bring up an interface I first meet ETH0 so I've been mauling a little bit about how you would define such a policy and I'd be happy to talk to anyone who is better at design or configuration file design than me but I started out with the NSS switch.conf file which kind of defines what happens in response to calling several modules which I'm kind of thinking about doing here then a brief look at the time and now came up with this configuration syntax for instance here this is maybe even configuration file policy file for ETH0 and it may allow members of group 1 as well as user 2 to actually bring that interface up and if the request to bring the interface up is received then we start with the configuration source ENI or CPC network interfaces so then one standard defines ENI and also says that if we do not find a configuration detail stanza within ENI then we should continue with DHCP so that's the next stanza get to ECP, send some parameters along and if you get a fail or a time-on event then continue with link logo and with link logo we don't actually have to define anything because we're just using the default so there's another example I hope you're getting the picture and I hope that you may have some valuable input for me on how to define this policy for instance this is OpenVPN in order to get TUN0UP which is the OpenVPN interface we first have a prerequisite to hit up ETH0 once that happens through a different policy configuration we return here and then start at OpenVPN so then you look at OpenVPN you see that the configuration file is specified and that if we managed to actually bind to the tier on the other side via an OpenVPN channel then we should invoke ENI to actually configure the link and then you can see here that it doesn't always have to be ENI it doesn't always have to be ETC network interfaces it should be more flexible than that so configuration sources is our next step once the policy decided what to do the demon may decide that I now need to get some details and it gets these details from configuration sources the policy is used to determine what was to consult and I sort of came up with a total of four different types of configuration sources in a 2x2 array because the configuration source may be interface specific such as DH client which is invoked for one interface only or it may be generic ENI which is the file that defines all interfaces on your system it may also a configuration source may also be doing a fine job which is for instance link mobile or ETC network interfaces and then just wait it has done its deal but on the other hand stuff like WTA supplement or DH client may actually continue to run and become an event source so in the end I figured out that the best way to deal with this is that if a configuration source is consulted it becomes an event source so in the in the case of DHCP that actually makes sense a lot I think you query DHCP for a lease and then you kind of keep on spinning in the main loop until DH client gets a release or gets a failure notification and then simply creates an event used by the demon asynchronously and the demon can then take appropriate action once it is used it with cases like E and I if you see network interfaces it seems like overfilled to think about in terms of the event source and I'm not entirely sure how I'm going to deal with that but it could also be a one-time event source that simply commits suicide when it's done Enrico on the other hand the user can change the file and it's nice on the other hand the user can change the file and then you can generate the event if the interface configuration changed and re-configured yeah you can do that it sounds like 2.0 feature kind of convenient I'll give you the big picture in just a second I hope this is not too confusing but I have one more component to introduce to you which are the methods so far we've met the event sources we've met the queue processor which is the demon the central demon or the brain we've met the policy broker and we've met the configuration sources now all of these are currently tied together such that at one point in time the demon will receive an event that contains all the information it needs to bring up an interface now in order to actually then bring up an interface the demon invokes methods and I'm talking from DH Plans here because what DH Plans does in a number of states in their documentation is that everything always specific is put into DH Plans script so that it can be very easily part of all two BST which may not actually use stuff like IP round I've had some talks with the 3D people about that and this is one of the motivations why I'm really trying to stay always agnostic with the design of NetCon but if we'd actually do methods as channel scripts for instance the whole thing becomes A insensible and B always non-specific so it should be easily pointable I'll define methods to be the only scripts, the only parts of this entire framework that are allowed to actually touch the interfaces with that I primarily mean configure them right to them but I may also actually decide to read states information only by methods so that a configuration source or an event source may not actually clearly interface directly that we have an additional level of layer abstraction there to make it easier to port to other kernels the methods get information from the daemon by the environment and return a return status or any form of other information by a standard error for instance and are cost-synchronously so the daemon immediately gets a response path because it's a very quick action and there's one challenge that I set myself because I've always been thinking about about that sort of approach to configuration whenever my network at home wouldn't work because if your network at home doesn't work the windows way of approaching it is deep down and up the more unique type way or in a more complex environment the more productive way would be to figure out what is actually currently going on what is the desired state, what is the delta and how do I eliminate that delta so I'm thinking that it could actually be very powerful if we design these methods to be declarative in that they specify that the final state is supposed to be or rather get information from the daemon about what the final state is supposed to be and then simply work to change to minimize the delta between the current state and the final state so now bring the entire interface down but reconfigure it now I realize this sounds very hacky or patchy or like a lot of things could be going wrong and my mind isn't set on it but I think it's an interesting idea to follow unless it fails horribly I think that's where I'm going to go so that's time for the big picture and you've met all the players I'm going to look a little bit a little bit of an exit here hopefully making the overall picture a little clearer and let's play through a very simple scenario where the user is asking the network of daemon to bring up ETH0 where there is no configuration for ETH0 in EDC network interfaces but the policy defines that if there is no configuration in ENI then we should try the HTTP in this case we don't actually get a HTTP at least for to make it a little more interesting in that case then please fall back to link local so what's happening is that the user creates an event through the control socket which is used to notify the daemon that's queued with the daemon's event queue and the daemon says well I want to bring up interface 0 now in today's ETH0 because that's what the user requested we'll start by asking the policy how to do it and the policy says well start at ENI so the daemon puts out a request to the configuration sources in this case the ENI file and then gets a response back synchronously or asynchronously I haven't decided that yet and upon receipt of that response it figures out okay that was not found so dear policy what do I do now and the policy says in case you didn't find a configuration in ETH network interfaces please do DHCP so the daemon goes and says please DHCP configuration source would you get me a lease now at some point after that request DHCP is actually going to report sorry I cannot fail did not manage to contact the DHCP server and it creates an event and sends it back to the daemon and the daemon gets this failure event consult the policy and says what should I do now and the policy says please try and link global and it's just a request and link global eventually answers with an event that contains the configuration details needed to bring up interface ETH0 and the daemon then says okay well now I can finally do some work now I can finally obey the user's command and bring up ETH0 bypassing all the information to the configuration method in this case static even if the configuration source would have been DHCP which is non-statute it's the dynamic host control protocol or config protocol what we get back from it is just an IP address and a gateway and so on and support and we use that to statically configure the interface until something changes was that moderately clear are there any questions about it? Pete so it sounds like they need a new DH client that just returns the lease and doesn't actually configure the interface well DHCP can actually do it DHCP can be told to use this DHCP script which then can output to standard hour the entire environment in a standardized format so I can read that back in in the sub-process and get all the data and since DHCP wouldn't have done all the work if I just print the environment it actually doesn't touch the interface it's very damaged but it will do there's another question you said that the method work in a declarative way but the method also can fail I guess like for example setting default route can fail in some way how can you communicate that and what's the fallback mode for the demon in that case will it just discard the whole configuration source or that's a very good question I'll get to answering part of that question in the next slide but also what I mean with declarative is that success or failure of the method is determined by success or failure of reaching the desired state if it finds out that as a matter of fact there was an error setting the default gateway then it could either try to figure out why it failed do something about it eventually succeed or it could just say I tried but I did not actually reach the desired status in which case yes there would be an error that would be fed back to the demon and the demon would have to consult with the policy for instance to see what to do now I get back to there was another question over there I get back to that in just a second but let me quickly fast forward one slide here just to give you an idea of what I mean or where I see the ability of the demon to actually communicate this information about failure back to the originating event source which is most likely the user system startup or something like that I was too lazy this morning to take a proud picture so bullets won't have to do the control socket is very very simple it's a very simple protocol I've considered not implementing my own protocol but I'm using something like HTTP so or something like that but so far I haven't really been able to get all the features that I need into these other protocols so I'm just staying with my own right now but if there are protocol designers among you or language designers please come and speak to me and the client connects to that socket and issues HTTP like events requests which are then actually created converted to events in queue with the demon the event object itself contains a file descriptor that is opened and write only which directly leads back to the client so whatever you write into that file descriptor will be returned to the client via the control socket in real time so that stuff like dhclient can output its bother in real time because a lot of users would actually be bothered if dhclient wouldn't output stuff anymore or wouldn't do it in real time and there's also a mark done callback function in which the processor of this event is supposed to call once it's done to let the client know that as a matter of fact this transaction is finished there you go and then I guess today or the day before how to do passphrase changes like would we actually want to have a little confused there passphrase queries that's what I wanted to say or perhaps whether we would actually want to integrate those into the control socket protocol make it a chat protocol but then I decided that as a matter of fact it's a little too complicated to do that to have a chat protocol that at the same time also allows for real time throughput of status or where output from the applications that are in use when they come so an idea that we came up with was to say look I need a passphrase to actually get onto this WPA network would you please feed that to me on that new integrated pipe I just put into bar run here's the path and then wait on that pipe after 10 seconds right into the control protocol like hey are you sleeping would you please provide that passphrase to the client so I hope that actually answers your question about how we can feed that information from the method that is doing the actual work to the client if there are any improvements you have to suggest I'd love to hear them but for now let's have that other question I was just going to mention that I'm pretty sure DH client supports DevOps so you could do the face of it that way I don't know anything about it but right so DevOps that's a very important word which I've heard pretty much every single time I've been talking about NetCon and DevOps is a sort of IDC replacement it's a rather scalable way of talking between applications and provides very interesting features such as authentication or authorization and routing and multicast and so on and so forth but I do not use it in NetCon at least not in the core simply because it's another dependency I don't want that dependency however I realize that Debuss has it is very valuable and stuff like Network Manager actually uses Debuss to communicate so it is very likely that I will implement Debuss for NetCon in form of an additional package that simply provides the proxy to talk to the control center but again comments welcome and I think DH client actually doesn't speak Debuss it has its or if something special DHCDBB DH client Debuss Okay so there is a DH client Debuss which pulls which pulls into the proxy alright thanks there's another question Yeah so a couple of observations about the DHCB client not interacting directly with the status of the interface that's true that you can make DH client not bring it into phase and address to the interface but you have to be careful that the interface has to be up before you call DH client or let DH client bring it up because DH client has to be able to set packets and receive packets over interface Right I ran into that and was like oh damn it my entire design has failed and then I actually call IP late accept to get DH client working but the way that I do it now is DH client actually uses a pre-init event and I'll simply take that pre-init event and I view with a demon the demon then invokes a method to up the interface and then tells DH client to continue Yeah obviously a related thing which is slightly more subtle but similar that DH client has a kind of implied the DHCP server that if it can't renew a DHCP lease by the time it ends then the host will stop using that network, that IP address absolutely so the only way you can do this is you can arrange for DH client to tell your brain 10 seconds before it finally fails before the lease expires that it should stop using that stuff and then if your brain is down or is not talking to it for some reason at the time the lease expires DH client should cut the interface and de-configure it anyway because you have to make sure that whatever happens with this stuff the machine stops using that IP address at the time the IP lease expires I hope that the brain will still listen at that point in time otherwise the entire event queue is going to be broken but if it is a very interesting idea to say like 30 seconds before we would lose the lease after having tried several times to renew it to actually create an event out of that so the demon could do something and then when it finally completely fails, when it gets that fail event in the end then the demon has to do the appropriate thing and not fail a network with that IP address sure and one more question and it's okay you talked about at the beginning one of your aims was to be able to get other configuration information like proxies or apps which is a great thing but you didn't really go into any more detail on that stuff I don't know if you could elaborate if you have any ideas on how that would happen specifically do you see a sort of abstraction layer on this stuff so a web browser can ask up down where's the proxy and the proxy will have some configuration okay if I use DHCP then you do WPAC otherwise do this or look in this file so that you abstract all of that information through the same configuration yeah that's sort of what I was thinking about I mean whether it's a control socket command to get these data or whether it's just a file in var run anywhere like var run HTTP proxy you can source that and then you have the HTTP proxy that was returned by DHCPine that's to be decided but the way it would work is simply that DHCP the DH subclang thread includes all these data in the response in the environment if you properly query for it that's a configuration issue and then you can wrap these data up into the event object that you feed into the event queue and if the demon then gets an event that says if of the interface which also contains information about HTTP proxy etc that simply for instance invoke another method like the HTTP proxy writing it into files system method and store that information there and then obviously that works my hope is that applications like web browsers or apps will start using these files similarly to what ETC mailing for instance has been in the past so something that you need to think about when designing this stuff is that a kind of big bang approach where you get all this information as soon as the network comes up might not work for DHCP because DHCP packets are very space limited so there's lots of potential options you can ask for and if you ask for too many then the answers won't all fit in a DHCP packet and you can get around that because there is a DHCP basically telling you just as a query so you can ask for it you can go back to the DHCP server and you don't touch the lease it's all you just say what's the answer to this particular configuration option but to be able to do that you kind of need to arrange this stuff so that when your browser comes up and says where's the proxy then you go back to the DHCP server and make a query on that rather than trying to get all the information in a big bang at the beginning and then just have it available ok thanks for that information that's something I will have to read out long but let me just write that down thanks a lot for good questions are there any other ones at this point in time alright I don't have very many slides to go so we'll have time to discuss in the very end let's have a quick look at the implementation and the outlook as I said it's currently written in Python for easy prototyping but because I realized that Python may not be the language of choice for a lot of people or it may not actually be suitable for embedded systems whether a team in that configuration network interface is suitable for embedded systems or not that's an entirely different question or at least I'll make an entirely different question for now but Python is probably not going to be the final language this is going to be implemented in so when I said C++ would be the real language only so I decided that it has to be seen yet and one way of dealing with this requirement that I would have to actually pour a higher level language program written in Python to C was this is a sort of strict abstaining from all the nice higher level APIs that Python provides like I can actually implement a chat protocol over sockets rather than using async chat which is a module that provides a class of like four functions and you just have an entire chat server up and running within three lines of code now I'm actually doing it manually and if I look at the code now then all I see is cause to socket cause to select cause to some sort of threading library which to be honest that's one to one portable to see so the only real challenge will be to take the object orientedness because I am actually using OO and convert that to C but as we all know you can actually write object oriented code in C you just pass a struct or point it to a struct to every single function and if you know Python that's exactly what Python does every single class member function starts out with an argument problem so actually you know you can probably like automatically change that code over there in case you want to look at that and convince yourself that I'm not talking crap here it's all in a git repository and I switched to git beginning of this week and I've solved like five things it's a quite impressive project if you haven't looked at it should so obviously this is all sorry I just know how to use this briefly this is all linked from the netconf homepage which is on ADN netconf.adn.dev.org and you can get information on how to check out the code from git there and netconf used to be my brainchild until depth cam 7 until last Sunday pretty much a week ago when really everything has been like done the waterfall model like writing design documents and thinking about how I'm going to do it I'm not writing a single line of code and I sat down last Sunday and started to write code and then hit a complete like absolute zero down around Wednesday evening when nothing was working and like the entire structure that I had chosen didn't work out at all and then ended up refactoring a lot and arriving at the current design but most of the parts that I had written before Wednesday can actually be reused so what I can say is that right now the netconf.demon and the client of the control protocol work everything is handled by events every request that you wish to do the control socket generates an event which is dispatched by the demon to a handler if that handler exists then it is actually processed upon and right now that includes one command called ping I will show you how so I will be starting netconf.demon on here in the right side I hope the font is probably a little small isn't it yes and I have no idea how to tell RSVT to increase the font size but let's see I do it slightly bigger to everyone else so even bigger this is RSVT this is Unix from like 10 years yeah I can't believe I can't believe it it's ping it doesn't need to go on film but I really do want to show it so the F just begins to debug show me debug messages and F is staying foreground so you see it started here and then it spawned the control socket listener yeah it's very difficult I just left what I'm doing right now you're on the right now I see again so it started it's running in the background now and then I provide this little like stupid control socket client script which connects to the socket which currently just sits in the directory here you can see the socket file and tells me that it is now coming from PAE so and so and I actually use PAE and the user who runs and connects to the socket to authenticate and then I take an issue of command in here ping that's the first line it could take any number of arguments let's actually do that oh great it's not the control flow within the daemon and all the threads isn't entirely perfect yet but we're going to get there initially oh great but ping any number of arguments here and it then can take any number of parameters and you see that there this is actually the daemon echoing back now so it received that line and it received that line and then it will also receive that line until I actually send an eon and then what happens is that the daemon says okay I got a request I'm creating an event a ping event out of it but I don't actually know a handler for the control socket ping then so loads that handler dynamically it's just one item module or just one .so file and then then passes on the event to the handler which simply answers to the ping and marks the event is done and then closes the socket and the client disconnects and everything is fine and happy so that works but I haven't really done any integration with configuration sources or methods but the parts of them are already done for instance the e2c network interface parser was written by thomas code about two years ago and he just gave me the code and I pretty much ended up using it exactly because it works perfectly fine it can do everything that if of them can do including the mappings so you can include your mappings scripts or even stuff like guestnet and you'll get the correct information out there's also a used client thread written which gets you all the information and creates an event but I haven't actually integrated that with the handler but that's going to be a very simple task I have a netlink listener but I don't actually process it yet so you see it's very much work and progress and I need help well I don't I mean I'm having a lot of fun and it just takes longer but I'm getting help but if you're a beggar or a beggar and you want features that kind of thing speak up I also would love to have people conceptualizing more complex setups not only people who come up to me that they actually want like vlan tagging or rebonding and like doing everything all at once and then vpn on top and it must never fail that's a great idea right just tell me a little bit how you think that could be implemented I don't do vlan tagging and rebonding involvement I would love to have people write a unit test so we can make a competition out of it you know for every ten times to make my program fail with your unit tests I'll buy your gear something like that people if you like to document code there's absolutely no documentation in the code so far it is highly recommended after all it's rather easy to read but I haven't really bothered with documenting it yet I think like 99% of our projects start out and eventually never do anything else than that without documentation and I realize it's bad but I've been really wanting to get something working in time at this top which hasn't really happened except for the ping pong but so be it and then if you actually want to go and write code if you actually want to contribute please do come to me and I'll show you the code I'll walk you through it to explain it because there is no documentation and then you can access to the game repository so that's all from me for now if there are any more questions I would love people to tackle now as you probably know I'm the commentator of network manager so you were bashing me a bit at the beginning and I just wanted to say that for the next major release multiple active connections are a goal so this will be possible and another design though network manager is that it just works the philosophy behind it and with laptops becoming more and more important I think you completely missed out the part of wireless networking that's a major pain currently with the network manager so if you plug in a wireless network card to the medics it starts to scan the way that the network presents a list of that in the UI and when you select one in two you know which type of encryption it uses and stuff like that how do you want to integrate that into a NetConf I mean it's currently a network manager who uses the WDXT interface to interface with the driver so what's your goal in that regard well it is true that I could have added one or two slides to my talk about wireless networking because as a matter of fact I completely agree with you that it's more and more important that it is also the major source of trouble I think for most people in terms of network configuration I've spent an hour over a cappuccino with Reinhardt partner, served, retired from on the high streets and we were conceptualizing how to do that that was before I actually ended up refactoring so I came into this talk with a majorly complex setup like I had to have a section on nomenclature in my design document just to be able to actually make it clear what I'm trying to do and then we were trying to beat that thing into shape to actually make it work with DH client and with WDXT and I think we haven't finalized it but I think that it is possible to do WDXT in the way that you would expect it to do including the scanning including the configuration of it with the same design that I'm using for DH client because in the end it's very much the same stuff that is happening like DH client needs to get an even place up, there's a pre-init event you can use that pre-init event to get scanning information for instance DH client issues the bound event if it found a lease whereas WPA stuff can be made to issue a similar event if it manages to get an association now I realized that I'm kind of like making this up as I go but we did have a rather intense talk and I did spend quite some time with WPA supplicant at the time when we changed from they changed from the 0.3 or 0.4 release to 0.5 because the new way of doing WPA supplicant configurations by E&I and Debbie just broke everything that I might configuration so I tried to figure out how I could fix that and I think through because WPA supplicant also controls socket you can start the demon and then you can control it as it's running and you can tell it to connect to new networks and so on and so forth I think it will fit in quite nicely if I have NetCon spawn a control threat for WPA supplicant which then connects to that control socket issues commands as needed and well that would be actually the method that issues the commands and then queries or receives the events and so on and so forth the connect commands passes them off into the event queue and the demon and that's when things happen so within your design where would this be in your demon where you hold the state about the found wireless network and stuff like that I mean I think if you remember you said want to completely complete the stateless and the thing about network network is it tries to scan repeatedly where this offers a second or so to be removed immediately from the list of the wireless networks and stuff like that but I don't think you can make it completely stateless you have to do the state somewhere you cannot make it completely stateless and I have stated here it will have to keep some state and if that state is only there there is actually a threat running for the usqq and the basic gh0 it's not possible to do it stateless but you can do it and it's not a redundant information information that's in the chrono we don't need to keep it in the file system that sort of thing but yes it will be a challenge WPA is a bookend and then when it gets an association do DHCP and then open VPN on top of that this kind of thing it will be a challenge but sorry that it is it gets ugly with all the wireless drivers yes I know but we'll see what happens if that doesn't manage to do that in the end then at least I finally managed to write some code in Python the meaning to do that forever I'm a sole developer but I haven't ever started my own project in Python so this is good are there any other questions? I've been trying with actually doing with a colleague some bottomed stuff where we ought to make you consider which interfaces should be part of the same code and some previous should be find out which interfaces which subnets can pair them all together do you see an easy way of doing that kind of stuff with make-up? basically location art of detection is that what you're saying it's a prerequisite it's on my wish list I have to admit that right now I can point out where it would happen but I think it might be related to the policy the policy would have to say it's sort of a configuration source if you think about it the policy would say don't start an ETC memory interface start at location detection and then that would actually spawn a where am I or a laptop detect or whatever thread which would come up with location which then gets wrapped up into the next event to configure by an E and I so initially I thought of a config source as to be a stack that's sort of the lowest level of information like layer 2 and then layer 3 is the HCP and then layer 5 and so on and I got rid of that idea because you want a policy to decide what to do the stack you always I call for that it's not always IP and it's not always the HCP or link global it really depends on the policy but I think that in that model you can insert the location on the detection underneath the getting IP address config source we'll see about that I guess my time's over and thank you all for the questions and for coming for your attention and I hope that I'll have a lot of people in the near future thanks