<div dir="ltr">As a test I would suggest adding this line to the DHCP configuration for that subnet, and see if it makes a difference:<div><br></div><div>always-broadcast true;<br></div><div><br></div><div>If it works, it could be a workaround.  We have had to use this to get certain clients to work with certain routers doing DHCP forwarding of broadcast packets, which is not the same as your issue, but close enough to be worth a test.</div><div><br></div><div class="gmail_extra"><div><div class="gmail_signature">-- <br>Bob Harold<br>University of Michigan</div></div>
<br><div class="gmail_quote">On Thu, Nov 6, 2014 at 3:23 PM, Mikhail Morfikov <span dir="ltr"><<a href="mailto:mmorfikov@gmail.com" target="_blank">mmorfikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Something is wrong !<br>
> Next step is to fire up a traffic sniffer on each end and see if the<br>
> Ack packets are getting back to the client or not. I assume the two<br>
> devices can communicate via other protocols ? The biggest difference<br>
> (networking wise) between the renewals (Request-Ack) and the "full<br>
> monty" (Discover-Offer-Request-Ack, or DORA for short) is that the<br>
> packet sin the DORA exchange are broadcast while the short renewal<br>
> uses unicast packets.<br>
<br>
</span>I think there's some kind of problem with WLAN interfaces on clients, or maybe it's<br>
just my wifi adapter. Below is a short test.<br>
...</blockquote><div> </div></div></div></div>