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

[Camilo Aguilar]

> I'd really hope we could avoid setting broadcast everywhere, as that
>seems very wasteful...

I agree with you, broadcasting everywhere it's clearly not convenient.

It seems to me the ideal path to move forward looks like this:

   1. Use platform specific raw sockets for the first attempt of getting a
   DHCPOFFER, through unicast and without ARP. Just like ISC's does
   <https://kb.isc.org/article/AA-00379/0/How-DHCP-uses-raw-sockets.html>.
   2. If *1* doesn't work, fall back to normal BSD sockets setting the
   broadcast flag on. This is done by ISC's impl too, as I showed in my
   previous email. See https://cloudup.com/cAneyImU2H2 and
   https://gist.github.com/c4milo/017a50a6f5d329887707
   3. Use Tom's patch for qeth devices setting
   /sys/class/net/%s/device/layer2 to 0 which seems to happen
   <https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8>
   but it will be nice to confirm.
   4. Provide a configuration parameter for administrators to set the
   broadcast flag manually.


In essence, Patrik's proposal is the same as 1 and 2, just a different
implementation.


>> + if (link->udev_device) {
>> +     const char *l2;
>> +
>> +     l2 = udev_device_get_sysattr_value(link->udev_device, "layer2");
>> +     if (l2) {
>> +             unsigned layer2;
>> +
>> +             r = safe_atou(l2, &layer2);
>> +             if (r < 0)
>> +                     return r;
>> +
>> +             if (!layer2) {
>> +                     r = sd_dhcp_client_request_
broadcast(link->dhcp_client);
>> +                     if (r < 0)
>> +                             return r;
>> +             }

>Am I now missing something if I can't find the
>file /sys/class/net/<device>/device/layer2 for a regular networking
>interface? The above enables broadcast only for virtual interfaces,
>right?

Patrik, based on what Tom says, I think the above patch will only cover
qeth devices setting /sys/class/net/%s/device/layer2 in 0 which seems to
happen in some cases:
https://github.com/bldewolf/dhcpcd/commit/3bc21a1a09852407df89a363c67d7575efa081c8


The issue that brought me here is consistently happening in VMware virtual
machines using bridged networking: https://github.com/coreos/bugs/issues/12

Best,
Camilo


On Fri, May 30, 2014 at 4:06 AM, Tom Gundersen <teg at jklm.no> wrote:

> On Fri, May 30, 2014 at 3:24 AM, Camilo Aguilar
> <camilo.aguilar at gmail.com> wrote:
> > Hi Tom, the patch did not work because there is no layer2 file. Would it
> be
> > safe to assume that no file is the same as the file having 0? This is
> out of
> > my reach unfortunately, but I will be happy to read whatever link you
> throw
> > at me.
>
> I don't think that would work, as only the qeth driver actually
> exposes the layer2 file (and to the best of my knowledge the other
> upstream drivers support unicast). If other drivers also can't do
> unicast, then they need to expose this information to us somehow, I'm
> afraid that I don't know anything about the VMWare driver, but
> hopefully we can find a way to get this info out of that driver too
> (would of course be nice if everyone used the same interface...).
>
> > Also, to better clarify how ISC dhcp-4.3.0 works. It seems it uses raw
> > sockets as a first attempt (layer2 unicast) and falls back to normal BSD
> > sockets which will always set the broadcast flag on:
> > https://cloudup.com/cAneyImU2H2 and
> > https://gist.github.com/c4milo/017a50a6f5d329887707
>
> I'd really hope we could avoid setting broadcast everywhere, as that
> seems very wasteful...
>
> Cheers,
>
> Tom
>



-- 
*Camilo Aguilar*
Software Engineer
http://github.com/c4milo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140530/2c979484/attachment.html>