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>
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
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to