On 15/02/18 20:35, Michael Garrison Stuber wrote:
> 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);  ?  :)
> 

Ah, no. our random number generation is much more complex than that. :)

> 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-ubnt2  Copyright (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.76  Copyright (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
> 
> 


From  the changelog for v.78

version 2.78

        Fix DHCP relaying, broken in 2.76 and 2.77 by commit
        ff325644c7afae2588583f935f4ea9b9694eb52e. Thanks to
        John Fitzgibbon for the diagnosis and patch.


So an upgrade for the remote router looks like a good first step.



Cheers,

Simon.




> 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
> 


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

Reply via email to