Hi Camilo, Sorry for taking some time to get back to you.
On Sat, Jun 21, 2014 at 9:08 PM, Camilo Aguilar <camilo.agui...@gmail.com> wrote: > This is another reason why I previously suggested to expose a directive to > allow administrators to enable/disable the broadcast flag. I have seen DHCP > servers ignoring the flag and always sending broadcasted DHCPOFFERs. There > could be other servers that may only use unicast, Notice that the current client code should be ok with the server ignoring the broadcast flag, and just accept either broadcast or unicast packages. > and even networks that > might disallow broadcast traffic altogether. Hm, if I read the DHCP spec correctly it requires the networks to deal with broadcast packets, as NAK is always sent as broadcast, so if this is the case we have a bigger problem. > Set broadcast flag always ON for Firewire interfaces: > http://tools.ietf.org/html/rfc2855#section-2 > Set broadcast flag always ON for Infiniband interfaces: > http://tools.ietf.org/html/rfc4390#section-2.2 Once we support these RFC's, I agree that we should enable broadcast unconditionally for them (some work still needs to be done before we support DHCP over firewire/infiniband). > Set broadcast flag OFF by default, if and only if the interface is not > Infiniband or Firewire > Expose a configuration directive to allow administrators to configure the > broadcast flag in case there are DHCP servers ignoring the RFC, or networks > disallowing broadcast traffic. I'd be ok with making broadcast opt-in like this if we really have to, but I'd like to understand the problems seen by Friedrich first (still haven't gotten around to reproduce it). Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
