[systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support

[Tom Gundersen]

On Fri, Feb 28, 2014 at 2:39 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 28.02.14 14:34, Tom Gundersen (teg at jklm.no) wrote:
>> On Fri, Feb 28, 2014 at 2:24 PM, Lennart Poettering
>> <lennart at 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