> 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 <t...@jklm.no> wrote: > On Fri, May 30, 2014 at 3:24 AM, Camilo Aguilar > <camilo.agui...@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
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel