[Dnsmasq-discuss] dnsmasq 2.78 is failing to respond to dhcpv6 requests forwarded via relay agent

[Simon Kelley]

Great. I'm distressed I didn't remember the issue until I ran "git
blame" over the code when putting together debugging instructions.

Cheers,

Simon.


On 11/01/2019 08:47, Sandeep K M wrote:
> 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
> <mailto: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>
>     > <mailto: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.
>     >
>     >
>     >
>     >
>