Oh, never mind, there is no rush since we are already custom patching in CoreOS for now.
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. >> >> Does that make sense? >> >> Cheers, >> >> Tom >> >> > /* RFC2132 section 4.1.1: >> > The client MUST include its hardware address in the >> ’chaddr’ field, if >> > necessary for delivery of DHCP reply messages. >> > -- >> > 1.8.5.2 (Apple Git-48) >> > >> > >> > _______________________________________________ >> > systemd-devel mailing list >> > systemd-devel@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> > >> > > > > -- > *Camilo Aguilar* > Software Engineer > http://github.com/c4milo > > > -- *Camilo Aguilar* Software Engineer http://github.com/c4milo
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
