Thanks for your help on this.

As always, we need to know what version of dnsmasq you are running. We
don't just increment those version numbers for fun!
Wait?  You don't just do printf("Dnsmasq Version %d.%d\n", rand() % 100, rand() %100);  ?  :)


Sorry about that.  I got so focused on the traces I forgot the version numbers.

The main router is running:

Dnsmasq version ubnt/2.78-1-ubnt2Copyright (c) 2000-2017 Simon Kelley

Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify


The remote router is running:

Dnsmasq version 2.76Copyright (c) 2000-2016 Simon Kelley

Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset Tomato-helper auth no-DNSSEC loop-detect no-inotify


I could potentially update either, though I'd prefer to work with what's on the device if at all possible.

The packet from the DHCP is sent to the relay at 192.168.10.1, which is
correct, and the last packet in your series, "seen at the Remote Router"
is sent to the broadcast address, 255.255.255.255, which is strong
evidence that the relay has, in fact picked up the reply and forwarded
it to the remote client.

Is it?  The Main Router/DHCP Server definitely sends a packet back to the remote router.  It is address to 192.168.10.1, but the broadcast bit is set.  The remote router receives it on the 192.168.1.2 interface.  I never see anything in the Dnsmasq log indicating that the relay response was received.  I also don't see anything being sent from the remote router to the client.  It seems like the response is getting to 192.168.1.2, but isn't getting picked up by the Dnsmasq running in the relay mode.

Am I correct in thinking that the Dnsmasq Relay instance should be listening for a response from the Dnsmasq DHCP server instance, and then should send the DHCP response to the client?

I was looking at the following: https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents to make sure I understood things correctly.   Notionally, the failure seems to be occurring at "2a" in figured 2 of the page.

It's sending it to the broadcast address
because the broadcast flag is on in the DHCP reply.

