On Wed, May 28, 2014 at 4:13 PM, Camilo Aguilar <camilo.agui...@gmail.com> wrote: > Oh, never mind, there is no rush since we are already custom patching in > CoreOS for now.
Hey, don't get ahead of yourself. I haven't merged your patch into CoreOS just yet ;-) I'm fine with the patch being a temporary fix as long as we can sort out the final version soon. > > > On Wed, May 28, 2014 at 7:10 PM, Camilo Aguilar <camilo.agui...@gmail.com> > wrote: >> >> 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 >> https://github.com/coreos/bugs/issues/12 and create a new issue to make it >> more robust? >> >> >> On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen <t...@jklm.no> wrote: >>> >>> On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar >>> <camilo.agui...@gmail.com> wrote: >>> > In systems running on hypervisors this flag needs to be set ON, so >>> > offers can reach >>> > the virtual machines. >>> > >>> > For more information please refer to this thread in CoreOS: >>> > https://github.com/coreos/bugs/issues/12 >>> > >>> > Signed-off-by: Camilo Aguilar <camilo.agui...@gmail.com> >>> > --- >>> > src/libsystemd-network/sd-dhcp-client.c | 9 +++++++++ >>> > 1 file changed, 9 insertions(+) >>> > >>> > diff --git a/src/libsystemd-network/sd-dhcp-client.c >>> > b/src/libsystemd-network/sd-dhcp-client.c >>> > index 0300a6b..8f54906 100644 >>> > --- a/src/libsystemd-network/sd-dhcp-client.c >>> > +++ b/src/libsystemd-network/sd-dhcp-client.c >>> > @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client >>> > *client, DHCPPacket **ret, >>> > refuse to issue an DHCP lease if 'secs' is set to zero */ >>> > packet->dhcp.secs = htobe16(client->secs); >>> > >>> > + /* RFC2132 section 4.1 >>> > + A client that cannot receive unicast IP datagrams until its >>> > protocol >>> > + software has been configured with an IP address SHOULD set >>> > the >>> > + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER >>> > or >>> > + DHCPREQUEST messages that client sends. The BROADCAST bit >>> > will >>> > + provide a hint to the DHCP server and BOOTP relay agent to >>> > broadcast >>> > + any messages to the client on the client's subnet. */ >>> > + packet->dhcp.flags = htobe16(0x8000); >>> >>> Hm, most clients can and should use unicast, so we should definitely >>> not request broadcast unconditionally. If there really is a situation >>> where we need broadcast, we should detect that and only request >>> broadcast in this case. Do you have any ideas on how to detect the issue documented here with VMware virtual machines? I haven't dug into this bug yet myself so I'm not sure what other DHCP implementations are doing off the top of my head. https://github.com/coreos/bugs/issues/12 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel