On Fri, Feb 28, 2014 at 2:39 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Fri, 28.02.14 14:34, Tom Gundersen (t...@jklm.no) wrote: >> On Fri, Feb 28, 2014 at 2:24 PM, Lennart Poettering >> <lenn...@poettering.net> wrote: >> > >> >> If you stop LL state machine and start again, then you will go through >> >> the probe/announce/defend process anyways. Tell you the truth I didn't >> >> quite understand your question. >> > >> > Well, in embedded environments (unlike on mobile/desktop cases) you >> > probably want to leave the network interface continiously configured as >> > soon as you got an IP address, and not take it down as soon as the link >> > beat vanishes, to provide stability for local apps. >> > >> > However, even in that case, each time the link sensing reports that a >> > cable got connected when it wasn't before we should refresh the DHCP >> > release and check with ARP whether the IPv4LL address is still without >> > conflicts, simply as a safety measure. >> >> I guess we could use CriticalConnection for this? Though currently the >> policy there for DHCP is that we never ever drop the address, so not >> sure how that would work with an IPv4LL conflict. > > Maybe a new WatchLinkBeat= or so? If "yes" this would mean that the > iface is unconfigured as soon as link beat is lost, if "no" this would > mean that the iface is always left configured as soon as it got an > address, but still refreshed if link beat changes comes back.
Yeah, I guess we might need this weaker version of CriticalConnection. >> >> > Hmm, this hash function is probably not that great... We probably >> >> > should just >> >> > use siphash here, we kind try to standardize on that... >> >> >> >> We are going to change the way we generate LL addresses and there is a >> >> TODO item for this too. We are going to have a predictable >> >> sequence. This way, if network crashes after assigning a LL address, >> >> our start off address will be the last one we have assigned. >> > >> > Hmm, what do you mean by "predicatable"? I mean, if there's a conflict, >> > and both sides notice that and decide to pick a new address but do that >> > with the same PRNG sequence they will try the same address next and so >> > on and so on. >> >> My suggestion was to seed the PRNG like we do for the persistent MAC >> addresses. The sequence of attempted IP's will be the same for a given >> NIC on a given machine, but different machines/NICs will have >> different sequences. > > This only works if the PRNG state can be stored per interface. Can we do > this with the glibc one? I guess rand_r() should allow this? -t _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel