On Wednesday, October 22, 2014, Lennart Poettering <lenn...@poettering.net> wrote:
> On Wed, 22.10.14 20:49, Tom Gundersen (t...@jklm.no <javascript:;>) wrote: > > > On Wed, Oct 22, 2014 at 6:23 PM, Lennart Poettering > > <lenn...@poettering.net <javascript:;>> wrote: > > > On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no <javascript:;>) > 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. > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org <javascript:;> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Sent from Gmail Mobile
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
