[systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1

[Michael Marineau]

On Wed, May 28, 2014 at 4:13 PM, Camilo Aguilar
<camilo.aguilar at 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.aguilar at 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 <teg at jklm.no> wrote:
>>>
>>> On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar
>>> <camilo.aguilar at 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.aguilar at 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