Is there a way to turn the broadcast flag off?  (Obviously the client needs to broadcast it's initial discover request, but it seems to me the relay could unicast the request to the server, and the server could unicast back.)

Which interface of
the remote router are you seeing this on. It's possible that the
relay-reply path is picking the wrong interface to send it out on.

The packet capture was looking at all interfaces, but the response is coming in on the 192.168.1.2 interface of the remote router.


On 2/14/2018 12:50 PM, Simon Kelley wrote:
On 12/02/18 21:35, Michael Garrison Stuber wrote:
Greetings!
     I'm trying to diagnose a problem with DHCP relaying via DNSMasq.
I'm hoping someone can help, or at least point to what to investigate
next.  I have a router running DNSMasq as a DHCP server.  I have a
second router connected to the first, running DNSMasq as a relay.

[Main Router] 192.168.1.1 <--WAN-Link--> 192.168.1.2 [Remote Router]
192.168.10.1 <--Client-LAN--> DHCP client.

     When a DHCP client comes on to the Client LAN, it sends a DHCP
request.  I see this in the Remote Router Log:

Feb 12 12:32:22 yew daemon.info dnsmasq-dhcp[7855]: DHCP relay
192.168.10.1 -> 192.168.1.1

     Remote Router forwards it the Main Router:

[Packets seen at Remote Router]

12:32:22.057611 Out 00:24:9b:29:81:f3 ethertype IPv4 (0x0800), length
344: (tos 0x0, ttl 128, id 22793, offset 0, flags [none], proto UDP
(17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
[|bootp]
12:32:22.058858 Out bc:ae:c5:c3:00:4d ethertype IPv4 (0x0800), length
344: (tos 0x0, ttl 64, id 38438, offset 0, flags [none], proto UDP (17),
length 328) 192.168.10.1.67 > 192.168.1.1.67: BOOTP/DHCP, Request [|bootp]
[Packets seen at Main Router]
12:32:22.213469  In 68:72:51:88:69:b4 ethertype IPv4 (0x0800), length
344: (tos 0x0, ttl 64, id 38438, offset 0, flags [none], proto UDP (17),
length 328)
     192.168.10.1.67 > 192.168.1.1.67: BOOTP/DHCP, Request from
00:24:9b:29:81:f3, length 300, hops 1, xid 0xf43325a2, secs 3072, Flags
[Broadcast]
           Gateway-IP 192.168.10.1
           Client-Ethernet-Address 00:24:9b:29:81:f3
           Vendor-rfc1048 Extensions
             Magic Cookie 0x63825363
             DHCP-Message Option 53, length 1: Discover
             Client-ID Option 61, length 7: ether 00:24:9b:29:81:f3
             Hostname Option 12, length 10: "MTGS-SBOOK"
             Vendor-Class Option 60, length 8: "MSFT 5.0"
             Parameter-Request Option 55, length 13:
               Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
               Router-Discovery, Static-Route, Vendor-Option,
Netbios-Name-Server
               Netbios-Node, Netbios-Scope, Classless-Static-Route,
Classless-Static-Route-Microsoft
               Option 252

     The main router responds:

[Packets seen at Main Router]
12:32:22.215239 Out 80:2a:a8:4f:c4:02 ethertype IPv4 (0x0800), length
346: (tos 0xc0, ttl 64, id 33748, offset 0, flags [none], proto UDP
(17), length 330)
     192.168.1.1.67 > 192.168.10.1.67: BOOTP/DHCP, Reply, length 302,
hops 1, xid 0xf43325a2, secs 3072, Flags [Broadcast]
           Your-IP 192.168.10.133
           Server-IP 192.168.1.1
           Gateway-IP 192.168.10.1
           Client-Ethernet-Address 00:24:9b:29:81:f3
           Vendor-rfc1048 Extensions
             Magic Cookie 0x63825363
             DHCP-Message Option 53, length 1: Offer
             Server-ID Option 54, length 4: 192.168.1.1
             Lease-Time Option 51, length 4: 86400
             RN Option 58, length 4: 43200
             RB Option 59, length 4: 75600
             Subnet-Mask Option 1, length 4: 255.255.255.0
             BR Option 28, length 4: 192.168.10.255
             Domain-Name Option 15, length 8: "localnet"
             Domain-Name-Server Option 6, length 4: 192.168.1.1
             Default-Gateway Option 3, length 4: 192.168.10.1

[Packet seen at Remote Router]
12:32:22.062199   P 80:2a:a8:4f:c4:02 ethertype IPv4 (0x0800), length
346: (tos 0xc0, ttl 64, id 33748, offset 0, flags [none], proto UDP
(17), length 330) 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP,
Reply, length 302, hops 1, xid 0xf43325a2, secs 3072, Flags [Broadcast]
           Your-IP 192.168.10.133
           Server-IP 192.168.1.1 [|bootp]

Unfortunately, the DNSMasq Process at the Remote Router never picks up
the response to send it to the client. I've tried using the <interface>
option of the --dhcp-relay option in DNSMasq, but it doesn't seem to
make a difference. ipforwarding is on, and iptables is set to accept
everything in both directions.  I can't tell whether DNSMasq at the
Remote Router is receiving the response and ignoring it, or if it never
makes it to the DNSMasq process.

Is there anyway to crank up the logging on DNSMasq even higher?  Am I
right in thinking that DNSMasq should in fact receive this message,
process it, and forward the response to the client?  Any tips on how to
trouble shoot this?


The packet from the DHCP is sent to the relay at 192.168.10.1, which is
correct, and the last packet in your series, "seen at the Remote Router"
is sent to the broadcast address, 255.255.255.255, which is strong
evidence that the relay has, in fact picked up the reply and forwarded
it to the remote client. It's sending it to the broadcast address
because the broadcast flag is on in the DHCP reply. Which interface of
the remote router are you seeing this on. It's possible that the
relay-reply path is picking the wrong interface to send it out on.

As always, we need to know what version of dnsmasq you are running. We
don't just increment those version numbers for fun!


Cheers,

Simon.


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

--
Michael Garrison Stuber

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to