Systemd Is Working Towards Its Own Super Fast DHCP Server, Client

[GreatEmerald]

Well, this sounds like quite an important implementation detail to me. Could you clear up the design a bit please? In particular: What happens if the non-forked-off library hits a nullptr-deref... will it kill PID 1? How much of your system do you need to update to do a bugfix in the library? As what user is networkd (and NetworkManager, for that matter) ran, and what are the consequences of "popping a shell" by exploiting a bug in it?

I haven't tested the whole networkd thing yet, but I'm pretty sure the answers to your questions will be "no, why would you ever think it would", "the library, obviously", "root" (at least it is for NetworkManager; it does have to manage network devices, after all. Also same for dhclient. Maybe not all networkd runs as root though?) and "same as with dhcpd".

[tomegun]

Well, this sounds like quite an important implementation detail to me. Could you clear up the design a bit please? In particular: What happens if the non-forked-off library hits a nullptr-deref... will it kill PID 1? How much of your system do you need to update to do a bugfix in the library? As what user is networkd (and NetworkManager, for that matter) ran, and what are the consequences of "popping a shell" by exploiting a bug in it?

In both cases, PID1 forks off the main daemon. NetworkManager will then fork again off a DHCP client daemon, whereas networkd will not. Neither will be able to take down PID1. A nullptr-deref in sd-dhcp-client will crash systemd-networkd, which will then be restarted automatically by PID1, and as we are mostly state-less that will 'just work'. Obviously a nullptr-deref is a bad situation to be in, so we shouldn't do that...

Currently the library only has one user, which is networkd itself, and it is in fact not shipped as a stand-alone library yet, but just compiled-in to networkd. So as things are now, if there is a bug in the library, networkd will have to be updated.

NetworkManager is run as root (as is most system daemons for that matter). networkd is also run as root, but with quite restricted capabilities. Exploiting a bug in a system-daemon is generally a bad thing, and this is no different with networkd. We are trying to limit the potential damage by dropping capabilities, but it still would be pretty bad... (nothing specific to networkd though).

[justmy2cents]

I understand the confusion, a bit of context is required to make sense of this You almost certainly already have a DHCP client as part of your boot process. It is probably being forked off as a separate daemon from whatever configures your network (maybe NetworkManager?). networkd is a network management daemon shipped with systemd, which can manage some types of basic networks. Including configuring DHCP. We don't fork off a daemon though, we do this via a library inside the networkd process itself (but that's an implementation detail). So from a users point of view configuring DHCP via networkd or networkmanager is not so different. They are both separate daemons started by PID1 at boot.

As to the server, there are cases where a network managment daemon may need to hand out dhcp leases. I'm not thinking of big DHCP servers like in your router or at your ISP, use special-purpose DHCP servers for that. If you have a peer-to-peer connection one side may want to hand out a dhcp lease to the other (wifi direct does this for instance), or if you do network sharing, you may want to connect your phone to the internet over 3G, set up a hotpot and hand out DHCP leases on that. The user-case I have in mind though, is to hand out DHCP leases to containers as they are started on your machine.

thanks, client was always understandable to me. it just makes sense at 1st glance. and sorry, i'm really not trying to troll, i'm just hoping someone would explain logic behind it.

as for server, i'm still struggling to understand what difference it is from starting dhcpd as 1st service you start after networkd. simply, because your machine that would start it, should never depend on it anyway. but, as far as any other scenario goes i fail to see it. containers could simply depend on dhcpd and systemd by default takes care that they don't start until all is prepared. why otherwise making dependency tree if you plan to hardcode it in the 1st place by stucking everything in your project.

[newwen]

I don't know such times how can be possible without violating any stardard. I thought clients have to send some ARP probes during a few seconds when they get a lease to avoid possible IP collisions.

[Ericg]

I don't know such times how can be possible without violating any stardard. I thought clients have to send some ARP probes during a few seconds when they get a lease to avoid possible IP collisions.

Times are probably so low since its local-machine connectivity (Container is on same machine as the dhcp server). Someone in the Google+ thread said that in basic testing trying it on their ACTUAL network they were still able to get a lease from their wireless router in less than 50msecs, with most of the time being the double-roundtrip you have to do. Which is still amazing.

[renkin]

I don't know such times how can be possible without violating any stardard. I thought clients have to send some ARP probes during a few seconds when they get a lease to avoid possible IP collisions.

On Google+, they're saying that all they did was bug fixing and taking care of bottlenecks, claiming that they're not doing anything revolutionary or novel.

[DeeK]

I don't know such times how can be possible without violating any stardard. I thought clients have to send some ARP probes during a few seconds when they get a lease to avoid possible IP collisions.

I get IP collisions using the ISC dhcp client. Colliding, of course, with idiots in the office that statically assign an IP in the dhcp range. It happens very occasionally, but still happens.

Nobody using Windows has such an issue, so I assume that their dhcp client does exactly what you mention.

RFC2131 states that the server _should_ check for IP conflicts. So, looks like this responsibility belongs to the server, not the client. Though it appears that Windows has it the other way around.

[DeepDayze]

But this does raise a question, is this DHCPclient going to be ported over to networkmanager?

Sounds like NM and other networking clients (wicd, wpasupplicant, ifupdown, etc) can benefit from this work as well. The one other bottleneck is the network card and associated driver, where latencies or slowness can affect the reconnection time when resuming from sleep. This should also be considered as well.

[newwen]

I get IP collisions using the ISC dhcp client. Colliding, of course, with idiots in the office that statically assign an IP in the dhcp range. It happens very occasionally, but still happens.

Nobody using Windows has such an issue, so I assume that their dhcp client does exactly what you mention.

RFC2131 states that the server _should_ check for IP conflicts. So, looks like this responsibility belongs to the server, not the client. Though it appears that Windows has it the other way around.

The client SHOULD also check if the address is already allocated and MUST decline the received configuration if it is.
RFC5227 tells how this must be done using ARP probes. According to that it would take 7seconds after the lease is obtained to check that there's no conflict

[tomegun]

I don't know such times how can be possible without violating any stardard. I thought clients have to send some ARP probes during a few seconds when they get a lease to avoid possible IP collisions.

There are three (optional) timeouts we skip: 1) waiting for 1-10 secs between the client starts and we start sending out packet. 2) The server pinging the network to check if there are collisions. 3) The clients sending out ARP probes to check if there are collisions.

There are cases where these features may be needed, so we will probably add them eventually. But in most cases they are not needed, and in the standard they are optional, so we'll almost certainly leave them as opt-in.