[Dnsmasq-discuss] DHCP Relay Problem
Michael Garrison Stuber
mtgstuber at gmail.com
Thu Feb 15 20:35:06 GMT 2018
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 at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
--
Michael Garrison Stuber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20180215/219fb8e7/attachment-0001.html>
More information about the Dnsmasq-discuss
mailing list