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

[Patrik Flykt]

On Thu, 2014-05-29 at 00:03 +0100, Tom Gundersen 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?

Actually, I have had recent reports from users that there seems to exist
a category of networking devices 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