Re: [systemd-devel] Static IP address on wandering Wi-Fi client
Hi Johann, >> And frankly IP configuration needs to move into the network technology >> daemons like iwd for example. > What's the argument here for that reasoning as in why not consolidate all > network configuration ( ethernet/wifi/vrrp/vpn's etc.. ) to a single place ( > networkd )? > > > > Why do you want to keep the network configuration and management space > fragmented ( as opposed to consolidated ) ? because that is what the standards are doing. WiFi for example can transport the IP address inline. You just need to confirm it with DHCP later. It is how the standards are written that you want to really move DHCP one level down. The same applies to cellular connections where all the IP level configuration comes via the cellular network and not DHCP. For setting up WiFi connections and being able to roam fast (even in the Tokyo subway scenarios), you need to do certain things in a single place. We will never be able to expose all the WiFi states one level up. We are hiding them inside iwd for a reason. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Static IP address on wandering Wi-Fi client
Hi Bruce, > I'm not so sure about handing the IP configuration to the service that > is managing the link level. What then do we do with Ethernet? Do we > build an iwd equivalent to set up the routes, etc. for the Ethernet > connections? What I like about what I've seen with systemd-networkd and > wpa_supplicant so far is that I can manage one set of systemd-networkd > configuration files to determine which interface (eth0 or wlan0) gets > priority, and whether or not to use the link's DNS and time services. It > all "just works" for me. I understand that iwd is going to be more > straightforward and better than wpa_supplicant, but systemd-networkd has > also been straightforward and easy for me to work with. I'd like iwd to > "just work", too. actually we have been working on ead (Ethernet Authentication Daemon) that does indeed will handle Ethernet setup and configuration. It is not about setting up the routes. For that you need a networkd, NM etc. It is about the actual IP configuration of the interface. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Static IP address on wandering Wi-Fi client
Hi Lennart, >> Is there any way to tell systemd-networkd to use one .network file or >> another depending on which SSID the Wi-Fi interface is connected to? > > This does not currently exist, but it was always the intention to add > this. So far nobody did the work though. > > Most likely this would require some minimal wifi netlink hookup so > that we can properly watch the configured SSID for the interfaces we > watch. Would love to review such a patch. actually this is the wrong approach. You are not getting the full state information back from the netlink interface. You need to talk to a proper WiFi daemon like iwd that has a full understanding of the WiFi state. And frankly IP configuration needs to move into the network technology daemons like iwd for example. Doing that at the level of networkd or NetworkManager is not working out long term. Each technology has a lot of interlinking between the IP configuration and its network technology. There needs to be a split between configuring the network interface and setting up routing and other relationships. The pure IP configuration has to be done by iwd (and soon it will be). Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] powering on bluetooth after suspend - required services aren't ready
Hi Lukas, > When a system wakes from suspend, the Bluetooth adapter needs to be > explicitly powered on. This can be conveniently done by a systemd > service file, as described for example on Archlinux wiki [1] (the > systemd service file at the bottom of the section). > > The hciconfig binary used to work up to kernel 4.1.5, with 4.1.6 and up > it stops working with Bluetooth LE (4.0) devices. The tool is > deprecated, instead a dbus call (ie. the commented line in the systemd > service file in [1]) or another tool, btmgmt, can be used to power on > the Bluetooth adapter. > > The problem is neither of these tools work at the time systemd invokes > them, they require the bluetooth daemon to reinitialize itself after > resume (at least for the dbus call it needs to listen on dbus, not sure > about the btmgmt tool). Normally systemd handles this gracefully, but > after resume, the required services appear ready to systemd while they > aren't. > > What is the proper solution to this problem? anybody hacking in a tool that manually powers on the previously powered Bluetooth controller is doing something wrong. The question that should have been asked is why the controller got powered down in the first place. An obvious issue could be that for some reason the device manufacturer decided to pull the power on the Bluetooth controller (aka USB disconnect) instead of handling proper suspend/resume. The btusb driver for example does support suspend/resume correctly, but it can not do anything about stupid devices. If they physically disappear from the bus, then they are for all intense and purposes unplugged. Now for the lifetime of bluetoothd, it could remember the state of such a controller and restore it when it comes back. However that does not really help us sine we actually want to stop bluetoothd when no Bluetooth hardware is attached to the system. So that means that bluetoothd would have to store the value persistently over restarts. Which now is a problem since we need to account for the overall offline mode policy. That offline mode policy is not well defined (unless you run something like ConnMan) and so the only safe bet is to initialize the controller, but not power it on. Just for reference, hciconfig has been deprecated since a long time now. It is a nice tool for quick and dirty testing, but using in production systems to power on a controller will not make your life happy. Especially if you want to use Bluetooth 4.0 Low Energy (LE) feature. The btmgmt is for developers and testers of the kernel API and is not even installed by BlueZ upstream package. The correct way is indeed to use bluetoothctl or send a D-Bus message. Something that can be done easily by the Bluetooth UI that also provides the Bluetooth agent. The UI will most likely have a good idea about the offline policy and can nicely enforce it. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Will *.network replace resolv.conf? What about Options single-request?
Hi Lennart, On Mon, May 4, 2015 at 2:57 PM, Christian Brunotte c...@lathspell.de wrote: systemd.network(5) with Options like DNS= and Domains= looks like /etc/resolv.conf will soon be superfluous. In many setups, yes, but we will not aim at bug-for-bug compatibility or anything like that. We are open to adding features that make sense though. If that's the plan, I wonder what happens to options single-request which I had to use on all IPv6 enabled devices. Is ResolveOptions just missing in Systemd or considered so special that will stay in libc's resolv.conf? (quoting from the man page: By default, glibc performs IPv4 and IPv6 lookups in parallel since version 2.9. Some appliance DNS servers cannot handle queries properly and make the requests time out.) Hm, this really does not sound like something that should be configurable. Are you really seeing these bugs in the wild? And if so, how do other OSs deal with this? I mean, having to add quirks to every client does not sound very viable... Surely DNS is something that should 'just work'. I feel like I'm missing some part of the picture here. Yeah, it *is* something that should 'just work', but then there are both corporate firewalls and embedded devices (i.e. home gateways) which choke on EDNS, crash upon seeing DNSSEC, truncate all packets to 512 bytes (manufactured in 2015!), and even outright lie – by making up their own (incorrect) responses instead of forwarding the query. (If it's not encrypted, some proxy somewhere will screw it up...) So, sometimes it works in the sense of Windows doesn't trigger the bugs. Well, but in all these cases, we should try to actively learn, and try a few things before we give up, but certainly not give up completely and let the user configure things. For example, if a server doesn't resond to EDNS or DNSSEC or truncates packets, then we should detect that automatically, fall back and remember this during runtime. so EDNS0 over UDP is something you really should to give up on. In ConnMan we tried hard to make that work and in the end gave up. Funny thing is that home routers in Germany were the most broken ones when it comes to EDNS0 support. The solution is to just jump to DNS over TCP right away and not try to handle larger packets with EDNS0 over UDP. What this means is if a remote server or home network gateways truncates DNS packets, then switch over to establish a TCP connection for DNS and start using that one. Meaning in case the result is too large to fit in over UDP, make the same request over TCP and deliver that result to the clients. At that point, you can also keep using the TCP connection. I think in ConnMan we used some sort of idle timeout to terminate the TCP connections and fallback to UDP until the next truncated packet required us to re-establish the TCP connection. And I think that glibc does something similar. If it receives a truncated packet, it tries to get the full packet over TCP and only if the DNS server does not support TCP, it delivers the truncated data. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Tomasz, Have you looked into MuJS instead of duktape? http://mujs.com/ It has a C api similar to Lua, with all state encapsulated in an opaque structure, that you interface with via a virtual stack. It could be easily tested. I did so the PAC related code is contained in a specific place, sharing nothing specific but a somehow generic internal api. I have personally no bold opinion at this time about which JS engine to use. interesting to test, but it clearly states that its license is AGPL which is clearly more restrictive than the permissive license of duktape. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 3/6] proxy-discoveryd: Add PAC support through duktape js engine
Hi Zbyszek, --- a/Makefile.am +++ b/Makefile.am @@ -5895,12 +5895,19 @@ rootlibexec_PROGRAMS += \ systemd-proxy-discoveryd systemd_proxy_discoveryd_SOURCES = \ + src/proxy-discovery/duktape.h \ + src/proxy-discovery/duktape.c \ These files are not included in the patch, how do you intend to ship them? I figured this could be included as a separate commit, when it will be time to commit proxy-discoveryd someday. Those 2 files represent more than 2 megabytes, so I did not want to flood the ml. duktape should not be embedded in systemd. It's a separate project, which gets updates and has a life of its own. Preferably, duktape would be packaged by distributions and we would use it like any other external library. If that is not possible, we'll have to look for some other option, but only then. For example, git submodule is still better than embedding of a snapshot. that is not how this actually works with duktape. The release versions are building a single duktape.[ch] that you can only find in the releases. Otherwise you have to stitch that manually. It is pretty much designed to be included into other project as a copy. That is why nobody has actually packages this so far. So while I get that including copies of other libraries is generally bad for security update reasons, but this one would qualify as an exception. It is just that we have to monitor duktape upstream releases and with that also update the duktape version in systemd. It is something that is not the greatest solution, but something that is feasible. Keep in mind that embedding your JS engine right into your application allows for optimizations that you really want. We have build PACrunner against V8 and MozJS and these are two really painful experiences. For anybody wanting to build a small system, dealing with these two upstream packages is a nightmare. It sort of works in a large distribution like Fedora, but anything small it is not an option. I know that embedding is the way that upstream suggests. But it is a bad fit for the way that systemd is distributed. Our primary consumers are distributions, and the first thing most distributions will do is to rip out the embedded copy in order to use a shared one. Something as big as a javascript engine is bound to have security updates and by embedding it systemd we would be forced to a) follow upstream changes, b) release systemd updates based on duktape releases. Not something that we want to do or would do very well. We really should try to base this on a javascript engine which provides a shared library. so do you know of a small Javascript engine with a proper license then? And that also has no additional dependencies. I was not kidding when I said the V8 and MozJS are a nightmare when you want to build a small system. So these two are pretty much out of the question for the PAC service. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 3/6] proxy-discoveryd: Add PAC support through duktape js engine
Hi Zbyszek, --- a/Makefile.am +++ b/Makefile.am @@ -5895,12 +5895,19 @@ rootlibexec_PROGRAMS += \ systemd-proxy-discoveryd systemd_proxy_discoveryd_SOURCES = \ + src/proxy-discovery/duktape.h \ + src/proxy-discovery/duktape.c \ These files are not included in the patch, how do you intend to ship them? I figured this could be included as a separate commit, when it will be time to commit proxy-discoveryd someday. Those 2 files represent more than 2 megabytes, so I did not want to flood the ml. duktape should not be embedded in systemd. It's a separate project, which gets updates and has a life of its own. Preferably, duktape would be packaged by distributions and we would use it like any other external library. If that is not possible, we'll have to look for some other option, but only then. For example, git submodule is still better than embedding of a snapshot. that is not how this actually works with duktape. The release versions are building a single duktape.[ch] that you can only find in the releases. Otherwise you have to stitch that manually. It is pretty much designed to be included into other project as a copy. That is why nobody has actually packages this so far. So while I get that including copies of other libraries is generally bad for security update reasons, but this one would qualify as an exception. It is just that we have to monitor duktape upstream releases and with that also update the duktape version in systemd. It is something that is not the greatest solution, but something that is feasible. Keep in mind that embedding your JS engine right into your application allows for optimizations that you really want. We have build PACrunner against V8 and MozJS and these are two really painful experiences. For anybody wanting to build a small system, dealing with these two upstream packages is a nightmare. It sort of works in a large distribution like Fedora, but anything small it is not an option. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Zbyszek, As it has been discussed in the systemd hackfest during the Linux Conference Europe, one daemon could centralize the management of all network proxy configurations. Idea is something user can do per-application (like in firefox for instance) or broader (per-DM like in Gnome), user could do it once and for all through such daemon and applications would then request it to know whether or not a proxy has to be used and which one. As a notice, this is nothing new. Such standalone daemon has been already done by the past, pacrunner. systemd-proxy-discoveryd will more or less implement the same ideas with improvements. It will get rid of big JS engines like spidermonkey or v8 which are overkill for the tiny PAC files to be executed on, for instance. From pacrunner experience, APIs will be also improved. Hi, the idea of having centralized proxy config is certainly nice. But the PAC files make me shiver. So the first question: is it really necessary to support PAC files? Are they widely used in corporate setting or something? Is there no saner standard? If the PAC files must be interpreted, I think this is the hardest part. FindProxyForURL is started for every request, potentially hundreds of times per second and more. This means that starting a process per invocation is out of the question, and even starting a thread per invocation seems to be too much. But each call fall into an infinite loop and hang. So the run time of FindProxyForURL should be bounded. FindProxyForURL can also resolve names over the network, which would best be done asynchronously. Things in systemd are usually implemented through poll loops, which makes it easy to support thousands of concurrent jobs. I'd think that this would be the best option here too, with a number of workers executing FindProxyForURL()s and stopping when name resolution is requested and continuing when the name is resolved. PACrunner is an existing implementation of this concept. It uses threads and seems to work just fine. We bridged libproxy API compatible library that talks to the PACrunner over D-Bus. I am confused why everybody worries about DNS here. Just use C library name resolving calls. Let it resolve it and be done with it. You are synchronous anyway since the name resolving happens as a Javascript function call. It just happens that this is mapping to actually system code internally. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 2/6] proxy-discoveryd: Add the basics for parsing the default configuration
Hi Lennart, The config file will be in /etc/systemd/proxy/filename.conf It currently only load Proxy parts, with the key PAC. Rest is ignored. The PAC keyword is a path to a .pac file (a specific js script for proxy configuration). Only one PAC based proxy configuration will be loaded at a time. (Just a side note: I figure in the long run we should probably track PAC data per-interface (plus maybe one global setting), so that clients can query this specifically for an interface, and so that we can search PAC data over the right network. But I figure for now this doesn't matter too much.). why would you have a global PAC file. I think they should be all per interface and nothing else. Well, maybe not a global PAC file, but probably an explicitly configurable global HTTP proxy, if people want that... I mean, it is a pretty common setting to have I figure, and the daemon should proibably cover both PAC and straightforward proxy config... yes that makes sense. So what we have done in PACrunner was that instead of a PAC file you could just give it the HTTP proxy address. And that would also work per interface. When then libproxy or someone did FindProxyForURL, the configured HTTP proxy URL was returned. Of course in these situations, no PAC files are executed, but the D-Bus API for talking to systemd-proxydiscoverd to get the proxy to use can be still used. I still wonder if it is a good idea to have a global proxy there. I would assume you just configure the proxy per interface in your network configuration file. This should be treated similar to DNS configuration. You want this per interface. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Lennart, As it has been discussed in the systemd hackfest during the Linux Conference Europe, one daemon could centralize the management of all network proxy configurations. Idea is something user can do per-application (like in firefox for instance) or broader (per-DM like in Gnome), user could do it once and for all through such daemon and applications would then request it to know whether or not a proxy has to be used and which one. As a notice, this is nothing new. Such standalone daemon has been already done by the past, pacrunner. systemd-proxy-discoveryd will more or less implement the same ideas with improvements. It will get rid of big JS engines like spidermonkey or v8 which are overkill for the tiny PAC files to be executed on, for instance. From pacrunner experience, APIs will be also improved. Hi, the idea of having centralized proxy config is certainly nice. But the PAC files make me shiver. So the first question: is it really necessary to support PAC files? Yes, it's kinda necessary. PAC is pretty widely used in corporate setting. Windows does the WPAD stuff (the protocol to discover PAD) in all its versions since a long time. In fact, it immediately issues the wpad requests as first thing when you plug in an ethernet cable, in addition to DHCP. Are they widely used in corporate setting or something? Is there no saner standard? Nope, not really, I fear. If the PAC files must be interpreted, I think this is the hardest part. FindProxyForURL is started for every request, potentially hundreds of times per second and more. This means that starting a process per invocation is out of the question, and even starting a thread per invocation seems to be too much. But each call fall into an infinite loop and hang. So the run time of FindProxyForURL should be bounded. FindProxyForURL can also resolve names over the network, which would best be done asynchronously. Things in systemd are usually implemented through poll loops, which makes it easy to support thousands of concurrent jobs. I'd think that this would be the best option here too, with a number of workers executing FindProxyForURL()s and stopping when name resolution is requested and continuing when the name is resolved. Well, it's Java script code. People can just add code like for (;;); , and we must be able to cancel the lookup then safely. I doubt that's cleanly doable with either thread-based or event loop based solutions. I am pretty sure a worker process logic is the way to go. The worker process should get the PAC data when it is forked off, and then read FindProxyForURL data from a pipe and output the result on another, or something similar, and easily sandboxable... are you sure that you are not overthinking this? I think that duktape actually allows just canceling the JS engine execution, no matter what operation it runs. So you could just cancel the JS context. How is this implemented in duktype? I mean, cancelling threads is fricking awful. POSIX thread cancellation is awful, and I am pretty sure NSS calls are incompatible with it anway. Which means you have to check flags after each javascript instruction -- which however doesn't really work too well either, since NSS calls will block as long as they want, hence you couldn't use this to cancel those... I am not saying that we cancel the thread. I know that this is painful. I am saying that we just cancel the duktape context and its execution, then the thread would just yield all by itself. So I think the question is if a master thread could just tell the duktape context to quit. That is something we might want to figure out. I really would prefer doing this out-of-process. Then we can kill the stuff, regardless what it is doing, without interfering with anything else. Heck, we can even let the kernel help us with the timeout thing with RLIMIT_CPU... We would need to define some IPC and managing the pool of these processes. Of course this is possible since almost any browser does it this way. It however sounds like a lot of effort and complexity if we can do the same with threads and just cancel the duktape execution instead. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Lennart, As it has been discussed in the systemd hackfest during the Linux Conference Europe, one daemon could centralize the management of all network proxy configurations. Idea is something user can do per-application (like in firefox for instance) or broader (per-DM like in Gnome), user could do it once and for all through such daemon and applications would then request it to know whether or not a proxy has to be used and which one. As a notice, this is nothing new. Such standalone daemon has been already done by the past, pacrunner. systemd-proxy-discoveryd will more or less implement the same ideas with improvements. It will get rid of big JS engines like spidermonkey or v8 which are overkill for the tiny PAC files to be executed on, for instance. From pacrunner experience, APIs will be also improved. Hi, the idea of having centralized proxy config is certainly nice. But the PAC files make me shiver. So the first question: is it really necessary to support PAC files? Yes, it's kinda necessary. PAC is pretty widely used in corporate setting. Windows does the WPAD stuff (the protocol to discover PAD) in all its versions since a long time. In fact, it immediately issues the wpad requests as first thing when you plug in an ethernet cable, in addition to DHCP. Are they widely used in corporate setting or something? Is there no saner standard? Nope, not really, I fear. If the PAC files must be interpreted, I think this is the hardest part. FindProxyForURL is started for every request, potentially hundreds of times per second and more. This means that starting a process per invocation is out of the question, and even starting a thread per invocation seems to be too much. But each call fall into an infinite loop and hang. So the run time of FindProxyForURL should be bounded. FindProxyForURL can also resolve names over the network, which would best be done asynchronously. Things in systemd are usually implemented through poll loops, which makes it easy to support thousands of concurrent jobs. I'd think that this would be the best option here too, with a number of workers executing FindProxyForURL()s and stopping when name resolution is requested and continuing when the name is resolved. Well, it's Java script code. People can just add code like for (;;); , and we must be able to cancel the lookup then safely. I doubt that's cleanly doable with either thread-based or event loop based solutions. I am pretty sure a worker process logic is the way to go. The worker process should get the PAC data when it is forked off, and then read FindProxyForURL data from a pipe and output the result on another, or something similar, and easily sandboxable... are you sure that you are not overthinking this? I think that duktape actually allows just canceling the JS engine execution, no matter what operation it runs. So you could just cancel the JS context. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods
Hi Lennart,
+
+static int method_find_proxy(sd_bus *bus, sd_bus_message *message, void
*userdata, sd_bus_error *error) {
+_cleanup_free_ char *p = strdup(DIRECT);
Please don't mix variable declarations and function invocations in one
line (also see CODING_STYLE). Also, missing OOM check...
+Manager *m = userdata;
+int r;
+
+assert(bus);
+assert(message);
+assert(m);
+
+r = proxy_execute(m-default_proxies, message);
+if (r 0)
+sd_bus_reply_method_return(message, s, p);
Hmm, is this right? Shouldn't we return the error code to the client
instead of eating up and returning DIRECT?
Also, why allocate DIRECT with strdup() at all?
There are no errors. Either you get a proxy directive or you return
DIRECT to indicate no proxy. What would you do in an error case
anyway. The backup is always assume no proxy.
Well, so far it has been our coding styles to propagate errors up if
they cause the invoked operations to fail, and allow the higher up
code deal with them and possibly eat them up. I mean, the HTTP client
can eat the error up and downgrade to DIRECT on its own, there's no
need to do this from our side already.
of course it can, but it also does not help you at all. You are not making
anything better here.
I think that one clean interface to this needs to be a API compatible libproxy.
Similar to what we did in PACrunner since that allows existing application to
just use systemd-proxydiscoverd.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 4/6] proxy-discoveryd: Execute the PAC based proxy in a thread
Hi Lennart, sd-bus is not thread-safe. You cannot send messages from different threads at the same time... Why precisely do you need threads here? Because the PAC programs might be slow? the Javascript execution is normally blocking and it can do whatever it wants. If it wants to draw a smiley face, while looking up the proxy, it can do that. I think the PAC execution needs to be done in a thread, but not the D-Bus message handling. WHat about unbounded loops in PAC programs? We need to protect from that, which kinda suggests we muight want to run the PAC stuff out of process so that we can neatly kill the program when it runs for too long? Remember that in theory for every HTTP request a browser makes it is suppose to ask the PAC file first. Meaning it will run this a lot. So spawning processes might be not really useful. Even if we start one PAC processing process for each interface, you still want threads since you might have multiple requests from different application. And if one can be answered from a cache, then you do not want to wait until the Javascript execution finished. Hmm, this really feels like we should still do this out-of-process with a worker process logic. Reuse processes to keep the cost down, and run up to a fixed number of them in parallel to allow multiple sumultaneous requests. THis would have have the major added benefit that we could lock the worker threads down with seccomp and whatnot, which is certainly a good thing given that we'll execute foreign, untrusted code we downloaded from the network with this. And we can easily kill the execution with a time limit if we desir to do so... I get the feeling that this needs to be measured and someone has to write some performance tool around this. So while you have only seen tiny PAC files, I am seen ours. And that one is massive. I bet that other corporation have similar large ones. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 2/6] proxy-discoveryd: Add the basics for parsing the default configuration
Hi Lennart, The config file will be in /etc/systemd/proxy/filename.conf It currently only load Proxy parts, with the key PAC. Rest is ignored. The PAC keyword is a path to a .pac file (a specific js script for proxy configuration). Only one PAC based proxy configuration will be loaded at a time. (Just a side note: I figure in the long run we should probably track PAC data per-interface (plus maybe one global setting), so that clients can query this specifically for an interface, and so that we can search PAC data over the right network. But I figure for now this doesn't matter too much.). why would you have a global PAC file. I think they should be all per interface and nothing else. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 3/6] proxy-discoveryd: Add PAC support through duktape js engine
Hi Lennart,
+struct PAC {
+duk_context *ctx;
+};
+
+static int get_addresses_from_interface(int ifindex, union in_addr_union
*address) {
+struct ifreq ifr = {};
+int sk;
+
+sk = socket(AF_INET, SOCK_DGRAM, 0);
+if (sk 0)
+return -1;
No made up errors please! Return -errno or so.
+
+ifr.ifr_ifindex = ifindex;
+
+if (ioctl(sk, SIOCGIFNAME, ifr) 0 || ioctl(sk, SIOCGIFADDR,
ifr) 0) {
+close(sk);
+return -1;
Same here...
Also, please don't use the old ioctls for querying network
information. Use netlink through sd-rtnl. You can look at the
systemd-resolved sources, they do this already, and this code should
probably do it very similar from that.
+static int pac_dns_resolve(duk_context *ctx) {
+_cleanup_free_ char *address = NULL;
+struct addrinfo hints = {};
+struct addrinfo *res, *addr;
+const char *hostname;
+int r;
+
+hostname = duk_require_string(ctx, 0);
+
+hints.ai_family = AF_INET;
+
+r = getaddrinfo(hostname, NULL, hints, res);
+if (r != 0)
+return 0;
Hm, synchronous getaddrinfo() is nasty... Please use sd-resolve for
this, which adds asynchronous getaddrinfo() for cases like this...
you do realize that you want this synchronous. These are the magic dnsResolve
and myIpAddress Javascript functions that are expected to be present when
executing the PAC file. There are a few more, but they can be implemented in
Javascript and don't need a C backend. These two actually need that. So you
need to report the result.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 4/6] proxy-discoveryd: Execute the PAC based proxy in a thread
Hi Lennart,
+static void *run_thread(void *data) {
+_cleanup_free_ struct proxy_parameters *params = NULL;
+_cleanup_pac_free_ struct PAC *pac = NULL;
+_cleanup_free_ char *result = NULL;
+const char *url, *host;
+
+params = data;
+
+if (sd_bus_message_read(params-message, ss, url, host) 0)
+goto answer;
+
+if (pac_load(params-proxy, pac) 0)
+goto answer;
+
+pac_execute(pac, url, host, result);
+
+answer:
+if (!result)
+result = strdup(DIRECT);
+
+sd_bus_reply_method_return(params-message, s, result);
sd-bus is not thread-safe. You cannot send messages from different
threads at the same time...
Why precisely do you need threads here? Because the PAC programs might
be slow?
the Javascript execution is normally blocking and it can do whatever it wants.
If it wants to draw a smiley face, while looking up the proxy, it can do that.
I think the PAC execution needs to be done in a thread, but not the D-Bus
message handling.
WHat about unbounded loops in PAC programs? We need to protect from
that, which kinda suggests we muight want to run the PAC stuff out of
process so that we can neatly kill the program when it runs for too
long?
Remember that in theory for every HTTP request a browser makes it is suppose to
ask the PAC file first. Meaning it will run this a lot. So spawning processes
might be not really useful. Even if we start one PAC processing process for
each interface, you still want threads since you might have multiple requests
from different application. And if one can be answered from a cache, then you
do not want to wait until the Javascript execution finished.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods
Hi Lennart,
+
+static int method_find_proxy(sd_bus *bus, sd_bus_message *message, void
*userdata, sd_bus_error *error) {
+_cleanup_free_ char *p = strdup(DIRECT);
Please don't mix variable declarations and function invocations in one
line (also see CODING_STYLE). Also, missing OOM check...
+Manager *m = userdata;
+int r;
+
+assert(bus);
+assert(message);
+assert(m);
+
+r = proxy_execute(m-default_proxies, message);
+if (r 0)
+sd_bus_reply_method_return(message, s, p);
Hmm, is this right? Shouldn't we return the error code to the client
instead of eating up and returning DIRECT?
Also, why allocate DIRECT with strdup() at all?
there are no errors. Either you get a proxy directive or you return DIRECT to
indicate no proxy. What would you do in an error case anyway. The backup is
always assume no proxy.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl sdio.ids in the release tarballs.
Hi Zybszek, On 16 March 2015 at 23:15, Marcel Holtmann mar...@holtmann.org wrote: Hi Dimitri, Just tell patch or git to skip the hunks modifying ids-update.pl and sdio.ids. Problem solved. I'll apply the patch, but with a slightly different motivation. [L]GPL requires commercial entities distributing a modified version of the program to provide full source in the preferred form for modification, including all scripts used for building. This includes sdio.ids and ids-update.pl. We should make it easy to follow the our licensing, so we should include those files in our tarball to make it directly redistributable. that is just making stuff up. Where was I wrong? Are you now also including usb.ids? We probably should Right, we should include all source files, not only the generated files. is this turning in Freaky Friday now? Can we please be real for a bit. You do realize that I did not put a copyright header on top of sdio.ids. In addition this information will be most likely considered a not copyrightable piece of source anyway. If we assume that this is non-copyrightable, then how can you apply a copyleft license to it? It's not about applying a license to sdio.ids. If may just as well be non-copyrightable. It's just distributed because in the tarball because it is one of the things necessary to generate a patch. please get your story straight. Now it is because of generating a patch. You can tell git to leave certain files or directories out when generating patches. It is plain simple. Now, in practice, any sane person would clone the repository and do modifications there, but the terms of our license demand that redistributors redistribute the source. I think it makes sense to set things up so that if they just use the tarball, they actually are doing that. So where do you think the Bluetooth IDs are coming from? Or the USB IDs or PCI IDs. For me this sounds that someone want to be really lazy with back porting and not add the needed extra switch to exclude these two files while generating patches and/or applying patches. And out of a sudden some bogus license argument gets dragged into it. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl sdio.ids in the release tarballs.
Hi Michael, On 16 March 2015 at 23:15, Marcel Holtmann mar...@holtmann.org wrote: Hi Dimitri, Just tell patch or git to skip the hunks modifying ids-update.pl and sdio.ids. Problem solved. I'll apply the patch, but with a slightly different motivation. [L]GPL requires commercial entities distributing a modified version of the program to provide full source in the preferred form for modification, including all scripts used for building. This includes sdio.ids and ids-update.pl. We should make it easy to follow the our licensing, so we should include those files in our tarball to make it directly redistributable. that is just making stuff up. Where was I wrong? Are you now also including usb.ids? We probably should Right, we should include all source files, not only the generated files. is this turning in Freaky Friday now? Can we please be real for a bit. You do realize that I did not put a copyright header on top of sdio.ids. In addition this information will be most likely considered a not copyrightable piece of source anyway. If we assume that this is non-copyrightable, then how can you apply a copyleft license to it? And honestly I rather take sdio.ids file out of systemd.git and maintain it outside if we start making these weird claims. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl sdio.ids in the release tarballs.
Hi Zbyszek, On 16 March 2015 at 23:15, Marcel Holtmann mar...@holtmann.org wrote: Hi Dimitri, This makes it easier to apply stable branch patches on top of the release tarball. --- Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 856accb..0ed35ac 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3877,7 +3877,9 @@ dist_udevhwdb_DATA = \ hwdb/70-touchpad.hwdb EXTRA_DIST += \ - units/systemd-hwdb-update.service.in + units/systemd-hwdb-update.service.in \ + hwdb/ids-update.pl \ + hwdb/sdio.ids I do not think that these files belong in the tarball. Especially the sdio.ids is not something that should be in the tarball. If it is missing locally, a script can always download it rom systemd.git tree. That is where the source is for these and not the tarball. If you want to apply patches from git, then you can always tell git to exclude these files and it will happily apply the rest of the patch. So I do not see a good enough reason to do this. I should be able to regenerate generated copies of code from things included in the tarball without network or git... I need this precisely because stable patches are patching sdio.ids... which is (a) missing (b) ids-update.pl is missing (c) the files that are generated with ab are not updated (a) and (b) can be solved by telling 'patch' or 'git' to not apply hunks to those files. (c) sounds wrong to me. Whenever we change ids-update.pl and friends, we also run them and commit the results to -git. So either you apply the wrong patch (the ids-update.pl-path instead of the patch that commits the results), or your haven't been looking closely enough. I don't see why a distribution would be interested in fixes for ids-update.pl? It should be ignored and never marked for back-porting. Only if at the same run we also update the generated files, those should be picked up. Looking at stable branch: http://cgit.freedesktop.org/systemd/systemd-stable/log/hwdb?h=v219-stable sdio.ids was changed in http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stableid=c10e229f8222b92117ba38045ddb3e4d7951244a but updated in a later commit http://cgit.freedesktop.org/systemd/systemd-stable/commit/hwdb?h=v219-stableid=9ac622b00ca23f9d01e0ff0c944130be8dc3a0e9 So they do look up to date there. usb.ids does not appear to be in the source tree. To me this looks untidy, as preffered form of modification is not shipped in full neither in git, nor in the tarball. And I do need to modify them, the hwdb is too large and has too many things for my targets thus I'm looking at how to patch them out in a maintainable way. that is pretty much your problem to solve if you do not want the full database. Why is that a stable tree issue? Especially since shrinking the database has nothing to do with ids-update.pl or sdio.ids. Why not just commit ids-update.pl / sdio.ids and generate the .hwdb files on $ make dist, or at autoreconf time? Just tell patch or git to skip the hunks modifying ids-update.pl and sdio.ids. Problem solved. I'll apply the patch, but with a slightly different motivation. [L]GPL requires commercial entities distributing a modified version of the program to provide full source in the preferred form for modification, including all scripts used for building. This includes sdio.ids and ids-update.pl. We should make it easy to follow the our licensing, so we should include those files in our tarball to make it directly redistributable. that is just making stuff up. Are you now also including usb.ids? Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl sdio.ids in the release tarballs.
Hi Dimitri, This makes it easier to apply stable branch patches on top of the release tarball. --- Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 856accb..0ed35ac 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3877,7 +3877,9 @@ dist_udevhwdb_DATA = \ hwdb/70-touchpad.hwdb EXTRA_DIST += \ - units/systemd-hwdb-update.service.in + units/systemd-hwdb-update.service.in \ + hwdb/ids-update.pl \ + hwdb/sdio.ids I do not think that these files belong in the tarball. Especially the sdio.ids is not something that should be in the tarball. If it is missing locally, a script can always download it rom systemd.git tree. That is where the source is for these and not the tarball. If you want to apply patches from git, then you can always tell git to exclude these files and it will happily apply the rest of the patch. So I do not see a good enough reason to do this. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] boot: efi - move background pixel variable into different scope
Hi Kay,
CC src/boot/efi/splash.o
src/boot/efi/splash.c: In function ‘graphics_splash’:
src/boot/efi/splash.c:256:9: warning: missing initializer for field ‘Blue’
of ‘EFI_GRAPHICS_OUTPUT_BLT_PIXEL’ [-Wmissing-field-initializers]
EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { };
^
In file included from /usr/include/efi/efi.h:39:0,
from src/boot/efi/splash.c:18:
/usr/include/efi/efiprot.h:641:9: note: ‘Blue’ declared here
UINT8 Blue;
^
That patch removes the initializer?
indeed, if you do not have background provided, then it is undefined. And also
in the Apple case, the Reserved field would not be set. Anyway, I have no idea
on how to fix this compiler warning the right way.
Alternatively doing something like this shuts it up as well:
EFI_STATUS graphics_splash(UINT8 *content, UINTN len, const
EFI_GRAPHICS_OUTPUT_BLT_PIXEL *background) {
-EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = {};
+EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { 0x00, };
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: add sdio identifiers for Broadcom WLAN cards
Hi Arend, This patch adds the sdio identifiers known to be supported by the brcmfmac open-source driver. Cc: Marcel Holtmann mar...@holtmann.org Signed-off-by: Arend van Spriel ar...@broadcom.com I remove the signed-off-by line since it is not standard practice here and then applied the patch. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] boot: efi - move background pixel variable into different scope
CC src/boot/efi/splash.o
src/boot/efi/splash.c: In function ‘graphics_splash’:
src/boot/efi/splash.c:256:9: warning: missing initializer for field ‘Blue’ of
‘EFI_GRAPHICS_OUTPUT_BLT_PIXEL’ [-Wmissing-field-initializers]
EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = { };
^
In file included from /usr/include/efi/efi.h:39:0,
from src/boot/efi/splash.c:18:
/usr/include/efi/efiprot.h:641:9: note: ‘Blue’ declared here
UINT8 Blue;
^
---
src/boot/efi/splash.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/boot/efi/splash.c b/src/boot/efi/splash.c
index 3f2aa27ddd20..e5c9d270af0a 100644
--- a/src/boot/efi/splash.c
+++ b/src/boot/efi/splash.c
@@ -253,7 +253,6 @@ EFI_STATUS bmp_to_blt(EFI_GRAPHICS_OUTPUT_BLT_PIXEL *buf,
}
EFI_STATUS graphics_splash(UINT8 *content, UINTN len, const
EFI_GRAPHICS_OUTPUT_BLT_PIXEL *background) {
-EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel = {};
EFI_GUID GraphicsOutputProtocolGuid =
EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
EFI_GRAPHICS_OUTPUT_PROTOCOL *GraphicsOutput = NULL;
struct bmp_dib *dib;
@@ -266,6 +265,8 @@ EFI_STATUS graphics_splash(UINT8 *content, UINTN len, const
EFI_GRAPHICS_OUTPUT_
EFI_STATUS err;
if (!background) {
+EFI_GRAPHICS_OUTPUT_BLT_PIXEL pixel;
+
if (StriCmp(LApple, ST-FirmwareVendor) == 0) {
pixel.Red = 0xc0;
pixel.Green = 0xc0;
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] boot: efi - fix missing include
Hi Zbyszek, src/boot/efi/splash.c:312:9: warning: implicit declaration of function ‘graphics_mode’ [-Wimplicit-function-declaration] err = graphics_mode(TRUE); ^ Just push such trivial ones directly. okay, pushed. I couldn't tell if this was intentional because of missing refactoring or just an oversight. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: add sdio identifiers for Broadcom WLAN cards
Hi Arend, This patch adds the sdio identifiers known to be supported by the brcmfmac open-source driver. Cc: Marcel Holtmann mar...@holtmann.org Signed-off-by: Arend van Spriel ar...@broadcom.com there are some commits with Signed-off-by lines, but in general they are not in use. So don't bother with it. --- hwdb/sdio.ids | 10 ++ 1 file changed, 10 insertions(+) diff --git a/hwdb/sdio.ids b/hwdb/sdio.ids index 8a4c713..d617297 100644 --- a/hwdb/sdio.ids +++ b/hwdb/sdio.ids @@ -34,6 +34,16 @@ 5347 GDM72xx WiMAX 02d0 Broadcom Corp. 044b Nintendo Wii WLAN daughter card + a887 BCM43143 WLAN card + 4324 BCM43241 WLAN card + 4329 BCM4329 WLAN card + 4330 BCM4330 WLAN card + 4334 BCM4334 WLAN card + a94c BCM43340 WLAN card + a94d BCM43341 WLAN card + 4335 BCM4335/BCM4339 WLAN card + a962 BCM43362 WLAN card + 4354 BCM4354 WLAN card I would prefer if we keep the file sorted as stated in the header. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name
Hi Lennart, Moreover, if we give people this feature I'm pretty sure we'll get lots of people expecting it to work also for any other sort of name and getting confused when it doesn't. Well, this is something we can fix by documentation, no? Or maybe name the match option differently, maybe OriginalName= or KernelName= or so, and then only matching interfaces where you know that the name was selected by userspace in the first place? I like the idea of OriginalName, much less likely to get people confused. I now implemented that, with the restriction that we cannot match on renamed names. For now I left it open to match on ethX style names, as people in principle could do sensible things like OriginalName=eth* or even OriginalName=eth0 when we know there is only one interface. One thing to consider would be to disallow renaming from a .link file where the OriginalName was used to match. That way we don't have the somewhat odd situation that a .link file can only be applied once (we do not remember the original name, so cannot match on that the second time around, as that would be a mess)... Maybe we should even store the original name in a udev property, so that we can make this fully idempotent simply because we can always check this new property for the original name passed down from the kernel? you do realize that once the kernel renamed the name, it is free to reuse that name again. So eth0 as OriginalName can then be present multiple times. I think that you can only have OriginalName matching if a renaming has never occurred. Otherwise this is really not deterministic. Since foo0 (renamed from eth0) and and bar0 (renamed from eth0) will both match OriginalName=eth0. The difference is only timing and that is inhering racy of course. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
Hi Lennart, That's normal behavior in the case of a platform rfkill device and a device-specific rfkill device. The platform rfkill functionality can sometimes (often?) cut power to the device through BIOS and GPIOs, and it will drop off the USB or PCI bus. But the device itself can also expose rfkill functionality through it's own drivers, that doesn't cause it to drop off the bus. This is your case with the USB-based Bluetooth device and the BIOS-based platform killswitch. Since the routing of all these rfkills is highly model specific, there is no way to know that the platform rfkill has an affect on any other device in a generic way. That would have to be hardcoded into the kernel and would be pretty awful to maintain. Hmm, so, currently we include the rfkill device name in the filename we store in disk (combined with ID_PATH if it is known). For an rfkill device that comes and goes and each time changes its name this filename will not be stable. Is there any way how we can get some stable ID out of these devices, in a way that allows multiple rfkill devices per USB device/interface? I don't see how without kernel change. If rfkill devices shall be reliably recognizable, then we need some kind of sub-USB device stability... actual individual RFKILL switch control is not something that anybody should store anywhere. We support it via /dev/rfkill, but it is not something you can rely on. As you have seen the RFKILL switches can come and go and be re-enumerated at it. For this specific reason we have introduced the RFKILL_OP_CHANGE_ALL where you can either switch on/off all RFKILL switches (comparable to flight mode setting) or where you can switch on/off a specific type of switch (bluetooth, wlan, nfc etc.). What is important that for example Bluetooth comes back up as it is suppose to. So if you do a CHANGE_ALL Bluetooth on, then you would expect to come back after suspend and reboot the same way. So the proper way is record the change all states and keep them. And bring them back after suspend and resume. That is pretty much how ConnMan does it actually since it works on a per technology basis and not individual devices. Of course with this handling a few RFKILL switches will fail to be restored as they were, because people messed with individual switches. There is nothing much you can do about that. Getting a unique RFKILL switch id is really hard. It relies on that your parent exposes a serial number or something really unique that makes it persistent over reboot. And all the platform RFKILL switches are just plain terrible since in most cases we pull some out of the ACPI magic or worse some vendor magic. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hi Tom, Trying unicast, waiting some time and then trying broadcast, if a DHCP offer is not sent within that time limit, seems like a fair thing to do. My 2 cents. Yeah, it seems this is what we should do. I guess it makes sense to make RequestBroadcast=yes|no|automatic, and default to the latter. Please name it auto, not automatic... Please make the time short enough though to still give a nice feeling... I figure the reverse of first trying broadcast, and then trying unicast is unnecessary, right? Yeah, I don't think it makes sense to expose this implementation detail. The preference should be for unicast if we don't know any better, as that causes slightly less network traffic, so I think we should do a couple of unicasts only before starting to do both, but that's not anything the user should care about. if we have a test case that lets us test this easily, someone might want to test the latest ConnMan and see if it does this correctly. Since there we are doing the automatic fallback already. On a side note, once figured out what works, print a nice warning so admins can decide if they want to change the setting permanently to a different default. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
Hi Cameron, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). actually not using avahi-autoipd is the way you really want to go. Especially since networkd will do IPv4LL setup for you anyway. Same applies to ethtool hooks since they should be done by link files and configured by udev. For the wpa_supplicant, we are going to fix that one with a proper daemon soon. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi Lennart, I'm having another issue with private networking in systemd-nspawn. This one I'm not so certain is a bug, but probably some kind of mistake on my part. Base on my reading of the systemd-nspawn man page though, I can't figure out what the problem is. Basically, all I'm tring to do is remove an interface from the host namespace and provide it to the container. Details are included below (This is systemd 216-r3 in Arch Linux ARM). [root@host01 ~]# systemd-nspawn --network-interface=wlan0 -M1 -bD /home/lanvpn/ Spawning container 1 on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface wlan0 to namespace: File exists actually netdev interfaces like wlan0 can not move into network namespaces by themselves. With wireless hardware, the underlying physical device (for example phy0) needs to move into the namespace. Which means that all netdev that belong to a specific phyX will move with it into the namespace. Try using iw phy phyname set netns pid to achieve this. Marcel, what does this internally do? Maybe this is something we should somehow expose in nspawn as well? this nl80211 is based on generic netlink, you would need to do a lot to just add simple support for it. Also for all network interfaces that have complex physical devices as base (including Bluetooth) it is never that dead simple. Maybe it would be useful for systemd-nspawn to add an option to call a binary that takes the PID of the first process in the namespace as first argument. Then you can push additional setup to such a binary. I am actually hacking around a wireless simulator that could make use of this. Since besides actually moving a wiphy into a namespace, it would also need to setup up the simulated pairs of wiphy first. Currently my code duplicates a lot of details that systemd-nspawn is doing already. But wireless specific details should stay out of systemd in my opinion. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi Lennart, this nl80211 is based on generic netlink, you would need to do a lot to just add simple support for it. Also for all network interfaces that have complex physical devices as base (including Bluetooth) it is never that dead simple. Well, sooner or later I figure sd-rtnl will have to learn about genetlink anyway... then your naming for sd-rtnl is pretty much broken right now. RTNL is just one instance of network. And Generic Netlink is another instance of netlink. While nl80211 is an instance on top of Generic Netlink. Triple the fun. Trust me when I say that you do not want to enter the mess that is generic netlink. Maybe it would be useful for systemd-nspawn to add an option to call a binary that takes the PID of the first process in the namespace as first argument. Then you can push additional setup to such a binary. Hmm, I am not too enthusiastic about such plugin interfaces I must say. If it's just a netlink request we should be able to do this natively I figure... That is the thing. It is not just a netlink request. Essentially you need to first resolve nl80211 to its family address, then list the actual wiphy devices and only then can you start looking into moving that wiphy device into the namespace. We are looking into having either network or device namespaces for Bluetooth as well. I am not sure you want to add extra magic to all of these different types of possible users. That is why I am saying, let the user specify a setup that allows to do this clean and do any extra steps. For me this also includes setting up the simulation environment. And that needs a lot of extra work that clearly will not fit into systemd-nspawn. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi James, I'm having another issue with private networking in systemd-nspawn. This one I'm not so certain is a bug, but probably some kind of mistake on my part. Base on my reading of the systemd-nspawn man page though, I can't figure out what the problem is. Basically, all I'm tring to do is remove an interface from the host namespace and provide it to the container. Details are included below (This is systemd 216-r3 in Arch Linux ARM). [root@host01 ~]# systemd-nspawn --network-interface=wlan0 -M1 -bD /home/lanvpn/ Spawning container 1 on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface wlan0 to namespace: File exists actually netdev interfaces like wlan0 can not move into network namespaces by themselves. With wireless hardware, the underlying physical device (for example phy0) needs to move into the namespace. Which means that all netdev that belong to a specific phyX will move with it into the namespace. Try using iw phy phyname set netns pid to achieve this. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing remote wake-up for Bluetooth
Hi Bastien, I wanted to add a toggle box like the one MacOS X has had for a long while, allowing users to wake up their system using a Bluetooth keyboard. The procedure is here: https://github.com/lwfinger/rtl8723au_bt/blob/master/readme.txt We could also always allow remote wake-up when a keyboard or joystick has been paired, I'm not too fussed. Ideas on how this should be implemented? actually there is a bit more to do than just enabling USB remote wakeup. That is just the bare minimum we need to support. On the Bluetooth side, we would actually have to change the HCI event mask to only produce certain events. Otherwise the controller (and with that the host) can wake up for all kinds of reasons. In addition, we would need to program the specific addresses that allow us to wake up. Otherwise anybody knowing your address can trick your system to wake up for no reason. Besides BR/EDR mice and keyboards, we also have LE mice these days. They operate a little bit different and might need some extra magic to handle wake ups. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] watchdog feature highly ineffecient / using too much CPU
Hi Michael, So, lets look at the bluetoothd code: watchdog_usec = getenv(WATCHDOG_USEC); seconds = atoi(watchdog_usec) / (1000 * 1000); watchdog = g_timeout_add_seconds_full(G_PRIORITY_HIGH, seconds / 2, watchdog_callback, NULL, NULL); If WATCHDOG_USEC is smaller than 2,000,000 (2s), then seconds is =1 and thus seconds / 2 is 0. Thus, bluetoothd sends watchdog notifications without any timeout. Two solutions: 1) Don't set such watchdog values for bluetoothd. 2) Fix bluetoothd to use usec instead of seconds. Thanks for the detailed analysis, David. This indeed looks like a bug in bluetooth. Especially since you can break bluetooth completely by setting e.g. WatchdogSec=0.. setting WatchdogSec=0 should disable that feature (as described in the manpage). Which means that systemd should never give us the environment variable WATCHDOG_USEC in the first place. Are you saying that systemd does that. In that case that is a systemd bug. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
Hi Miroslav, ConnMan is a single daemon solution doing NTP, DHCP and DNS all in one place. Any sort of callouts are costing time. And that is time that has a visible user impact. There is nothing that justifies to have a bit more nanosecond accuracy of synchronized time than making the user wait for extra milliseconds to get their network connection and time. You need the first clock update to happen milliseconds after the network is up? Seriously? I agree that's not possible with chronyd or ntpd even if they were listening to networkd, but I don't think it's a requirement on any desktop system. start building a media client. Then you will see that the faster you have your IP address and the faster you have your clocks synchronized, the better your user experience gets. So this is all crucial. Until we fixed DHCP, everybody was fine waiting for many seconds to get an IP address. Now you get the IP in a few 100 milliseconds. But sure, lets go back to 10 years ago where everything took forever. And lets have a boot take 10 minutes. You might realize that a theme shows up here. If you are building a server, then by all means install ntpd or Chrony and configure it. You are the admin, you know what you are doing. If you do not know what are doing or do not care, then keep it simple. I'm not convinced. I think uninformed users should be using the best tool for the typical use case they have at hand. Trading falseticker detection, stable clock control with intermittent connections, ability to drift through when network is congested, ability to deal with broken clocks (as in some virtual machines) and monotonic time just for a super fast update seems like a bad choice to me. Seriously? That is what desktop users want. Cool, can you show me the desktop users that do care about this. I am actually curious now on how you justify doing all that with the expected battery life. I'm sure timesyncd will be significantly improved over time, but currently I'd not describe it as more than appropriate for most installations. That is the beauty of open source. If enough users care it will get added to timesyncd. So people will just start sending patches. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
Hi Miroslav, To have timedated/timedatectl managing the right NTP service on distributions like Fedora. I don't really think that timedated should manage an NTP server like ntpd/chrony. I'm talking about NTP clients, not servers. Writing a good NTP client is the difficult part, making server from a client is just a matter of binding a socket to port 123 and replying to the requests with current time. Anyway, chronyd doesn't reply to NTP requests by default, so think of it as an NTP client in this context. and writing a good DHCP client was supposedly also really hard. Guess what we have done that twice now and both of our clients are better than everything else out there. And guess what, we did the same for NTP. timedated's primary job is to be a service to GNOME and other DEs. But if an admin wants to upgrade to a full NTP server, then he should really enable/disable that with systemctl or a similar command. Distributions usually have a full NTP client installed by default, why should GNOME try to enable/disable an SNTP client that happens to be distributed with systemd? And that is the part that really needs to change. Desktop systems using a high accuracy NTP client instead of just using SNTP is a bad idea. Especially using NTP clients that are not aware of network states and/or states like Hotspot portals. Or think about systems using 3G/LTE connections. The code wasn't wrong for what it was supposed to do. We just didn't think the complexity of it would be appropriate. Ok, this patch to make it configurable at compilation time is extremely simple and there is zero runtime cost, so there should be no problem in including it, or not? If your suggestion is to use timesyncd by default on all systems where systemd is included, that might not work. Even if you don't care much about accuracy, stability or monotonicity of the system clock, I don't see why timesyncd would be any different regarding monotonicity that chrony would... After start chronyd uses only slewing to correct the clock, but timesyncd seems to step the clock when the offset is larger than 0.4 second and is not a spike. With an intermittent or congested internet connection suffering from bufferbloat it's pretty easy to get offsets larger than that. The adjtime system call is limited by the kernel and how much it can adjust. I do not remember that actual details, but at some point you are required to skip time. Trying to emulate that in userspace is a bad idea. Either the kernel can do it for you or you just skip to the next synchronized time you have. there is a problem with reliability. As timesyncd currently implements only SNTP and not full NTP client, it doesn't compare times from multiple servers, so it can't know when a server is broken and another should be selected instead. Well, if we start comparing features, then there's also some stuff that timesyncd can do that chrony can't (such as getting NTP server info from DHCP networkd, or support for offline clock monotonicity of RTC-less systems). Ok, chronyd is usually used with NetworkManager and it relies on a dispatcher script to get the servers from DHCP. Adding support to get them from networkd doesn't sound like a very difficult task if it's needed. Or could be networkd modified to write the list of the servers to a file so any NTP client could use it? As for systems without RTC, chronyd now has an option to restore the time similarly to the fake-hwclock script from Debian. If you ever tried to control a NTP client from the network managing daemon, then you would realize that this is all not designed to be controlled by any form of automated system or desktop environments like Gnome. Chrony and ntpd are for system administrators and systems that run with a basically static configuration in a datacenter. If you are thinking they are for anything else than you are kidding yourself. And that is exactly the point here. If you install a full blown high accuracy NTP client, then you know what you are doing and you know why you are doing it. Even inside ConnMan, we decided to include a SNTP client directly into ConnMan. In earlier days, we had ConnMan controlling ntpd's client. Ugly and complicated and also full of race conditions. We looked into Chrony and it was no better at all. We tried to write our own SNTP client that we control and can feed DHCP information into it. Worked beautifully and is still in use today and actual consumer products. If you want to see a popular one then take a look at the Nest Labs thermostat. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
Hi Miroslav, and writing a good DHCP client was supposedly also really hard. Guess what we have done that twice now and both of our clients are better than everything else out there. And guess what, we did the same for NTP. Are you saying timesyncd is already better than chronyd or ntpd? In what criteria? To me it looks like the only advantage currently is the integration with networkd. I see some trivial bugs in the code, I'll send patches. for a desktop environment like Gnome, yes timesyncd is already a huge step into the right direction. The integration with networkd or any kind of network management software is a huge advantage. Especially if you are looking at mobile devices like phones and laptops. Desktop systems using a high accuracy NTP client instead of just using SNTP is a bad idea. Especially using NTP clients that are not aware of network states and/or states like Hotspot portals. Or think about systems using 3G/LTE connections. An NTP client can be aware of network states too, I'm not sure why should be SNTP preferred over NTP. On mobile networks I'd probably want to use a client that can work well with intermittent connections, not something using the kernel PLL as it's unstable when under sampled. The question is what costs to be aware of network states. So first of all you need to watch operational states and do that correctly. Then you need to understand routing tables to see if you can actually get anywhere. Then you need to know if you can resolve addresses. If you are on a per interface level, then you need to know which DNS servers are valid for that interface. Not all DNS servers are valid for each interface. At the end of the day anything else other than timesyncd would need to duplicate a lot of functionality that is in networkd and resolved. And I think that is precisely the point here. If you are in a datacenter, and you need Chrony or ntpd level of NTP time synchronization, then just install it. Otherwise let the desktop run SNTP via timesyncd. The adjtime system call is limited by the kernel and how much it can adjust. I do not remember that actual details, but at some point you are required to skip time. Trying to emulate that in userspace is a bad idea. Either the kernel can do it for you or you just skip to the next synchronized time you have. The adjtime() offset isn't limited, but adjtimex() in PLL mode limits the offset to 0.5 second. chronyd controls the kernel frequency directly and if an update is late, the next correction is compensated for that. From what I can tell it works very well. If you are in the datacenter, by all means, try to be as smart as you want to be. However bothering the general user with this is just crazy stuff. And if you think that networkd, resolved, timedated and timesyncd are doing anything new, then you are pretty much mistaken. We have been through this with ConnMan a few years back already. All of this needs to be tightly integrated. So this means that you get a really good basis where clocks are synchronized. If you want something better, you can install it. It is a waste of time trying to integrate anything else than timesyncd since if you use anything else, you will manually configure it and use its advanced options. If you do not need the advanced features, then why install other NTP clients in the first place. Even inside ConnMan, we decided to include a SNTP client directly into ConnMan. In earlier days, we had ConnMan controlling ntpd's client. Ugly and complicated and also full of race conditions. We looked into Chrony and it was no better at all. We tried to write our own SNTP client that we control and can feed DHCP information into it. Worked beautifully and is still in use today and actual consumer products. Ok, how exactly are you feeding the NTP client? Perhaps it's something we could use in chronyd too. ConnMan is a single daemon solution doing NTP, DHCP and DNS all in one place. Any sort of callouts are costing time. And that is time that has a visible user impact. There is nothing that justifies to have a bit more nanosecond accuracy of synchronized time than making the user wait for extra milliseconds to get their network connection and time. You might realize that a theme shows up here. If you are building a server, then by all means install ntpd or Chrony and configure it. You are the admin, you know what you are doing. If you do not know what are doing or do not care, then keep it simple. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH kdbus] handle: Return POLLOUT | POLLWRNORM mask when no messages are pending
Hi Lennart, To facility the feature of doing an asynchronous sending of messages when the bus is idle, make sure to return POLLOUT | POLLWRNORM from kdbus_handle_poll. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/handle.c b/handle.c index ac6868133280..fc15d28351b3 100644 --- a/handle.c +++ b/handle.c @@ -884,6 +884,8 @@ static unsigned int kdbus_handle_poll(struct file *file, mask |= POLLERR | POLLHUP; else if (!list_empty(conn-msg_list)) mask |= POLLIN | POLLRDNORM; + else + mask |= POLLOUT | POLLWRNORM; Hmm, what's your use case here? list_empty(conn-msg_list) only checks the incoming list of the current connection for pending messages. That doesn't tell you whether the bus is idle, or if your receiving end has messages pending ... if you are a good client citizen, then you only send messages when POLLOUT gets signaled. That is what this is allowing now. Blindly sending messages is never a good idea. You want to poll for POLLOUT first. This does not make a big difference for current kernel, but it allows future extensions when the clients are well behaving and just waiting for POLLOUT. Meaning once the kernel does not signal POLLOUT, no new messages will come from the client. Current code does not do this POLLOUT before sending a messages, but our kdbus client actually does that. It is the right thing to do. And we have been doing this with all of our protocols that are using asynchronous IO. No point in kdbus being any different. Well, kdbus keeps per-reciever buffers only, hence signalling on the kdbus fd when you are able to write is not really possible, since this information is not bound to the sender fd but only to the receiever of which there are many... If I understand you correctly you hence want the kdbus fd to always return EPOLLOUT then, because if a client wants to send something it can do that at any time? If that's the case then POLLOUT should really be ORed into the mask unconditionally, not just in some cases... So, I can sympathize with what you are trying to do. However, I think your patch doesn't do the right thing... It should really OR the POLLOUT into all masks always. always returning POLLOUT is also fine. As long as the fd signals POLLOUT and not just swallows it. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH kdbus] handle: Return POLLOUT | POLLWRNORM mask when no messages are pending
To facility the feature of doing an asynchronous sending of messages when the bus is idle, make sure to return POLLOUT | POLLWRNORM from kdbus_handle_poll. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/handle.c b/handle.c index ac6868133280..fc15d28351b3 100644 --- a/handle.c +++ b/handle.c @@ -884,6 +884,8 @@ static unsigned int kdbus_handle_poll(struct file *file, mask |= POLLERR | POLLHUP; else if (!list_empty(conn-msg_list)) mask |= POLLIN | POLLRDNORM; + else + mask |= POLLOUT | POLLWRNORM; mutex_unlock(conn-lock); return mask; -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH kdbus] handle: Return POLLOUT | POLLWRNORM mask when no messages are pending
Hi Daniel, To facility the feature of doing an asynchronous sending of messages when the bus is idle, make sure to return POLLOUT | POLLWRNORM from kdbus_handle_poll. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/handle.c b/handle.c index ac6868133280..fc15d28351b3 100644 --- a/handle.c +++ b/handle.c @@ -884,6 +884,8 @@ static unsigned int kdbus_handle_poll(struct file *file, mask |= POLLERR | POLLHUP; else if (!list_empty(conn-msg_list)) mask |= POLLIN | POLLRDNORM; +else +mask |= POLLOUT | POLLWRNORM; Hmm, what's your use case here? list_empty(conn-msg_list) only checks the incoming list of the current connection for pending messages. That doesn't tell you whether the bus is idle, or if your receiving end has messages pending ... if you are a good client citizen, then you only send messages when POLLOUT gets signaled. That is what this is allowing now. Blindly sending messages is never a good idea. You want to poll for POLLOUT first. This does not make a big difference for current kernel, but it allows future extensions when the clients are well behaving and just waiting for POLLOUT. Meaning once the kernel does not signal POLLOUT, no new messages will come from the client. Current code does not do this POLLOUT before sending a messages, but our kdbus client actually does that. It is the right thing to do. And we have been doing this with all of our protocols that are using asynchronous IO. No point in kdbus being any different. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
Hi Dan, Now that networkd can send the systems hostname to the dhcp server, I would find it useful to have an option to override the hostname that gets sent. In my use case, I would like to setup a number of macvlans with different hostnames. Something as simple as [DHCP] SendHostname=true Hostname=foo Sounds useful, though this could just be a single option SendHostname=foobar or so. If not set it sends the system hostname, otherwise the specified hostname. Or something like that. what would this be useful for? Either you send the hostname or you don't. I think what you are looking for is an option to set the Client ID. And when that is set, then that is used. If it not set and SendHostname=true, the hostname is used as Client ID. If SendHostname=false and Client ID is not send, then none of them are send. Typically the send-hostname thing is actually used for DNS updates, where you send the hostname to the DHCP server, which then gives you a lease and sends the hostname + IP to the DNS server, so that your machine is accessible via DNS automatically. I've never heard of it being used as a Client ID, and AFAIK the send hostname and client ID can both be used at the same time. this means that allowing to provide a custom hostname that is not set via hostname or hostnamectl makes no sense at all. Since you want to send your actual hostname. So current boolean for SendHostname is the right way to do this. In addition someone might add a ClientId=foo option. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd Promiscuous mode
Hi Lennart, There seems to be no way in systemd-networkd to put a link in Promiscuous mode. This is needed to make macvlan work correctly (Otherwise it receives no traffic with its mac address as the destination). If I am not mistaken this could be a boolean in *.link files. Sounds useful. Added to the todo list. actually this sounds like a design mistake. If macvlan requires the network interface in promiscuous mode, then it should do that internally. Inside the kernel the promiscuous mode is actually reference counted. This can for example be utilized from packet(7) sockets. That way you do not accidentally leave a device in promiscuous mode if all users are gone. So why not fix macvlan to put the parent into promiscuous mode. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
Hi Lennart, Now that networkd can send the systems hostname to the dhcp server, I would find it useful to have an option to override the hostname that gets sent. In my use case, I would like to setup a number of macvlans with different hostnames. Something as simple as [DHCP] SendHostname=true Hostname=foo Sounds useful, though this could just be a single option SendHostname=foobar or so. If not set it sends the system hostname, otherwise the specified hostname. Or something like that. what would this be useful for? Either you send the hostname or you don't. I think what you are looking for is an option to set the Client ID. And when that is set, then that is used. If it not set and SendHostname=true, the hostname is used as Client ID. If SendHostname=false and Client ID is not send, then none of them are send. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Changing configurations with networkd
Hi Tom, I think the lease should be remembered and reused in this case. Hm, this sounds like a bug somewhere. When the new discover is sent out it should send the same identifying information to the server, and hence be given the same lease back again. Wireshark should tell you if the fault is networkd's or the DHCP server. I get the same address at first, but after several minutes the DHCP server decides to offer a new address. I should note, that I have a 10 minute lease time for debugging purposes, so that might make the problem more prominent. I'll see if I can figure out what happens here. look at your DHCP server and see what lease time it really hands out after reboot. However this is between you and your DHCP server. If you configure a lease time of 10 minutes, then that is the only guaranteed time for a given IP address. There is no mandate that the server has to give you the same address after 10 minutes when you ask again. It is valid to just get a different one. And that many home routers try to give you back the same one does not mean that they are required to do so. The nice DHCP servers will remember your Ethernet address and/or identity information and give you back your old IP address. Either with the left over lease time or with a brand new lease time. There is really no need to store this information on disk. If the lease expired the information on disk are stale as well. And since our DHCP implementation is so fast, it makes really no difference. It is safer start out with a brand new DHCP lease instead of having to deal with renewal during boot. At least that way you know the DHCP server is still there and you have a valid IP address. Just re-using a stored IP with a left-over lease is not safe anyway. You never know what changed in the network when you were off. I think there was some misunderstanding here. I don't want to keep the lease across reboots. I don't care about that. I think networkd should remember the lease when restarting networkd only and not send a new dhcp discover. Right, I spoke too quickly. What I don't want is to preserve state between reboots, preserving it between restarts of networkd would indeed be fine. We already serialize the dhcp leases to /run, so I'd be happy to take a patch to deserialize these again when networkd starts. I am not sure this is useful either. It feels like a bandaid for the time where networkd does not have an API to reload configuration changes. Killing networkd should give you a clean start from the configuration files and not magic cached value somewhere. Otherwise you end up with funny side effects all the time and have to explain to users to clear some /run states. Or ask them to switch the computer off and back on again. When you are opting for DHCP instead of static addresses, then there is really no guarantee for addresses staying the same. At least not for the client to know. So unless you own the DHCP server and configure it with static assignment. In all cases you have to confirm with the DHCP server that you address is still valid. That said, I'm not sure this will help you much in your case. It would allow us to explicitly request the current IP address when restarting networkd, but according to your previous email you already are getting assigned the correct IP address at first, and then only later does this change. What is causing your DHCP server to send out a different IP address later on, I don't know, but it seems unlikely that this is anything we can fix in the client. I have my doubts as well here. Seems like a misconfigured DHCP server. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Changing configurations with networkd
Hi Michael, I think the lease should be remembered and reused in this case. Hm, this sounds like a bug somewhere. When the new discover is sent out it should send the same identifying information to the server, and hence be given the same lease back again. Wireshark should tell you if the fault is networkd's or the DHCP server. I get the same address at first, but after several minutes the DHCP server decides to offer a new address. I should note, that I have a 10 minute lease time for debugging purposes, so that might make the problem more prominent. I'll see if I can figure out what happens here. look at your DHCP server and see what lease time it really hands out after reboot. However this is between you and your DHCP server. If you configure a lease time of 10 minutes, then that is the only guaranteed time for a given IP address. There is no mandate that the server has to give you the same address after 10 minutes when you ask again. It is valid to just get a different one. And that many home routers try to give you back the same one does not mean that they are required to do so. The nice DHCP servers will remember your Ethernet address and/or identity information and give you back your old IP address. Either with the left over lease time or with a brand new lease time. There is really no need to store this information on disk. If the lease expired the information on disk are stale as well. And since our DHCP implementation is so fast, it makes really no difference. It is safer start out with a brand new DHCP lease instead of having to deal with renewal during boot. At least that way you know the DHCP server is still there and you have a valid IP address. Just re-using a stored IP with a left-over lease is not safe anyway. You never know what changed in the network when you were off. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add support for DHCP static route options in networkd
Hi Lennart, I am tempted to say that we should try to apply as much information from DHCP as we can by default, but make sure it doesn't become a security problem. i.e. we should probably use metrics or so so that manual routes always win, or routes to other interfaces. I think using metrics is a good idea. Are there some accepted guidelines on what reasonable values for route metrics should be? Static routes (from [Route]) are added with 0, what would a good value for DHCP routes be? 100? 1000? Hmm, something in the middle of the range, I figure, that is still nice to type and look at for whatever that is. pick something... Also I figure the default route added due to dhcp config should also use this same metric. it might actually make sense to provide a configuration option for the metric value here. And if not present just default to something that make sense. Seems like 1024 is pretty popular. Allowing different metrics for multi homing situation seems like a neat benefit. If by all means possible, add all routes provided by DHCP for eth0 with metric A and for eth1 use metric B. You never know what kind of datacenter network configuration you encounter. I have seen really crazy ones in my lifetime ;) Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tuntap device
Hi Tom, This patch introduces tuntap support to networkd. Example conf file : tuntap.netdev [NetDev] Name=tuntap-test Kind=tuntap [TUNTAP] Hm, maybe call this TunTap instead? Mode=tap OneQueue=true MultiQueue=true PacketInfo=true I wonder if it might be better separate in Tun and in Tap devices. Tun devices are IP only devices and Tap devices are actual Ethernet devices. It looks a bit silly that you have to specific Kind=tuntap only to later specific Mode=tap. Why not just do Kind=tap device? That under Linux the setup of both Tun and Tap devices happens via /dev/net/tun is just an implementation detail. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
Hi Cristian, When enabled in [Network] it will set up a dhcp server on the interface, listening on one of its statically configured IPv4 addresses and with a fixed size pool of leases determined from it. Hi Tom, before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Yeah IMHO the dhcp server should be a separate daemon, that of course does not preclude it from sharing code with networkd. that is not a good idea. Why would you make the DHCP server a separate daemon. That is just asking for trouble. The only way to provide a proper integration is if the DHCP server is part of systemd-networkd. Otherwise you are just wasting time in trying to figure out on how to handle configuration and update of states between two daemon. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: Loosing nic's driver set functionality
Hi Umut, Making RTM_GETLINK and RTM_SETLINK asynchronously is causing RTM_SETLINK to remove the nic's functionality. In my case, I am loosing IFF_MULTICAST after networkd sets the interface up. I am not sure if 5d4795f37229 can solve the problem but the only documentation I found was stating ifi_change is reserved so I didn't look in to it. I have converted GETLINK call to sync and made sure SETLINK uses the flags coming from GETLINK call. Attaching a patch for it. Please ignore it if you can solve the problem in another way. RTNL is not a synchronous interface. This is just paper over a hole approach. It is not stopping anybody from doing any modification behind your back while you think you wait for your GETLINK response. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] net: set default DEVTYPE for all ethernet based devices
Hi Tom,
In systemd's networkd and udevd, we would like to give the administrator a
simple way to filter ethernet devices by their DEVTYPE. In order to avoid
having a special treatment of the case where DEVTYPE=(null), initialize
it to
a default value, ethernet, in the kernel.
Signed-off-by: Tom Gundersen t...@jklm.no
Cc: Marcel Holtmann mar...@holtmann.org
Cc: Greg KH gre...@linuxfoundation.org
---
Hi Greg and Marcel,
This patch seems to do the right thing for me. Any comments before I send
it
off to LKML?
I suppose it may make sense to hide this behind a kernel option in case
we are
worried about breaking existing users (but if ConnMan is adapted, I don't
know
of any other issues, NetworkManager is not affected at least).
Cheers,
Tom
net/core/dev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index ba3b7ea..62881e0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6215,6 +6215,10 @@ void netdev_freemem(struct net_device *dev)
kfree(addr);
}
+static const struct device_type ethernet_type = {
+ .name = ethernet,
+};
+
/**
*alloc_netdev_mqs - allocate network device
*@sizeof_priv: size of private data to allocate space for
@@ -6305,6 +6309,8 @@ struct net_device *alloc_netdev_mqs(int
sizeof_priv, const char *name,
goto free_all;
#endif
+ SET_NETDEV_DEVTYPE(dev, ethernet_type);
+
strcpy(dev-name, name);
dev-group = INIT_NETDEV_GROUP;
if (!dev-ethtool_ops)
this means that every single netdev is defaulting to Ethernet. This
includes also the fake ones like IrDA or raw IP ones like PPP or TUN
devices. I do not think that is something we really want here.
Hm, so then the assumption I first worked under (DEVTYPE==(null) means
ethernet) is not really correct. Doesn't this give you problems in
ConnMan at the moment?
that is why I mentioned ARPHRD_* earlier. It is important to check that
value as well. You will need both at some point.
Hm, I thought that was to fix false negatives. I.e., that some devices
with, say, DEVTYPE=bluetooth should in fact be treated as regular
ethernet?
DEVTYPE=bluetooth and DEVTYPE=wlan are not false negatives. They should be like
that. That is something current userspace relies on. We can not break this.
However you will see a DEVTYPE=bluetooth as Ethernet emulation and another as
raw IP (6loWPAN). You want to differentiate these for the default address
assignment you pick. For example 6loWPAN will just rely on IPv6 route
solicitation.
Same applies to DEVTYPE=wwan btw. Some Qualcomm cards can be exposed as
Ethernet or they do a raw IP only header in their netdev. DEVTYPE is just to
figure out the underlying technology of your network device. Then the ARPHRD_
is to get an idea of the actual encapsulation that is used.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] net: set default DEVTYPE for all ethernet based devices
Hi Tom,
In systemd's networkd and udevd, we would like to give the administrator a
simple way to filter ethernet devices by their DEVTYPE. In order to avoid
having a special treatment of the case where DEVTYPE=(null), initialize it to
a default value, ethernet, in the kernel.
Signed-off-by: Tom Gundersen t...@jklm.no
Cc: Marcel Holtmann mar...@holtmann.org
Cc: Greg KH gre...@linuxfoundation.org
---
Hi Greg and Marcel,
This patch seems to do the right thing for me. Any comments before I send it
off to LKML?
I suppose it may make sense to hide this behind a kernel option in case we are
worried about breaking existing users (but if ConnMan is adapted, I don't know
of any other issues, NetworkManager is not affected at least).
Cheers,
Tom
net/core/dev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index ba3b7ea..62881e0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6215,6 +6215,10 @@ void netdev_freemem(struct net_device *dev)
kfree(addr);
}
+static const struct device_type ethernet_type = {
+ .name = ethernet,
+};
+
/**
*alloc_netdev_mqs - allocate network device
*@sizeof_priv: size of private data to allocate space for
@@ -6305,6 +6309,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv,
const char *name,
goto free_all;
#endif
+ SET_NETDEV_DEVTYPE(dev, ethernet_type);
+
strcpy(dev-name, name);
dev-group = INIT_NETDEV_GROUP;
if (!dev-ethtool_ops)
this means that every single netdev is defaulting to Ethernet. This includes
also the fake ones like IrDA or raw IP ones like PPP or TUN devices. I do not
think that is something we really want here.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] net: set default DEVTYPE for all ethernet based devices
Hi Tom,
In systemd's networkd and udevd, we would like to give the administrator a
simple way to filter ethernet devices by their DEVTYPE. In order to avoid
having a special treatment of the case where DEVTYPE=(null), initialize it
to
a default value, ethernet, in the kernel.
Signed-off-by: Tom Gundersen t...@jklm.no
Cc: Marcel Holtmann mar...@holtmann.org
Cc: Greg KH gre...@linuxfoundation.org
---
Hi Greg and Marcel,
This patch seems to do the right thing for me. Any comments before I send it
off to LKML?
I suppose it may make sense to hide this behind a kernel option in case we
are
worried about breaking existing users (but if ConnMan is adapted, I don't
know
of any other issues, NetworkManager is not affected at least).
Cheers,
Tom
net/core/dev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index ba3b7ea..62881e0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6215,6 +6215,10 @@ void netdev_freemem(struct net_device *dev)
kfree(addr);
}
+static const struct device_type ethernet_type = {
+ .name = ethernet,
+};
+
/**
*alloc_netdev_mqs - allocate network device
*@sizeof_priv: size of private data to allocate space for
@@ -6305,6 +6309,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv,
const char *name,
goto free_all;
#endif
+ SET_NETDEV_DEVTYPE(dev, ethernet_type);
+
strcpy(dev-name, name);
dev-group = INIT_NETDEV_GROUP;
if (!dev-ethtool_ops)
this means that every single netdev is defaulting to Ethernet. This includes
also the fake ones like IrDA or raw IP ones like PPP or TUN devices. I do
not think that is something we really want here.
Hm, so then the assumption I first worked under (DEVTYPE==(null) means
ethernet) is not really correct. Doesn't this give you problems in
ConnMan at the moment?
that is why I mentioned ARPHRD_* earlier. It is important to check that value
as well. You will need both at some point.
What do you think would be the correct behavior? To use this patch,
but also patch up IrDA, PPP, TUN and whatever else to set real
DEVTYPE's; or to leave them as essentially 'unknown', and go through
the ethernet drivers and set them to DEVTYPE='ethernet' one-by-one?
The kernel has an alloc_etherdev_mqs() that might be a better starting point.
However even then, you might still need to fix some false positives.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] networkd/udev: match on 'ethernet' devices
Hi Tom, I just pushed a change[0] which allows the match syntax Type=ethernet to match on network devices without a DEVTYPE. We had a discussion on IRC whether we should call it Type=wired or Type=ethernet. I think the former may be more intuitive, but the latter seems to be more in line with what is done elsewhere (connman calls it ethernet, and udev prefixes the devices names with 'en'). Any thoughts? Any reason why the kernel can't be setting this value in the first place so you don't have to rely on it being null? Seems like a kernel issue. I asked Marcel the same thing earlier. He said: [Friday 03 January 2014] [19:58:22] holtmann Because you have to touch every single driver to get this done properly. [Friday 03 January 2014] [19:58:34] holtmann So DEVTYPE= means it is wired Ethernet. [Friday 03 January 2014] [19:58:42] holtmann If that is not true, then that is a bug. From my point of view, I'd prefer the kernel just doing the right thing (and I'd be happy to write the patches), but my impression was that that's not going to happen...(?) It shouldn't need to be set for every driver, wireless doesn't work this way, so there is lots of precident for how to do this in only a few lines of kernel code :) Also, if we start setting DEVTYPE=ethernet in the kernel, I guess apps (such as connman) that relies on DEVTYPE=(null) to detect ethernet devices will break. Ah, that's a different problem, we can't break userspace. Ugh, well, if you want me to try to make this change, I will. If you see a way to make it happen, that'd be great (and I can revert this patch). we can easily update ConnMan to handle DEVTYPE= and DEVTYPE=ethernet. That is an easy change and will keep things working. As I explained in the other reply, the main reason for DEVTYPE=something is to detect that it is a network device that needs a management entity before it becomes useful. You also need to check the ARPHRD_ type of an interface to make sure it is actually Ethernet and not just rely on what DEVTYPE= is telling you. We are having the case with Bluetooth right now that you get DEVTYPE=bluetooth, but one of them is Ethernet emulation via BNEP and the other raw IP via 6loWPAN. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] networkd/udev: match on 'ethernet' devices
Hi Tom, we can easily update ConnMan to handle DEVTYPE= and DEVTYPE=ethernet. That is an easy change and will keep things working. As I explained in the other reply, the main reason for DEVTYPE=something is to detect that it is a network device that needs a management entity before it becomes useful. You also need to check the ARPHRD_ type of an interface to make sure it is actually Ethernet and not just rely on what DEVTYPE= is telling you. We are having the case with Bluetooth right now that you get DEVTYPE=bluetooth, but one of them is Ethernet emulation via BNEP and the other raw IP via 6loWPAN. So the usecase I see for the DEVTYPE is quite different. I'm simply interested in using it to let the administrator classify devices in an intuitive and predictable way, so in this case (I think) we actually do want to use Type=bluetooth for all bluetooth devices, regardless of the actual protocols they speak. Also, having DEVTYPE=ethernet set by the kernel becomes quite useful as there is no 'magic' going on, and the admin can simply read 'udevadm info' to know whether or not a given device will match. I am all for doing a DEVTYPE=ethernet. It was just not that simple when I introduce DEVTYPE for network interfaces. Maybe things have also changed now. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 01/26] dhcp: Add DHCP protocol structures and initial defines
Hi Patrik, I agree with Zbigniew: this should probably be in src/libsystemd-dhcp/, so that this is similar to libsystemd-bus/, libsystemd-id128/ and so on... Sent a patch for that, and in the process of creating an account on freedesktop.org. As that will most probably take some time, someone with proper access could bite the bullet... I will take care of getting these patches committed. Can you just send an updated version with everything in place in the right location. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dhcp: Move src/dhcp to src/libsystemd-dhcp
Hi Patrik, --- Makefile.am | 42 +- src/dhcp/Makefile |1 - src/dhcp/client.c | 1002 - src/dhcp/internal.h | 41 - src/dhcp/network.c| 65 -- src/dhcp/option.c | 184 src/dhcp/protocol.h | 119 --- src/dhcp/test-dhcp-client.c | 224 - src/dhcp/test-dhcp-option.c | 377 src/libsystemd-dhcp/Makefile |1 + src/libsystemd-dhcp/client.c | 1002 + src/libsystemd-dhcp/internal.h| 41 + src/libsystemd-dhcp/network.c | 65 ++ src/libsystemd-dhcp/option.c | 184 src/libsystemd-dhcp/protocol.h| 119 +++ src/libsystemd-dhcp/test-libsystemd-dhcp-client.c | 224 + src/libsystemd-dhcp/test-libsystemd-dhcp-option.c | 377 17 files changed, 2034 insertions(+), 2034 deletions(-) delete mode 12 src/dhcp/Makefile delete mode 100644 src/dhcp/client.c delete mode 100644 src/dhcp/internal.h delete mode 100644 src/dhcp/network.c delete mode 100644 src/dhcp/option.c delete mode 100644 src/dhcp/protocol.h delete mode 100644 src/dhcp/test-dhcp-client.c delete mode 100644 src/dhcp/test-dhcp-option.c create mode 12 src/libsystemd-dhcp/Makefile create mode 100644 src/libsystemd-dhcp/client.c create mode 100644 src/libsystemd-dhcp/internal.h create mode 100644 src/libsystemd-dhcp/network.c create mode 100644 src/libsystemd-dhcp/option.c create mode 100644 src/libsystemd-dhcp/protocol.h create mode 100644 src/libsystemd-dhcp/test-libsystemd-dhcp-client.c create mode 100644 src/libsystemd-dhcp/test-libsystemd-dhcp-option.c instead of moving everything around after the fact, I would say we better start off with a clean patch set and everything in the right spot in the first place. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? The problem with NSS is that it still does not fix the fundamental problem. It is sequential and blocking. You can spawn as many threads as you want and it will stay sequential. I fully agree with you that we need to consider /etc/hosts, the local hostname and also mDNS, but I get the feeling it would be more beneficial to just build that in. ConnMan ships a DNS proxy cache to actually be able to be smart and parallel. We did not bother with the details like /etc/hosts so far since our use cases always had an empty /etc/hosts with just localhost only anyway. However that is easy to fix. Spawning threads or forking is expensive (even if you reuse it) comparing to what you actually do here. You just want to resolve a host. It is especially expensive since you can not control on what is actually used. And there are clearly use cases where you have to ask a specific nameserver or set of nameservers. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] logs-show.c: Fix missing sys/socket.h include
CC src/shared/logs-show.lo src/shared/logs-show.c: In function 'get_boot_id_for_machine': src/shared/logs-show.c:1153:9: warning: implicit declaration of function 'socketpair' [-Wimplicit-function-declaration] if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sock) 0) ^ src/shared/logs-show.c:1153:24: error: 'AF_UNIX' undeclared (first use in this function) if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sock) 0) ^ src/shared/logs-show.c:1153:24: note: each undeclared identifier is reported only once for each function it appears in src/shared/logs-show.c:1153:33: error: 'SOCK_DGRAM' undeclared (first use in this function) if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sock) 0) ^ src/shared/logs-show.c:1179:17: warning: implicit declaration of function 'send' [-Wimplicit-function-declaration] k = send(sock[1], buf, 36, MSG_NOSIGNAL); ^ src/shared/logs-show.c:1179:44: error: 'MSG_NOSIGNAL' undeclared (first use in this function) k = send(sock[1], buf, 36, MSG_NOSIGNAL); ^ src/shared/logs-show.c:1189:9: warning: implicit declaration of function 'recv' [-Wimplicit-function-declaration] k = recv(sock[0], buf, 36, 0); ^ --- src/shared/logs-show.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc7569429..0e3fd3de2630 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logs-show.c: Fix missing sys/socket.h include
Hi Zbyszek, diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc7569429..0e3fd3de2630 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h Marc-Antoine sent an identical patch, applied the other one. I would have picked the one with the clear commit subject and not this generic one. I had too generic commit messages ;) Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
Hi Andrey, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. that is extremely heavy and must suck form a latency point of view. Then again, nothing that a DNS-LDAP bridge couldn’t easily support. Since dragging LDAP dependencies into every program that has to load NSS modules is not a good idea either. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. that is extremely heavy and must suck form a latency point of view. Then again, nothing that a DNS-LDAP bridge couldn’t easily support. Since dragging LDAP dependencies into every program that has to load NSS modules is not a good idea either. Note that nscd was created to deal with the performance of the LDAP setups and also doesn't require loading everything into the same process. and that is an excuse to keep using NSS modules? We took a rather shitty idea and hacked it up a little and it is now a little bit less shitty. Just to be clear, I have nothing against the general idea, I am just saying that NSS itself with its current design is pretty limited. And keep working around it is not helping either. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 01/26] dhcp: Add DHCP protocol structures and initial defines
Hi Lennart, +uint32_t ciaddr; +uint32_t yiaddr; +uint32_t siaddr; +uint32_t giaddr; Hmmm, why uin32_t? Shouldn't this be32_t? THis is network byte order, right? which is just synoymous to big endian... Or even, if you now use struct in_addr elsewhere anyway, why not just use that here too? be32_t seems reasonable, the 'struct in_addr' was deemed to add slightly too much cruft without being particularly useful in internal code. What if we figure out whether this patch set is otherwise reasonable and fix this and add the remaining parts of DHCP in a coming patch set? Meanwhile Tom could take the code for an official test spin... This code looks as if it's ready to be merged. WHatever else comes up can be fixed post-commit. I think it would be best if you'd get commit access so that you can maintain this. are you fine with the layout of files and directories? Then I can start handling maintaining it and dealing with patches. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hashmap: Remove unused auxv variable
CC src/shared/hashmap.lo
src/shared/hashmap.c: In function 'hashmap_new':
src/shared/hashmap.c:188:15: warning: unused variable 'auxv' [-Wunused-variable]
void *auxv;
^
---
src/shared/hashmap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/shared/hashmap.c b/src/shared/hashmap.c
index 8f5957b4ac80..d8d6bc719d2a 100644
--- a/src/shared/hashmap.c
+++ b/src/shared/hashmap.c
@@ -185,7 +185,6 @@ Hashmap *hashmap_new(hash_func_t hash_func, compare_func_t
compare_func) {
bool b;
Hashmap *h;
size_t size;
-void *auxv;
b = is_main_thread();
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
Hi Daniel,
Reindentation is done to fit systemd
---
Makefile.am | 23 +
src/libsystemd-asyncns/asyncns.c | 1513 +
src/libsystemd-asyncns/asyncns.h | 163
src/libsystemd-asyncns/test-asyncns.c | 178
4 files changed, 1877 insertions(+)
create mode 100644 src/libsystemd-asyncns/asyncns.c
create mode 100644 src/libsystemd-asyncns/asyncns.h
create mode 100644 src/libsystemd-asyncns/test-asyncns.c
diff --git a/Makefile.am b/Makefile.am
index 19da6ea..a0564b5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -659,6 +659,29 @@ tests += test-rtnl
#
--
noinst_LTLIBRARIES += \
+ libsystemd-asyncns.la
+
+libsystemd_asyncns_la_SOURCES = \
+ src/libsystemd-asyncns/asyncns.c \
+ src/libsystemd-asyncns/asyncns.h
+
+libsystemd_asyncns_la_CFLAGS = \
+ -pthread
+
+test_asyncns_SOURCES = \
+ src/libsystemd-asyncns/test-asyncns.c
+
+test_asyncns_LDADD = \
+ libsystemd-asyncns.la
+
+test_asyncns_LDFLAGS = \
+ -lresolv \
+ -pthread
+
+tests += test-asyncns
+
+#
--
+noinst_LTLIBRARIES += \
libsystemd-shared.la
libsystemd_shared_la_SOURCES = \
diff --git a/src/libsystemd-asyncns/asyncns.c
b/src/libsystemd-asyncns/asyncns.c
new file mode 100644
index 000..f1c2602
--- /dev/null
+++ b/src/libsystemd-asyncns/asyncns.c
@@ -0,0 +1,1513 @@
+/***
+ This file is part of libasyncns.
+
+ Copyright 2005-2008 Lennart Poettering
+
+ libasyncns is free software; you can redistribute it and/or modify
+ it under the terms of the GNU Lesser General Public License as
+ published by the Free Software Foundation, either version 2.1 of the
+ License, or (at your option) any later version.
+
+ libasyncns is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with libasyncns. If not, see
+ http://www.gnu.org/licenses/.
+ ***/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+/* #undef HAVE_PTHREAD */
+
+#include assert.h
+#include fcntl.h
+#include signal.h
+#include unistd.h
+#include sys/select.h
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include errno.h
+#include sys/wait.h
+#include sys/types.h
+#include pwd.h
+#include netinet/in.h
+#include arpa/nameser.h
+#include resolv.h
+#include dirent.h
+#include sys/time.h
+#include sys/resource.h
+#include stdint.h
+
+#ifdef HAVE_SYS_PRCTL_H
+#include sys/prctl.h
+#endif
+
+#if HAVE_PTHREAD
+#include pthread.h
+#endif
+
+#include asyncns.h
+
+#ifndef MSG_NOSIGNAL
+#define MSG_NOSIGNAL 0
+#endif
+
+#define MAX_WORKERS 16
+#define MAX_QUERIES 256
+#define BUFSIZE (10240)
+
+typedef enum {
+REQUEST_ADDRINFO,
+RESPONSE_ADDRINFO,
+REQUEST_NAMEINFO,
+RESPONSE_NAMEINFO,
+REQUEST_RES_QUERY,
+REQUEST_RES_SEARCH,
+RESPONSE_RES,
+REQUEST_TERMINATE,
+RESPONSE_DIED
+} query_type_t;
+
+enum {
+REQUEST_RECV_FD = 0,
+REQUEST_SEND_FD = 1,
+RESPONSE_RECV_FD = 2,
+RESPONSE_SEND_FD = 3,
+MESSAGE_FD_MAX = 4
+};
+
+struct asyncns {
+int fds[MESSAGE_FD_MAX];
+
+#ifndef HAVE_PTHREAD
+pid_t workers[MAX_WORKERS];
+#else
+pthread_t workers[MAX_WORKERS];
+#endif
+unsigned valid_workers;
why do we have to spawn threads or do forks for DNS. This looks all pretty
expensive. In ConnMan for example we just wrote our own async DNS using a
mainloop. Works perfectly fine and is dirt cheap.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
Hi Greg, This patch set implements a DHCPv4 client library named libsystemd-dhcp to be used with systemd-network. Nice stuff. Where did this code come from, conman? If so, for some reason I thought that it would be easier to make a library of the existing conman dhcp code and have both projects use it instead of forking and having two copies? that is the long term plan. Once ConnMan is switching over to use libsystemd-bus and kdbus, we are switching over to using the systemd event loop instead of GLib main loop and then it will also start using libsystemd-dhcp. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd questions
Hi Bill, Without criticizing any of the existing solutions, some of the things that motivated my interest in this is that I think we need: something easily configured via plain configuration files by a sysadmin, something that would take a limited amount of space (including its dependencies) so it could be reasonably used in an initrd, something which would be fast/efficient, so not e.g. calling out to external tools/daemons for stuff like dhcp/ipv4ll. On this specific point... are you *sure* you want to be rewriting a dhcp/dhcpv6 client? yes, we want to do exactly that. (I ask, because we've gone through at least three over history here, and dealing with the assorted corner cases between vendors and configuration bits required would seem to make it one area not worth trying to reinvent.) I wonder who this magical we is in this statement ;) Speaking from ConnMan history, we actually went through the whole process of fork+exec of dhclient/udhcpc/autoipd for a period of time. But really early on, it was clear that this is not acceptable. Just spawning external processes and hoping for the best is not an approach that is sustainable. The state machine is way more complex and they are interdependencies between them. For example just the simple case of DHCPv4 and IPv4-LL is something you need to run through a single state machine to get this working as it is suppose to be. Inside ConnMan we actually got this right since they guys running the Nao robots are using this heavily. Or have a look at DHCPv6 and prefix delegation. Having to spawn 3 instances of dhclient to get your local network configured is just crazy. None of these clients are synchronized with each other. Also just the simple fact of setting up 6to4 as fallback are these tiny details you want to account for. Since a little over 2 years, ConnMan is running its own DHCP client and server. It runs in commercial devices like the Nest and other devices. It is significant more stable, more feature complete and faster. I presented our numbers at LinuxCon Vancouver a few years back. Look it up if you are interested. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
Hi Colin, that is the long term plan. Once ConnMan is switching over to use libsystemd-bus and kdbus, we are switching over to using the systemd event loop instead of GLib main loop But I think the long term architecturally correct place for the core system main loop is glibc, not systemd. For example, that would allow runtimes like OpenJDK and Python to unconditionally depend on it (if present). As systemd's event loop becomes public API, it has the potential to create interoperability problems for GNOME - think applications like https://git.gnome.org/browse/gnome-logs that want to both monitor the systemd journal and talk to GTK+. At the moment it's OK because sd_journal has APIs sufficient to plug in external loops. Adding a mainloop API to glibc would be a lot of work - it might even entail trying to get it by POSIX. At least it'd entail describing the interaction with the other POSIX APIs. But I think that'd be worth the effort. I am a bit lost on your concerns here. Our focus for ConnMan is libsystemd-bus and kdbus support. Over time we will be removing our dependency on GLib completely. So the systemd event loop will become our only event loop. And as a system daemon, I only care about writing to the Journal. No idea why I would need a event loop for that. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/28] dhcp: Add DHCP protocol structures and initial defines
Hi Lennart, +#define BOOTREQUEST 1 +#define BOOTREPLY 2 + +#define DHCP_DISCOVER 1 +#define DHCP_OFFER 2 +#define DHCP_REQUEST3 +#define DHCP_DECLINE4 +#define DHCP_ACK5 +#define DHCP_NAK6 +#define DHCP_RELEASE7 + +#define DHCP_OVERLOAD_FILE 1 +#define DHCP_OVERLOAD_SNAME 2 + +#define DHCP_OPTION_PAD 0 +#define DHCP_OPTION_SUBNET_MASK 1 +#define DHCP_OPTION_ROUTER 3 +#define DHCP_OPTION_DOMAIN_NAME_SERVER 6 +#define DHCP_OPTION_HOST_NAME 12 +#define DHCP_OPTION_DOMAIN_NAME 15 +#define DHCP_OPTION_NTP_SERVER 42 +#define DHCP_OPTION_REQUESTED_IP_ADDRESS50 +#define DHCP_OPTION_OVERLOAD52 +#define DHCP_OPTION_MESSAGE_TYPE53 +#define DHCP_OPTION_PARAMETER_REQUEST_LIST 55 +#define DHCP_OPTION_END 255 For defines like these I'd really suggest using anonymous enums. It's a good thing if the compiler knows these things, not just the pre-processor... these are wire protocol definitions. What benefit do you gain if the compiler knows them. You always have to handle invalid cases anyway since malicious servers are a reality. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/28] dhcp: Add DHCP protocol structures and initial defines
Hi Zbyszek, +#define BOOTREQUEST 1 +#define BOOTREPLY 2 + +#define DHCP_DISCOVER 1 +#define DHCP_OFFER 2 +#define DHCP_REQUEST3 +#define DHCP_DECLINE4 +#define DHCP_ACK5 +#define DHCP_NAK6 +#define DHCP_RELEASE7 + +#define DHCP_OVERLOAD_FILE 1 +#define DHCP_OVERLOAD_SNAME 2 + +#define DHCP_OPTION_PAD 0 +#define DHCP_OPTION_SUBNET_MASK 1 +#define DHCP_OPTION_ROUTER 3 +#define DHCP_OPTION_DOMAIN_NAME_SERVER 6 +#define DHCP_OPTION_HOST_NAME 12 +#define DHCP_OPTION_DOMAIN_NAME 15 +#define DHCP_OPTION_NTP_SERVER 42 +#define DHCP_OPTION_REQUESTED_IP_ADDRESS50 +#define DHCP_OPTION_OVERLOAD52 +#define DHCP_OPTION_MESSAGE_TYPE53 +#define DHCP_OPTION_PARAMETER_REQUEST_LIST 55 +#define DHCP_OPTION_END 255 For defines like these I'd really suggest using anonymous enums. It's a good thing if the compiler knows these things, not just the pre-processor... these are wire protocol definitions. What benefit do you gain if the compiler knows them. You always have to handle invalid cases anyway since malicious servers are a reality. For example, it's nicer to work with gdb if it can resolve them... You'll also get an error if you use an enum value of one kind in a call requiring an enum of different type. as I said, these are wire protocol definitions. They come in as bits and bytes and not as enums. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/28] dhcp: Add DHCP protocol structures and initial defines
Hi Lennart, +#define BOOTREQUEST 1 +#define BOOTREPLY 2 + +#define DHCP_DISCOVER 1 +#define DHCP_OFFER 2 +#define DHCP_REQUEST3 +#define DHCP_DECLINE4 +#define DHCP_ACK5 +#define DHCP_NAK6 +#define DHCP_RELEASE7 + +#define DHCP_OVERLOAD_FILE 1 +#define DHCP_OVERLOAD_SNAME 2 + +#define DHCP_OPTION_PAD 0 +#define DHCP_OPTION_SUBNET_MASK 1 +#define DHCP_OPTION_ROUTER 3 +#define DHCP_OPTION_DOMAIN_NAME_SERVER 6 +#define DHCP_OPTION_HOST_NAME 12 +#define DHCP_OPTION_DOMAIN_NAME 15 +#define DHCP_OPTION_NTP_SERVER 42 +#define DHCP_OPTION_REQUESTED_IP_ADDRESS50 +#define DHCP_OPTION_OVERLOAD52 +#define DHCP_OPTION_MESSAGE_TYPE53 +#define DHCP_OPTION_PARAMETER_REQUEST_LIST 55 +#define DHCP_OPTION_END 255 For defines like these I'd really suggest using anonymous enums. It's a good thing if the compiler knows these things, not just the pre-processor... these are wire protocol definitions. What benefit do you gain if the compiler knows them. You always have to handle invalid cases anyway since malicious servers are a reality. For example, it's nicer to work with gdb if it can resolve them... You'll also get an error if you use an enum value of one kind in a call requiring an enum of different type. as I said, these are wire protocol definitions. They come in as bits and bytes and not as enums. I was suggesting an *anonymous* enum. That doesn't introduce a type or anything, it just maps name to integers (of any size). That's all. And it does so on the compiler level, rather than in the pre-processor. This is useful because gdb knows about the thing then. fair enough on the gdb level. It is only helping you if the enum value is actually used. So for example in assignments and if-clauses or similar. It does not help you values from the wire that you do not process. I never really cared about gdb here. Either we have builtin debug/trace printing in our protocol code or we use external tools like tcpdump etc. From BlueZ, oFono and ConnMan past experience, the builtin debug/trace printing has been the most useful tool when we had to debug something that is a wire protocol. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
Hi Auke, This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured, mostly as a proof of concept. I expect to expand on this as soon as we are agreed on the basic design. Comments, testing and contributions greatly appreciated! alright, I'll comment, but it took me 5 minutes to clear the coffee off my monitor... Looking at the feature list, why are you not contributing to connman instead? It seems you're going to be duplicating a ton of code And connman does what your goal is, meaning you can pre-provision static configurations without any of the more involved dependencies. It has a DBus interface for status, configuration etc I'm frankly shocked a bit, not sure what to say. Maybe this is a great thing, but, without a doubt someone will want to convert this code long term into connman / NM, and at that point we have 3 standards, not 2. Best to try and stick to 2 standards and fix the one that has the best long-term prospective value. I have a little bit different viewpoint here. I do not look at what are the low-level technical tasks or the implementation, I look at the users. We have two types of users for networking. The first type is sysadmins and the second type is end users. These two groups are as different as it gets in their use cases and how they expect things to be done. When I look at sysadmins, then you target servers, datacenters, could and containers. So headless systems that are not mobile. They are mainly Ethernet based and configure once and not worry about anymore. As an extra added benefit some of these have to configure everything as early as the initramfs. And they want simple configuration files and command line tools. Looking at end users, I see desktop, laptops, phones and all these embedded devices like thermostats, fridges and whatever you can think of. Things where networking can mean also WiFi, cellular even sensor networks like Bluetooth 6loWPAN. It is a dynamic world and needs configuration that is targeted for non-technical people. And end users need a nice UI for their needs. It is also not one UI, there will be many and so APIs need to be simple and designed for that user base in mind. You normally do not take your 12-core Xeon server to the coffee shop around the corner and want to use its public WiFi with a hotspot login. If you do, please take a picture ;) Trying to smash these together seems rather crazy to me. I looks simple in the beginning, but the devil is in the details. There is a reason why ConnMan stayed out of the datacenter world. So the way I see it is that networkd should own the initramfs and sysadmin side of things. And ConnMan will handle the end user side. What this means is that both work in harmony together. Think of it like this, the system boots with networkd in initramfs and then you either start networkd for taking over the initramfs configuration and running in datacenter mode. Or you start ConnMan for running in desktop mode. It is a little bit over-simplified, but I think you get the basic idea. So networkd and ConnMan for example will share a lot of code. And what we will be doing is to contribute the shared pieces into networkd. One prime example is DHCP of course. And the rest we will figure out as networkd progresses. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
Hi Lennart,
+struct Link {
+uint64_t ifindex;
Hmm is this really an uint64_t? if_nametoindex(3) suggestes it's an
unsigned?
actually using if_nametoindex() is bad idea as well. That should be turned into
an async RTNL call as well. We better just cache the ifname to ifindex mapping
internally and then just do a lookup.
The problem with RTNL is that there are some global locks in there. So if you
are really unlucky, then either glibc uses and ioctl that blocks and it uses
internally netlink synchronously. If you serialize all RTNL netlink
communication via asynchronous calls, then you never have to worry about that
lock affecting you.
And for the ifindex type, the one that is communicated over RTNL netlink is the
one that counts. Everything else is just some ancient leftover. And I bet you
find tons of differences everywhere. I personally have not found a single truth.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: gpt-auto-generator depends on HAVE_BLKID
--- Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index fd38e82..5654ad3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1708,6 +1708,7 @@ bin_PROGRAMS += \ bootctl endif +if HAVE_BLKID # -- systemgenerator_PROGRAMS += \ systemd-gpt-auto-generator @@ -1725,6 +1726,7 @@ systemd_gpt_auto_generator_LDADD = \ systemd_gpt_auto_generator_CFLAGS = \ $(AM_CFLAGS) \ $(BLKID_CFLAGS) +endif # -- systemd_rc_local_generator_SOURCES = \ -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: Add database for Bluetooth company identifiers
--- Makefile.am | 1 + hwdb/20-bluetooth-vendor-product.hwdb | 541 ++ 2 files changed, 542 insertions(+) create mode 100644 hwdb/20-bluetooth-vendor-product.hwdb diff --git a/Makefile.am b/Makefile.am index 477b3a6..94ae549 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1905,6 +1905,7 @@ dist_udevhwdb_DATA = \ hwdb/20-pci-classes.hwdb \ hwdb/20-usb-vendor-product.hwdb \ hwdb/20-usb-classes.hwdb \ + hwdb/20-bluetooth-vendor-product.hwdb \ hwdb/20-acpi-vendor.hwdb \ hwdb/20-OUI.hwdb diff --git a/hwdb/20-bluetooth-vendor-product.hwdb b/hwdb/20-bluetooth-vendor-product.hwdb new file mode 100644 index 000..c8cb322 --- /dev/null +++ b/hwdb/20-bluetooth-vendor-product.hwdb @@ -0,0 +1,541 @@ +# This file is part of systemd. +# +# Data imported from: +# http://www.bluetooth.org/Technical/AssignedNumbers/identifiers.htm + +bluetooth:v* + ID_VENDOR_FROM_DATABASE=Ericsson Technology Licensing + +bluetooth:v0001* + ID_VENDOR_FROM_DATABASE=Nokia Mobile Phones + +bluetooth:v0002* + ID_VENDOR_FROM_DATABASE=Intel Corp. + +bluetooth:v0003* + ID_VENDOR_FROM_DATABASE=IBM Corp. + +bluetooth:v0004* + ID_VENDOR_FROM_DATABASE=Toshiba Corp. + +bluetooth:v0005* + ID_VENDOR_FROM_DATABASE=3Com + +bluetooth:v0006* + ID_VENDOR_FROM_DATABASE=Microsoft + +bluetooth:v0007* + ID_VENDOR_FROM_DATABASE=Lucent + +bluetooth:v0008* + ID_VENDOR_FROM_DATABASE=Motorola + +bluetooth:v0009* + ID_VENDOR_FROM_DATABASE=Infineon Technologies AG + +bluetooth:v000A* + ID_VENDOR_FROM_DATABASE=Cambridge Silicon Radio + +bluetooth:v000B* + ID_VENDOR_FROM_DATABASE=Silicon Wave + +bluetooth:v000C* + ID_VENDOR_FROM_DATABASE=Digianswer A/S + +bluetooth:v000D* + ID_VENDOR_FROM_DATABASE=Texas Instruments Inc. + +bluetooth:v000E* + ID_VENDOR_FROM_DATABASE=Ceva, Inc. (formerly Parthus Technologies Inc.) + +bluetooth:v000F* + ID_VENDOR_FROM_DATABASE=Broadcom Corporation + +bluetooth:v0010* + ID_VENDOR_FROM_DATABASE=Mitel Semiconductor + +bluetooth:v0011* + ID_VENDOR_FROM_DATABASE=Widcomm, Inc. + +bluetooth:v0012* + ID_VENDOR_FROM_DATABASE=Zeevo, Inc. + +bluetooth:v0013* + ID_VENDOR_FROM_DATABASE=Atmel Corporation + +bluetooth:v0014* + ID_VENDOR_FROM_DATABASE=Mitsubishi Electric Corporation + +bluetooth:v0015* + ID_VENDOR_FROM_DATABASE=RTX Telecom A/S + +bluetooth:v0016* + ID_VENDOR_FROM_DATABASE=KC Technology Inc. + +bluetooth:v0017* + ID_VENDOR_FROM_DATABASE=Newlogic + +bluetooth:v0018* + ID_VENDOR_FROM_DATABASE=Transilica, Inc. + +bluetooth:v0019* + ID_VENDOR_FROM_DATABASE=Rohde Schwartz GmbH Co. KG + +bluetooth:v001A* + ID_VENDOR_FROM_DATABASE=TTPCom Limited + +bluetooth:v001B* + ID_VENDOR_FROM_DATABASE=Signia Technologies, Inc. + +bluetooth:v001C* + ID_VENDOR_FROM_DATABASE=Conexant Systems Inc. + +bluetooth:v001D* + ID_VENDOR_FROM_DATABASE=Qualcomm + +bluetooth:v001E* + ID_VENDOR_FROM_DATABASE=Inventel + +bluetooth:v001F* + ID_VENDOR_FROM_DATABASE=AVM Berlin + +bluetooth:v0020* + ID_VENDOR_FROM_DATABASE=BandSpeed, Inc. + +bluetooth:v0021* + ID_VENDOR_FROM_DATABASE=Mansella Ltd + +bluetooth:v0022* + ID_VENDOR_FROM_DATABASE=NEC Corporation + +bluetooth:v0023* + ID_VENDOR_FROM_DATABASE=WavePlus Technology Co., Ltd. + +bluetooth:v0024* + ID_VENDOR_FROM_DATABASE=Alcatel + +bluetooth:v0025* + ID_VENDOR_FROM_DATABASE=Philips Semiconductors + +bluetooth:v0026* + ID_VENDOR_FROM_DATABASE=C Technologies + +bluetooth:v0027* + ID_VENDOR_FROM_DATABASE=Open Interface + +bluetooth:v0028* + ID_VENDOR_FROM_DATABASE=R F Micro Devices + +bluetooth:v0029* + ID_VENDOR_FROM_DATABASE=Hitachi Ltd + +bluetooth:v002A* + ID_VENDOR_FROM_DATABASE=Symbol Technologies, Inc. + +bluetooth:v002B* + ID_VENDOR_FROM_DATABASE=Tenovis + +bluetooth:v002C* + ID_VENDOR_FROM_DATABASE=Macronix International Co. Ltd. + +bluetooth:v002D* + ID_VENDOR_FROM_DATABASE=GCT Semiconductor + +bluetooth:v002E* + ID_VENDOR_FROM_DATABASE=Norwood Systems + +bluetooth:v002F* + ID_VENDOR_FROM_DATABASE=MewTel Technology Inc. + +bluetooth:v0030* + ID_VENDOR_FROM_DATABASE=ST Microelectronics + +bluetooth:v0031* + ID_VENDOR_FROM_DATABASE=Synopsys + +bluetooth:v0032* + ID_VENDOR_FROM_DATABASE=Red-M (Communications) Ltd + +bluetooth:v0033* + ID_VENDOR_FROM_DATABASE=Commil Ltd + +bluetooth:v0034* + ID_VENDOR_FROM_DATABASE=Computer Access Technology Corporation (CATC) + +bluetooth:v0035* + ID_VENDOR_FROM_DATABASE=Eclipse (HQ Espana) S.L. + +bluetooth:v0036* + ID_VENDOR_FROM_DATABASE=Renesas Technology Corp. + +bluetooth:v0037* + ID_VENDOR_FROM_DATABASE=Mobilian Corporation + +bluetooth:v0038* + ID_VENDOR_FROM_DATABASE=Terax + +bluetooth:v0039* + ID_VENDOR_FROM_DATABASE=Integrated System Solution Corp. + +bluetooth:v003A* + ID_VENDOR_FROM_DATABASE=Matsushita Electric Industrial Co., Ltd. + +bluetooth:v003B* + ID_VENDOR_FROM_DATABASE=Gennum Corporation + +bluetooth:v003C* + ID_VENDOR_FROM_DATABASE=Research In Motion + +bluetooth:v003D* + ID_VENDOR_FROM_DATABASE=IPextreme, Inc. + +bluetooth:v003E* +
Re: [systemd-devel] [PATCH] hwdb: Add database for Bluetooth company identifiers
Hi Tom, diff --git a/hwdb/20-bluetooth-vendor-product.hwdb b/hwdb/20-bluetooth-vendor-product.hwdb new file mode 100644 index 000..c8cb322 --- /dev/null +++ b/hwdb/20-bluetooth-vendor-product.hwdb @@ -0,0 +1,541 @@ +# This file is part of systemd. +# +# Data imported from: +# http://www.bluetooth.org/Technical/AssignedNumbers/identifiers.htm + +bluetooth:v* + ID_VENDOR_FROM_DATABASE=Ericsson Technology Licensing [...] How did you generate this? Might it make sense to patch ids-update.pl to generate the new .hwdb file so we make sure it stays up-to-date? it is actual manual labor. We have the database inside BlueZ which is manually updated. I added tools/hwdb utility to BlueZ that allows us to create the database from the BlueZ included data. The Bluetooth company identifiers update rather infrequently so that there was no need to automate anything. At least not so far. I update them as part of the BlueZ release process. I have started to also add product identifiers now. First one is the Nike+ FuelBand where they actually use Bluetooth vendor and product ids. There is no central database around these. I am tracking them inside BlueZ at the moment. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networking services management idea
Hi Chris, Unless the services take long to start, you'll have a much better time with socket activation. With socket activation, the service won't just wait until network availability to come online; the service will wait until an actual request to come online. Also check out my other posts to the mailing list about network availability levels and service management. Thanks David, I just read you posts in the thread network consuming user services where some of this was touched on. I see the points on the services being socket activated or listing to netlink and so-forth. But in my case, there are outgoing services, so protocol specific, that one just might not want even started unless a specific state is obtained. Agreed that network session level activity should be monitored and managed within the service, but before that when to really start the service. I am not talking about stalling or interfering with network.target, but I suggest is setting up targets that outgoing services could use or distro/admins could use to better structure in a generic scene. For instance. There is a service that uses NFC to used in credit card services. lets call it NFC-your-money.service This service needs an an active NFC connection, and is the service used to pay for things using you phone from you checking account. (No I don't have or use this.) 1. I don't want such a service running if I don't have a NFC connection. 2. I don't want it running if I loose my NFC connection. 3. I don't want to start the service to check if I have a NFC connection . this makes no sense. It is not how NFC actually works. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [PATCH] Allow compile without IPv6.
Hi Gustavo, I think new projects from 2010 should not have ipv4-only. This time should be over, finally. And people should get used to see ipv6 everywhere, and we should try to break the chicken-egg thing wherever possible. :) I can see the use for a systemd without any IP networking, but compiling-out ipv6 seems like the wrong thing to me. Sure, we should make sure, that systemd handles a kernel without ipv6 gracefully, but not offer a switch to stay in the IP stone age. :) That means I'll have to maintain this patch outside tree forever? :-) btw, if you allow my patch to get in, in consideration I will kindly create a new patch that flags if ipv6 support is present and if not fallback to my ipv4 code... but that also means we need review of my provided ipv4 code ;-) this is the wrong approach. I agree with Kay here in that systemd needs to handle gracefully a kernel where IPv6 is disabled, but that should be all that it is doing. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [PATCH] Allow compile without IPv6.
Hi Gustavo, I think new projects from 2010 should not have ipv4-only. This time should be over, finally. And people should get used to see ipv6 everywhere, and we should try to break the chicken-egg thing wherever possible. :) I can see the use for a systemd without any IP networking, but compiling-out ipv6 seems like the wrong thing to me. Sure, we should make sure, that systemd handles a kernel without ipv6 gracefully, but not offer a switch to stay in the IP stone age. :) That means I'll have to maintain this patch outside tree forever? :-) btw, if you allow my patch to get in, in consideration I will kindly create a new patch that flags if ipv6 support is present and if not fallback to my ipv4 code... but that also means we need review of my provided ipv4 code ;-) this is the wrong approach. I agree with Kay here in that systemd needs to handle gracefully a kernel where IPv6 is disabled, but that should be all that it is doing. Damn! and I was thinking about providing a connman build without ipv6... :-D BTW, could you provide some connman.service in your next release? if you have done so already, please send a patch. We can clearly include these. I still have the BlueZ patches from Lennart on my todo list. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
