Thanks for the offer. I think there may be a simpler answer, worth trying first.
Looking back through the git history, this looks like a bug introduced into 2.78 by the patches for security problems found by Google, in 2017. It was fixed for 2.79, by patch http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=499d8dde2b1a216eab9252ee500cc31b8c2b2974 So, first either move to 2.79 (or preferably 2.80) or apply that patch. If that doesn't fix it, we'll go for debugging. Cheers, Simon. On 10/01/2019 12:18, Sandeep K M wrote: > Hi Simon, > > Thanks again for the response. > > I will be happy to be your tester :) > > Its fairly a simple setup with two hosts and a switch. I can create this > any time you want. > > Please provide me the instructions. I am using dnsmasq version 2.78. > > Thanks > -Sandeep > > On Wed, Jan 9, 2019 at 10:33 PM Simon Kelley <si...@thekelleys.org.uk > <mailto:si...@thekelleys.org.uk>> wrote: > > On 04/01/2019 06:25, Sandeep K M wrote: > > Hi Simon, > > > > Thanks a lot for your prompt reply. > > > > Attached are the packet captures: > > > > 1. Packets exchanged between client and relay (client-relay.pcap) > > 2. Packets exchanged between relay and server (relay-server.pcap) > > 3. strace of dnsmasq (dnsmasq.trace) > > > > Please let me know if any other information is required. > > > > I am not an expert in reading pcap's or strace but I do see in the > > attached strace i.e. dnsmasq.trace file that ""DHCPADVERTISE" > message is > > being written to the same interface from which it received the > > "DHCPSOLICIT" packet. But still it is fails to go out of that > interface. > > > > 06:04:09.371741 write(2, "DHCPADVERTISE(m1s1p7) 2020::14 > > 00:01:00:01:23:c1:b0:e2:00:50:56:bd:09:fb ", 73) = 73 > > > > Any help on this would be greatly appreciated. Also is there any > example > > configuration of dnsmasq dhcpv6 working with relay ? Any reference > would > > be of great help. > > > > I'm sure this was tested with a relay, but the current test harnesses > here would take some work to get into a position to test this code, so > I'm going to try and use you as a tester, if that's OK? > > > Looking at the strace output, dnsmasq logs that it's sending a > DHCPADVERTISE reply, but it never calls sendto() to actually send the > packet. This is definitely a dnsmasq bug, and not something in your > network that's causing the packet to get lost: it never gets sent. > > > What's confusing me is that manually tracing the code paths from what's > known to be working (log the DHCPADVERTISE) to the sendto() call that > should send that packet, I can't see any reason why the code should > fail. > > Are you in a position to run dnsmasq under gdb and step through the > relevant code? I can give you detailed instructions on where to set > breakpoints and where the reply packet could be getting lost. The path > is maybe 50 lines. > > Staring at the code has found me one bug, but it's not relevant in this > case. (The code to avoid copying an RFC6939 link address option in a > relay request to the reply to the relay actually sends a zero-length > option, instead of eliding it entirely.) > > Cheers, > > Simon. > > > > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss