On Mon, Jun 2, 2014 at 2:09 PM, Patrik Flykt <patrik.fl...@linux.intel.com> wrote: > On Fri, 2014-05-30 at 17:21 +0100, Tom Gundersen wrote: >> I'm wondering if the criterion should be to request broadcast if and >> only if we have not configured an IP address (I.e. only in >> discovering, requesting and init-reboot), as that seems to be the >> problem, or did I get that wrong? > > Yes, I was aiming at requesting broadcast delivery from the server only > for broadcast packets sent by the client. That can be an overly simple > solution which waits until T2 until the client reacquires the lease by > using broadcast; the unicast packets between times T1 and T2 are always > lost on these links. Is this something acceptable?
Hm, are you sure packets are lost between T1 and T2? These sholud just be regular UDP packets, should they not? > Then again, if the network is known to operate correctly, it is better > to request and get unicast delivery all the time instead. Should we have > a configuration parameter that requests broadcast delivery by default > and therefore works in all places? The system owner can then turn on > unicast delivery once the network is known to work properly? I'd rather not introduce options to work around bugs, unless there is a really compelling reason... I'd either go with enabling broadcast unconditionally in the cases where it may be necessary, or find a test for deciding whether or not it should be enabled. I now pushed an attempt at a fix. Does it work as expected for everyone? Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
