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

[Tom Gundersen]

On 30 May 2014 10:12, "Patrik Flykt" <Patrik.Flykt at linux.intel.com> wrote:
>
> 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

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