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

[Camilo Aguilar]

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.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.
>>
>> 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140528/40ae01f0/attachment.html>