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

Simon Kelley simon at thekelleys.org.uk
Wed Jan 9 17:03:29 GMT 2019


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.







More information about the Dnsmasq-discuss mailing list