<div dir="ltr">gah, the link for 2 is <a href="https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8">https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8</a> instead</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 4:41 AM, Camilo Aguilar <span dir="ltr"><<a href="mailto:camilo.aguilar@gmail.com" target="_blank">camilo.aguilar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I spent some time studying the standard ISC's implementation. And, unless I'm misreading the code, for Linux the client seems to always set the broadcast bit ON except when SOCKET_CAN_RECEIVE_UNICAST_UNCONFIGURED is defined in compilation time, which I don't see anybody doing. For the rest of the ports they always sets it OFF.<div>
<br></div><div>Fedora has a modified version of <a href="https://github.com/greearb/dhcp-ct" target="_blank">ISC</a> where in addition to the define, they also <a href="https://github.com/greearb/dhcp-ct/blob/master/dhcp-4.2.0/client/dhclient.c#L2768" target="_blank">expose</a> setting the broadcast flag through the client's configuration file.</div>
<div><br></div><div>The best implementation I found is dhcpcd, used by Gentoo. If I understood well the code, dhcpcd does not send ever the broadcast flag unless two things happen: </div><div><br></div><div>1. The administrador runs the client with the --broadcast flag: <a href="https://github.com/bldewolf/dhcpcd/commit/5aec6bbd13b0de0c8cc8111d82f827ef7d3eed35" target="_blank">https://github.com/bldewolf/dhcpcd/commit/5aec6bbd13b0de0c8cc8111d82f827ef7d3eed35</a></div>
<div>2. The network interface says that it needs broadcast: <a href="https://github.com/bldewolf/dhcpcd/commit/fb4477f477d1faa60759f2b94e29c12999e1db49" target="_blank">https://github.com/bldewolf/dhcpcd/commit/fb4477f477d1faa60759f2b94e29c12999e1db49</a></div>
<div><br></div><div>Any thoughts? </div><div><br></div><div>Best, </div><span class="HOEnZb"><font color="#888888"><div>Camilo</div></font></span><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">
On Wed, May 28, 2014 at 9:39 PM, Camilo Aguilar <span dir="ltr"><<a href="mailto:camilo.aguilar@gmail.com" target="_blank">camilo.aguilar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>You are right. Apologies. I was stuck on my own work due to this issue and was eager to get it solved too soon. <div><br></div>
<div> I'll spend some more time tonight digging about how other DHCP clients deal with detecting if the interface supports link level unicast or not.</div></span><div>—<br>Sent from <a href="https://www.dropbox.com/mailbox" target="_blank">Mailbox</a>
</div><div><div>
<br><br><div class="gmail_quote"><p>On Wed, May 28, 2014 at 7:31 PM, Michael Marineau <span dir="ltr"><<a href="mailto:michael.marineau@coreos.com" target="_blank">michael.marineau@coreos.com</a>></span> wrote:<br>
</p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>On Wed, May 28, 2014 at 4:13 PM, Camilo Aguilar
<br><<a href="mailto:camilo.aguilar@gmail.com" target="_blank">camilo.aguilar@gmail.com</a>> wrote:
<br>> Oh, never mind, there is no rush since we are already custom patching in
<br>> CoreOS for now.
<br><br>Hey, don't get ahead of yourself. I haven't merged your patch into
<br>CoreOS just yet ;-)
<br>I'm fine with the patch being a temporary fix as long as we can sort
<br>out the final version soon.
<br><br>>
<br>>
<br>> On Wed, May 28, 2014 at 7:10 PM, Camilo Aguilar <<a href="mailto:camilo.aguilar@gmail.com" target="_blank">camilo.aguilar@gmail.com</a>>
<br>> wrote:
<br>>>
<br>>> It makes total sense. I can provide that patch in addition if you like,
<br>>> But, can we merge this change for now so we can fix
<br>>> <a href="https://github.com/coreos/bugs/issues/12" target="_blank">https://github.com/coreos/bugs/issues/12</a> and create a new issue to make it
<br>>> more robust?
<br>>>
<br>>>
<br>>> On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen <<a href="mailto:teg@jklm.no" target="_blank">teg@jklm.no</a>> wrote:
<br>>>>
<br>>>> On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar
<br>>>> <<a href="mailto:camilo.aguilar@gmail.com" target="_blank">camilo.aguilar@gmail.com</a>> wrote:
<br>>>> > In systems running on hypervisors this flag needs to be set ON, so
<br>>>> > offers can reach
<br>>>> > the virtual machines.
<br>>>> >
<br>>>> > For more information please refer to this thread in CoreOS:
<br>>>> > <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" target="_blank">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
<br>>>> > 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
<br>>>> > *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
<br>>>> > protocol
<br>>>> > + software has been configured with an IP address SHOULD set
<br>>>> > the
<br>>>> > + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER
<br>>>> > or
<br>>>> > + DHCPREQUEST messages that client sends. The BROADCAST bit
<br>>>> > will
<br>>>> > + provide a hint to the DHCP server and BOOTP relay agent to
<br>>>> > broadcast
<br>>>> > + any messages to the client on the client's subnet. */
<br>>>> > + packet->dhcp.flags = htobe16(0x8000);
<br>>>>
<br>>>> 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>Do you have any ideas on how to detect the issue documented here with
<br>VMware virtual machines? I haven't dug into this bug yet myself so I'm
<br>not sure what other DHCP implementations are doing off the top of my
<br>head.
<br><a href="https://github.com/coreos/bugs/issues/12" target="_blank">https://github.com/coreos/bugs/issues/12</a>
<br></p></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="">-- <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></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>