On 30 May 2014 10:12, "Patrik Flykt" <<a href="mailto:Patrik.Flykt@linux.intel.com">Patrik.Flykt@linux.intel.com</a>> wrote: > > On Thu, 2014-05-29 at 00:03 +0100, Tom Gundersen wrote: > > On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar > > <<a href="mailto:camilo.aguilar@gmail.com">camilo.aguilar@gmail.com</a>> 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: <a href="https://github.com/coreos/bugs/issues/12">https://github.com/coreos/bugs/issues/12</a> > > > > > > Signed-off-by: Camilo Aguilar <<a href="mailto:camilo.aguilar@gmail.com">camilo.aguilar@gmail.com</a>> > > > --- > > > 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? > > Actually, I have had recent reports from users that there seems to exist > a category of networking devices Do you have any more info on this by any chance? Any way we may classify these devices in a robust way? > which discard DHCPv4 messages unless > the messages are sent by broadcast. The users say that forcing the > DHCPv4 clients to use broadcast fixes the problem. > > I recently added a patch to ConnMan that always requests broadcast > replies when it is sending broadcast itself. That means broadcast > DHCPDiscover - DHCPOffer messages as well as DHCPRequest - DHCPAck/Nak > messages in Requesting and Rebinding states. Unicast is used for most of > the normal message sending in the Renewing state. This way not every > message is broadcast and if unicast messages disappear, there is always > Rebinding that gets through before lease expiry. Should we do the same > thing in networkd? > > > Cheers, > > Patrik >