<div dir="ltr"><div>Hi Simon,</div><div><br></div><div>Thanks again for the response.</div><div><br></div><div>I will be happy to be your tester :)</div><div><br></div><div>Its fairly a simple setup with two hosts and a switch. I can create this any time you want. <br></div><div><br></div><div>Please provide me the instructions. I am using dnsmasq version 2.78.<br></div><div><br></div><div>Thanks</div><div>-Sandeep<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 9, 2019 at 10:33 PM 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">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" 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 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 example<br>
> configuration of dnsmasq dhcpv6 working with relay ? Any reference 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 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>