[systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface

[Tom Gundersen]

On Thu, Oct 23, 2014 at 11:04 AM, Camilo Aguilar
<camilo.aguilar at gmail.com> wrote:
>
>
> On Wednesday, October 22, 2014, Lennart Poettering <lennart at poettering.net>
> wrote:
>>
>> On Wed, 22.10.14 20:49, Tom Gundersen (teg at jklm.no) wrote:
>>
>> > On Wed, Oct 22, 2014 at 6:23 PM, Lennart Poettering
>> > <lennart at poettering.net> wrote:
>> > > On Wed, 22.10.14 18:16, Tom Gundersen (teg at 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