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

[Tom Gundersen]

On Sun, Oct 12, 2014 at 12:57 AM, Tom Gundersen <teg at jklm.no> wrote:
> On Fri, Sep 26, 2014 at 4:52 AM, Leonid Isaev <lisaev at umail.iu.edu> wrote:
>> Hi,
>>
>> On Thu, Sep 25, 2014 at 04:56:55PM -0700, James Lott wrote:
>>> Actually, the reason I am using dhcpcd fro mthe command line is as a debugging
>>> measure, because I originally setup a .network file for this interface to
>>> attempt to allow systemd-networkd to handle acquiring the DHCP lease.
>>
>> You could run networkd manually as
>> # SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-networkd
>>
>> but this will also show endless DISCOVER attempts. In my case, I controlled the
>> DHCP server, and according to its logs the lease is actually assigned but the
>> client never receives it. So, I suspect a bug either in kernel or systemd
>> because packets get lost in the bridge (or bond in my case). I suspect the
>> former because restarting networkd didn't help (i.e. the DHCP lease never got
>> received).
>>
>>> Yuck. I'm really not a fan of netctl, and would probably sooner hack together
>>> some oneshot service files that manually setup the interfaces and acquire
>>> leases. So it sounds like systemd-networkd is not quite ready for prime time
>>> when it comes to being a complete interface management solution. I guess
>>> that's what I get for living life on the edge ;)
>>
>> Netctl is better in this situation because it allows ordering of different
>> profiles w.r.t. each other because they are just systemd services (in networkd
>> language this would be ordering of different .net* units if such existed). So
>> you can first set up vlans, then bridge and do the DHCP stuff.
>>
>> There is an additional problem with networkd: you never know how to order
>> against it. Sure there are network* targets (and ideally things _should_ work)
>> but they are useless in this context because they can be reached before
>> (virtual) devices are actually initialized. OTOH, when a netctl script
>> successfully returns, you know that things are properly set up.
>>
>> Hopefully this thread attracts relevant attention because I don't know how to
>> debug this...
>
> Hi Leonid and James,
>
> Thanks for debugging this so far, I'll take a look next week.
>
> Cheers,
>
> Tom

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.

We should probably come up with some better way to handle this, but it
is not clear to me at the moment how this can best be done to work
nicely out of the box.

Cheers,

Tom