> Notice that the current client code should be ok with the server > ignoring the broadcast flag, and just accept either broadcast or > unicast packages.
agreed >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. My interpretation is that a DHCPNAK is usually sent through unicast unless the broadcast bit flag is ON in the DHCPDISCOVERY or DHCPREQUEST packet. (Page 25) I was also cc'ed recently to a new case in Linode: https://bugs.freedesktop.org/show_bug.cgi?id=81225 If what Linode says in this blog post <https://blog.linode.com/2003/09/24/network-filtering-improvements/> still holds true, then it seems Linode is filtering ARP broadcasts. > 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). I'm not against understanding why this is failing on a case by case basis. it will be very useful if Friedrich could send us a dhcp dump <http://www.cyberciti.biz/faq/linux-unix-dhcpdump-monitor-dhcp-traffic/>. My suggestions are based on what I've seen implemented in dhcpcd and ISC dhcp, as well as my personal experience with some networks. Best, Camilo On Sun, Jun 29, 2014 at 2:56 PM, Tom Gundersen <t...@jklm.no> wrote: > 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 > -- *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
