<div dir="ltr">This is another reason why I previously suggested to expose a directive to allow administrators to enable/disable the broadcast flag. I have seen DHCP servers ignoring the flag and always sending broadcasted DHCPOFFERs. There could be other servers that may only use unicast, and even networks that might disallow broadcast traffic altogether. <div>

<br></div><div>IMHO, a pragmatic solution to this could be: <div><ul><li>Set broadcast flag always ON for Firewire interfaces: <a href="http://tools.ietf.org/html/rfc2855#section-2" style="color:rgb(65,131,196);text-decoration:none;font-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px;background-image:initial;background-repeat:initial">http://tools.ietf.org/html/rfc2855#section-2</a></li>

<li>Set broadcast flag always ON for Infiniband interfaces: <a href="http://tools.ietf.org/html/rfc4390#section-2.2" style="color:rgb(65,131,196);text-decoration:none;font-family:Helvetica,arial,freesans,clean,sans-serif;font-size:14px;line-height:23.799999237060547px;background-image:initial;background-repeat:initial">http://tools.ietf.org/html/rfc4390#section-2.2</a></li>

<li>Set broadcast flag OFF by default, if and only if the interface is not Infiniband or Firewire</li><li>Expose a configuration directive to allow administrators to configure the broadcast flag in case there are DHCP servers ignoring the RFC, or networks disallowing broadcast traffic.<br>

</li></ul><div>Best, </div></div></div><div>Camilo Aguilar</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 12:03 PM, Friedrich Kröner <span dir="ltr"><<a href="mailto:friedrich@mailstation.de" target="_blank">friedrich@mailstation.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Saturday 21 June 2014 15:24:03 Tom Gundersen wrote:<br>
> On Fri, Jun 20, 2014 at 12:12 PM, Michal Sekletar <<a href="mailto:msekleta@redhat.com">msekleta@redhat.com</a>><br>
wrote:<br>
> > On Wed, Jun 18, 2014 at 09:51:02PM +0200, Friedrich Kröner wrote:<br>
> >> Hello,<br>
> >><br>
> >> when trying systemd-networkd with >=214 and the following config:<br>
> >><br>
> >> [Match]<br>
> >> Name=eth*<br>
> >><br>
> >> [Network]<br>
> >> DHCP=yes<br>
> >><br>
> >> Address=2001:db8::1234:5678/64<br>
> >> DNS=8.8.8.8<br>
> >> DNS=2001:db8:1::ab9:C0A8:102<br>
> >><br>
> >><br>
> >> I get lots of DHCP DISCOVER events and it doesn't aquire an IPv4 address,<br>
> >> nor sets the configured IPv6.<br>
> >><br>
> >> Jun 18 18:44:31 localhost systemd[1]: Starting Network Service...<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: timestamp of<br>
> >> '/etc/systemd/network' changed<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20<br>
> >> bytes of incoming message<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            : link<br>
> >> 3<br>
> >> added<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            : udev<br>
> >> initialized link<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            :<br>
> >> flags<br>
> >> change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            :<br>
> >> gained<br>
> >> carrier<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: could not add new link<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              : link<br>
> >> 1<br>
> >> added<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              : udev<br>
> >> initialized link<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              :<br>
> >> flags<br>
> >> change: +LOOPBACK +UP +LOWER_UP +RUNNING<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              :<br>
> >> gained<br>
> >> carrier<br>
> >> Jun 18 18:44:31 localhost systemd[1]: Started Network Service.<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            : link<br>
> >> state is up-to-date<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            :<br>
> >> found<br>
> >> matching network '/etc/systemd/network/80-dhcp.network'<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            :<br>
> >> acquiring DHCPv4 lease<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> STARTED on ifindex 3 with address 52:54:e4:d2:24:44<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: Sent message<br>
> >> type=method_call sender=n/a destination=org.freedesktop.DBus<br>
> >> object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello<br>
> >> cookie=1 reply_cookie=0 error=n/a<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              :<br>
> >> getting address failed: Device or resource busy<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              : link<br>
> >> state is up-to-date<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              :<br>
> >> unmanaged Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl:<br>
> >> discarding 20 bytes of incoming message<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            :<br>
> >> added<br>
> >> address: fe80::5054:e4ff:fed2:2444/64<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: rtnl: received address<br>
> >> for a nonexistent link, ignoring<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              :<br>
> >> added<br>
> >> address: ::1/128<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0            :<br>
> >> added<br>
> >> address: <a href="http://123.23.23.21/22" target="_blank">123.23.23.21/22</a><br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: lo              :<br>
> >> added<br>
> >> address: <a href="http://127.0.0.1/8" target="_blank">127.0.0.1/8</a><br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message<br>
> >> type=method_return sender=org.freedesktop.DBus destination=:1.45<br>
> >> object=n/a<br>
> >> interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a<br>
> >> Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message<br>
> >> type=signal<br>
> >> sender=org.freedesktop.DBus destination=:1.45<br>
> >> object=/org/freedesktop/DBus<br>
> >> interface=org.freedesktop.DBus member=NameAcquired cookie=2<br>
> >> reply_cookie=0<br>
> >> error=n/a<br>
> >> Jun 18 18:44:33 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:44:34 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:44:38 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:44:46 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:45:02 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:45:33 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:46:36 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:47:41 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >> Jun 18 18:48:44 localhost systemd-networkd[19468]: DHCP CLIENT<br>
> >> (0x3ddf8f7):<br>
> >> DISCOVER<br>
> >><br>
> >> reverting commit 63a070415db09f5b5bcc5c sd-dhcp-client: allways request<br>
> >> broadcast<br>
> >> restores the previous behavior. Upon restart of systemd-networkd I get<br>
> >> the<br>
> >> usual OFFER, REQUEST, ACK confirmation and the IPv6 gets set as well.<br>
> >><br>
> >> This is on a kvm-machine with virtio_net as module.<br>
> >><br>
> >> Please let me know if you want me to test anything or need further<br>
> >> information.<br>
> ><br>
> > What DHCP server do you use? I was running networkd with<br>
> > 63a070415db09f5b5bcc5c included and was able to obtain offers just fine<br>
> > on qemu-kvm vms using dnsmasq as DHCP server.<br>
><br>
> Thanks guys for looking into this. I finally got my containers working<br>
> again today so I could reproduce. There was a bug in sd-dhcp-server so<br>
> that it would never send out broadcast packets (so the change<br>
> defaulting to requesting broadcast in the client obviously broke<br>
> everything). I fixed that now in git, so let me know if there are any<br>
> more problems.<br>
><br>
> Cheers,<br>
><br>
> Tom<br>
</div></div>My problem persists. I don't know which DHCP server is used, running current<br>
git still only gets me DISCOVERS. Reverting the commit in question fixes the<br>
issue.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><b>Camilo Aguilar</b></div><div>Software Engineer</div><div><a href="http://github.com/c4milo" target="_blank">http://github.com/c4milo</a></div>

<br><br></div>
</div></div>