On Thu, 23.10.14 07:15, Marcel Holtmann (mar...@holtmann.org) wrote: > 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.
What timeout did you pick? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
