<div dir="ltr"><div dir="ltr"><div>Thanks a lot Simon, that did the trick.</div><div><br></div><div>The patch fixed the issue. I am able to see the reply messages being sent by server and the same being received by the client:</div><div><br></div><div>Jan 11 06:46:52 dnsmasq[4131]: started, version 2.78 DNS disabled<br>Jan 11 06:46:52 dnsmasq[4131]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify<br>Jan 11 06:46:52 dnsmasq-dhcp[4131]: DHCPv6, IP range 2020::10 -- 2020::20, lease time 1h<br>Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPSOLICIT(m1s1p1) 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20<br>Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPADVERTISE(m1s1p1) 2020::12 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20<br>Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREQUEST(m1s1p1) 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20<br>Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20<br>Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPRENEW(m1s1p1) 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20<br>Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPREPLY(m1s1p1) 2020::12 00:01:00:01:23:ca:f8:95:00:50:56:96:32:20</div><div><br></div><div>Everything is working fine even the renew. Thanks again.<br></div><div><br></div><div>Thanks</div><div>-Sandeep<br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 11, 2019 at 3:21 AM Simon Kelley <<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for the offer. I think there may be a simpler answer, worth<br>
trying first.<br>
<br>
Looking back through the git history, this looks like a bug introduced<br>
into 2.78 by the patches for security problems found by Google, in 2017.<br>
<br>
It was fixed for 2.79, by  patch<br>
<br>
<br>
<a href="http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=499d8dde2b1a216eab9252ee500cc31b8c2b2974" rel="noreferrer" target="_blank">http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=499d8dde2b1a216eab9252ee500cc31b8c2b2974</a><br>
<br>
So, first either move to 2.79 (or preferably 2.80) or apply that patch.<br>
<br>
If that doesn't fix it, we'll go for debugging.<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
<br>
<br>
On 10/01/2019 12:18, Sandeep K M wrote:<br>
> Hi Simon,<br>
> <br>
> Thanks again for the response.<br>
> <br>
> I will be happy to be your tester :)<br>
> <br>
> Its fairly a simple setup with two hosts and a switch. I can create this<br>
> any time you want.<br>
> <br>
> Please provide me the instructions. I am using dnsmasq version 2.78.<br>
> <br>
> Thanks<br>
> -Sandeep<br>
> <br>
> On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>>> wrote:<br>
> <br>
>     On 04/01/2019 06:25, Sandeep K M wrote:<br>
>     > Hi Simon,<br>
>     ><br>
>     > Thanks a lot for your prompt reply.<br>
>     ><br>
>     > Attached are the packet captures:<br>
>     ><br>
>     > 1. Packets exchanged between client and relay (client-relay.pcap)<br>
>     > 2.  Packets exchanged between relay and server (relay-server.pcap)<br>
>     > 3. strace of dnsmasq (dnsmasq.trace)<br>
>     ><br>
>     > Please let me know if any other information is required.  <br>
>     ><br>
>     > I am not an expert in reading pcap's or strace but I do see in the<br>
>     > attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE"<br>
>     message is<br>
>     > being written to the same interface from which it received the<br>
>     > "DHCPSOLICIT" packet. But still it is fails to go out of that<br>
>     interface.<br>
>     ><br>
>     > 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14<br>
>     > 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73<br>
>     ><br>
>     > Any help on this would be greatly appreciated. Also is there any<br>
>     example<br>
>     > configuration of dnsmasq dhcpv6 working with relay ? Any reference<br>
>     would<br>
>     > be of great help.<br>
>     ><br>
> <br>
>     I'm sure this was tested with a relay, but the current test harnesses<br>
>     here would take some work to get into a position to test this code, so<br>
>     I'm going to try and use you as a tester, if that's OK?<br>
> <br>
> <br>
>     Looking at the strace output, dnsmasq logs that it's sending a<br>
>     DHCPADVERTISE reply, but it never calls sendto() to actually send the<br>
>     packet. This is definitely a dnsmasq bug, and not something in your<br>
>     network that's causing the packet to get lost: it never gets sent.<br>
> <br>
> <br>
>     What's confusing me is that manually tracing the code paths from what's<br>
>     known to be working (log the DHCPADVERTISE) to the sendto() call that<br>
>     should send that packet, I can't see any reason why the code should<br>
>     fail.<br>
> <br>
>     Are you in a position to run dnsmasq under gdb and step through the<br>
>     relevant code? I can give you detailed instructions on where to set<br>
>     breakpoints and where the reply packet could be getting lost. The path<br>
>     is maybe 50 lines.<br>
> <br>
>     Staring at the code has found me one bug, but it's not relevant in this<br>
>     case. (The code to avoid copying an RFC6939 link address option in a<br>
>     relay request to the reply to the relay actually sends a zero-length<br>
>     option, instead of eliding it entirely.)<br>
> <br>
>     Cheers,<br>
> <br>
>     Simon.<br>
> <br>
> <br>
> <br>
> <br>
</blockquote></div>