[Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent
Sandeep K M
sandeep.matada at gmail.com
Fri Jan 11 08:47:41 GMT 2019
Thanks a lot Simon, that did the trick.
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:
Jan 11 06:46:52 dnsmasq[4131]: started, version 2.78 DNS disabled
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
Jan 11 06:46:52 dnsmasq-dhcp[4131]: DHCPv6, IP range 2020::10 -- 2020::20,
lease time 1h
Jan 11 06:47:47 dnsmasq-dhcp[4131]: DHCPSOLICIT(m1s1p1)
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
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
Jan 11 06:47:48 dnsmasq-dhcp[4131]: DHCPREQUEST(m1s1p1)
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
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
Jan 11 07:17:48 dnsmasq-dhcp[4131]: DHCPRENEW(m1s1p1)
00:01:00:01:23:ca:f8:95:00:50:56:96:32:20
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
Everything is working fine even the renew. Thanks again.
Thanks
-Sandeep
On Fri, Jan 11, 2019 at 3:21 AM Simon Kelley <simon at thekelleys.org.uk>
wrote:
> 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 <simon at thekelleys.org.uk
> > <mailto:simon at 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.
> >
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20190111/887abfa9/attachment.html>
More information about the Dnsmasq-discuss
mailing list