<div dir="ltr">It makes total sense. I can provide that patch in addition if you like, But, can we merge this change for now so we can fix <a href="https://github.com/coreos/bugs/issues/12" target="_blank" style="font-family:arial,sans-serif;font-size:13px">https://github.com/coreos/bugs/issues/12</a> and create a new issue to make it more robust?</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen <span dir="ltr"><<a href="mailto:teg@jklm.no" target="_blank">teg@jklm.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar<br>
<<a href="mailto:camilo.aguilar@gmail.com">camilo.aguilar@gmail.com</a>> wrote:<br>
> In systems running on hypervisors this flag needs to be set ON, so offers can reach<br>
> the virtual machines.<br>
><br>
> For more information please refer to this thread in CoreOS: <a href="https://github.com/coreos/bugs/issues/12" target="_blank">https://github.com/coreos/bugs/issues/12</a><br>
><br>
> Signed-off-by: Camilo Aguilar <<a href="mailto:camilo.aguilar@gmail.com">camilo.aguilar@gmail.com</a>><br>
> ---<br>
>  src/libsystemd-network/sd-dhcp-client.c | 9 +++++++++<br>
>  1 file changed, 9 insertions(+)<br>
><br>
> diff --git a/src/libsystemd-network/sd-dhcp-client.c b/src/libsystemd-network/sd-dhcp-client.c<br>
> index 0300a6b..8f54906 100644<br>
> --- a/src/libsystemd-network/sd-dhcp-client.c<br>
> +++ b/src/libsystemd-network/sd-dhcp-client.c<br>
> @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client *client, DHCPPacket **ret,<br>
>             refuse to issue an DHCP lease if 'secs' is set to zero */<br>
>          packet->dhcp.secs = htobe16(client->secs);<br>
><br>
> +        /* RFC2132 section 4.1<br>
> +           A client that cannot receive unicast IP datagrams until its protocol<br>
> +           software has been configured with an IP address SHOULD set the<br>
> +           BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or<br>
> +           DHCPREQUEST messages that client sends.  The BROADCAST bit will<br>
> +           provide a hint to the DHCP server and BOOTP relay agent to broadcast<br>
> +           any messages to the client on the client's subnet. */<br>
> +        packet->dhcp.flags = htobe16(0x8000);<br>
<br>
</div>Hm, most clients can and should use unicast, so we should definitely<br>
not request broadcast unconditionally. If there really is a situation<br>
where we need broadcast, we should detect that and only request<br>
broadcast in this case.<br>
<br>
Does that make sense?<br>
<br>
Cheers,<br>
<br>
Tom<br>
<div class=""><br>
>          /* RFC2132 section 4.1.1:<br>
>             The client MUST include its hardware address in the ’chaddr’ field, if<br>
>             necessary for delivery of DHCP reply messages.<br>
> --<br>
> 1.8.5.2 (Apple Git-48)<br>
><br>
><br>
</div>> _______________________________________________<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>
><br>
</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>