On Thu, Oct 23, 2014 at 11:04 AM, Camilo Aguilar <camilo.agui...@gmail.com> wrote: > > > On Wednesday, October 22, 2014, Lennart Poettering <lenn...@poettering.net> > wrote: >> >> On Wed, 22.10.14 20:49, Tom Gundersen (t...@jklm.no) wrote: >> >> > On Wed, Oct 22, 2014 at 6:23 PM, Lennart Poettering >> > <lenn...@poettering.net> wrote: >> > > On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no) wrote: >> > > >> > >> Hi guys, >> > >> >> > >> I finally got around to have a look at this. I can reproduce the >> > >> problem, and for me a workaround is to set RequestBroadcast=yes in >> > >> the >> > >> DHCP section in the .network file for your host0 interface in the >> > >> container. Does that work for you too. >> > > >> > > Hmm, maybe the default .network file we ship for this case should >> > > include this setting? Or will it in turn break the non-bridged veth >> > > setups? >> > >> > Yeah, there is no perfect option. Some networks will filter broadcast >> > messages (though that is arguably even more broken than filtering >> > messed up unicast ones). >> >> Hmm? Not following. >> >> I understood that RequestBroadcast=yes is necessary to make dhcp work >> on the Linux kernel bridge. Or is that a misunderstanding? >> >> What I am wondering about specifically is whether >> 80-container-host0.network shall default to RequestBroadcast=yes, or not? >> >> Aso, if there are some networks that require the bit set, and others >> that require it unset, what about trying the other after not getting a >> reply on the first? > > > 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. Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
