<div dir="ltr">> <span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Notice that the current client code should be ok with the server</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">> ignoring the broadcast flag, and just accept either broadcast or</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">> unicast packages.</span><div><br></div><div><font color="#000000" face="arial, sans-serif">agreed</font></div><div><font color="#000000" face="arial, sans-serif"><br>
</font></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">>Hm, if I read the DHCP spec correctly it requires the networks to deal</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">>with broadcast packets, as NAK is always sent as broadcast, so if this</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">>is the case we have a bigger problem.</span><font color="#000000" face="arial, sans-serif"><br></font></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">My interpretation is that a DHCPNAK is usually sent through unicast unless the broadcast bit flag is ON in the DHCPDISCOVERY or </span><span style="color:rgb(0,0,0);white-space:pre-wrap">DHCPREQUEST</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> packet.</span><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> (Page 25)</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I was also cc'ed recently to a new case in Linode: </span><font color="#000000"><span style="white-space:pre-wrap"><a href="https://bugs.freedesktop.org/show_bug.cgi?id=81225">https://bugs.freedesktop.org/show_bug.cgi?id=81225</a></span></font></div>
<div><font color="#000000"><span style="white-space:pre-wrap">If what Linode says in this <a href="https://blog.linode.com/2003/09/24/network-filtering-improvements/">blog post</a> still holds true, then it seems Linode is filtering ARP broadcasts.</span></font></div>
<pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><span style="font-family:arial,sans-serif;font-size:13px;white-space:normal">> I'd be ok with making broadcast opt-in like this if we really have to,</span><br style="font-family:arial,sans-serif;font-size:13px;white-space:normal">
<span style="font-family:arial,sans-serif;font-size:13px;white-space:normal">> but I'd like to understand the problems seen by Friedrich first (still</span><br style="font-family:arial,sans-serif;font-size:13px;white-space:normal">
<span style="font-family:arial,sans-serif;font-size:13px;white-space:normal">> haven't gotten around to reproduce it).</span><br></pre>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 <a href="http://www.cyberciti.biz/faq/linux-unix-dhcpdump-monitor-dhcp-traffic/">dhcp dump</a>. <div>
<br></div><div>My suggestions are based on what I've seen implemented in dhcpcd and ISC dhcp, as well as my personal experience with some networks.</div><div><br></div><div>Best, </div><div>Camilo<br><div><br></div></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 29, 2014 at 2:56 PM, Tom Gundersen <span dir="ltr"><<a href="mailto:teg@jklm.no" target="_blank">teg@jklm.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Camilo,<br>
<br>
Sorry for taking some time to get back to you.<br>
<div class=""><br>
On Sat, Jun 21, 2014 at 9:08 PM, Camilo Aguilar<br>
<<a href="mailto:camilo.aguilar@gmail.com">camilo.aguilar@gmail.com</a>> wrote:<br>
> This is another reason why I previously suggested to expose a directive to<br>
> allow administrators to enable/disable the broadcast flag. I have seen DHCP<br>
> servers ignoring the flag and always sending broadcasted DHCPOFFERs. There<br>
> could be other servers that may only use unicast,<br>
<br>
</div>Notice that the current client code should be ok with the server<br>
ignoring the broadcast flag, and just accept either broadcast or<br>
unicast packages.<br>
<div class=""><br>
> and even networks that<br>
> might disallow broadcast traffic altogether.<br>
<br>
</div>Hm, if I read the DHCP spec correctly it requires the networks to deal<br>
with broadcast packets, as NAK is always sent as broadcast, so if this<br>
is the case we have a bigger problem.<br>
<div class=""><br>
> Set broadcast flag always ON for Firewire interfaces:<br>
> <a href="http://tools.ietf.org/html/rfc2855#section-2" target="_blank">http://tools.ietf.org/html/rfc2855#section-2</a><br>
> Set broadcast flag always ON for Infiniband interfaces:<br>
> <a href="http://tools.ietf.org/html/rfc4390#section-2.2" target="_blank">http://tools.ietf.org/html/rfc4390#section-2.2</a><br>
<br>
</div>Once we support these RFC's, I agree that we should enable broadcast<br>
unconditionally for them (some work still needs to be done before we<br>
support DHCP over firewire/infiniband).<br>
<div class=""><br>
> Set broadcast flag OFF by default, if and only if the interface is not<br>
> Infiniband or Firewire<br>
> Expose a configuration directive to allow administrators to configure the<br>
> broadcast flag in case there are DHCP servers ignoring the RFC, or networks<br>
> disallowing broadcast traffic.<br>
<br>
</div>I'd be ok with making broadcast opt-in like this if we really have to,<br>
but I'd like to understand the problems seen by Friedrich first (still<br>
haven't gotten around to reproduce it).<br>
<br>
Cheers,<br>
<br>
Tom<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><b>Camilo Aguilar</b></div><div>Software Engineer</div><div><a href="http://github.com/c4milo" target="_blank">http://github.com/c4milo</a></div>
<br><br></div>
</div>