[Dnsmasq-discuss] interface+macvlan on same network confuses dnsmasq v2.66rc2

Simon Kelley simon at thekelleys.org.uk
Tue Oct 22 16:45:38 BST 2013


On 21/10/13 20:31, Gui Iribarren wrote:
> Hello Simon!
> so, i'm trying to do whacky stuff with dnsmasq v2.66-rc2 on openwrt
>
> basically, i have two interfaces that have different ips but on the same
> netmask, and i want dnsmasq to offer dhcpv4 / RA on only one of them.
> yet, as dnsmasq config is thought out like "okay, here, have these
> ranges / prefixes, and find out by yourself on which interfaces you
> should offer them"
> i'm having a hard time.
>
> i thought of two alternatives:
> 1) use tag:interface when declaring the dhcp-ranges
> 2) use no-dhcp-interface=
>
> but none of them work as expected :( (i get the feeling i'm hitting
> bugs, walking an uncommon corner case)
>
> so, the actual details:
>
> ##########################################
>
> # ip a s br-lan
> 7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
> link/ether 64:70:02:fd:78:81 brd ff:ff:ff:ff:ff:ff
> inet 192.168.11.129/24 brd 192.168.11.255 scope global br-lan
> inet6 2a00:1508:1:f820::fd:7881/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::6670:2ff:fefd:7881/64 scope link
> valid_lft forever preferred_lft forever
> # ip a s anygw
> 22: anygw at br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UNKNOWN
> link/ether aa:aa:aa:40:28:b5 brd ff:ff:ff:ff:ff:ff
> inet 192.168.11.1/24 scope global anygw
> inet6 2a00:1508:1:f820::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::a8aa:aaff:fe40:28b5/64 scope link
> valid_lft forever preferred_lft forever
>
> ### anygw was created with the following command
> # ip link add link br-lan anygw address aa:aa:aa:40:28:b5 type macvlan
>
> ### i want dnsmasq to use anygw interface, and ignore br-lan
>
> ### first try:
> # cat /etc/dnsmasq.conf
> enable-ra
> dhcp-range=tag:anygw,2a00:1508:1:f820::, ra-names
> dhcp-range=tag:anygw,192.168.11.10,192.168.11.249,255.255.255.0,10m
>
> ### result: br-lan is not ignored; if i do "rdisc6" from a client,
> ### i get two RAs in reply, which breaks my whole idea
>
> Hop limit : 64 ( 0x40)
> Stateful address conf. : No
> Stateful other conf. : No
> Router preference : medium
> Router lifetime : 1800 (0x00000708) seconds
> Reachable time : unspecified (0x00000000)
> Retransmit time : unspecified (0x00000000)
> Prefix : 2a00:1508:1:f820::/64
> Valid time : 3600 (0x00000e10) seconds
> Pref. time : 3600 (0x00000e10) seconds
> MTU : 1500 bytes (valid)
> Source link-layer address: 64:70:02:FD:78:81
> Recursive DNS server : 2a00:1508:1:f820::fd:7881
> DNS server lifetime : 1200 (0x000004b0) seconds
> from fe80::6670:2ff:fefd:7881
>
> Hop limit : 64 ( 0x40)
> Stateful address conf. : No
> Stateful other conf. : No
> Router preference : medium
> Router lifetime : 1800 (0x00000708) seconds
> Reachable time : unspecified (0x00000000)
> Retransmit time : unspecified (0x00000000)
> Prefix : 2a00:1508:1:f820::/64
> Valid time : 3600 (0x00000e10) seconds
> Pref. time : 3600 (0x00000e10) seconds
> MTU : 1500 bytes (valid)
> Source link-layer address: AA:AA:AA:40:28:B5
> Recursive DNS server : 2a00:1508:1:f820::1
> DNS server lifetime : 1200 (0x000004b0) seconds
> from fe80::a8aa:aaff:fe40:28b5
>
> ### and this on the router log
>
> dnsmasq-dhcp[5637]: RTR-ADVERT(br-lan) 2a00:1508:1:f820::
> dnsmasq-dhcp[5637]: RTR-SOLICIT(br-lan)
> dnsmasq-dhcp[5637]: RTR-ADVERT(br-lan) 2a00:1508:1:f820::
> dnsmasq-dhcp[5637]: RTR-SOLICIT(anygw)
> dnsmasq-dhcp[5637]: RTR-ADVERT(anygw) 2a00:1508:1:f820::
> dnsmasq-dhcp[5637]: RTR-ADVERT(br-lan) 2a00:1508:1:f820::
>
> ### while in dhcpv4 it works a bit better, but also messes up a bit
> ### (client is doing "dhclient")
> dnsmasq-dhcp[5637]: DHCPDISCOVER(br-lan) 20:16:d8:65:4d:29 no address
> available
> dnsmasq-dhcp[5637]: DHCPDISCOVER(anygw) 20:16:d8:65:4d:29
> dnsmasq-dhcp[5637]: DHCPOFFER(anygw) 192.168.11.19 20:16:d8:65:4d:29
> dnsmasq-dhcp[5637]: DHCPREQUEST(br-lan) 192.168.11.19 20:16:d8:65:4d:29
> dnsmasq-dhcp[5637]: DHCPNAK(br-lan) 192.168.11.19 20:16:d8:65:4d:29
> wrong server-ID
> dnsmasq-dhcp[5637]: DHCPREQUEST(anygw) 192.168.11.19 20:16:d8:65:4d:29
> dnsmasq-dhcp[5637]: DHCPACK(anygw) 192.168.11.19 20:16:d8:65:4d:29 preta
>
> ### the OFFER it's sending is a funny mix:
> ### it is sent *from* br-lan MAC and IP (192.168.11.129)
> ### but 'router' and 'dns server' fields point to anygw (192.168.11.1)
>
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
> DHCPREQUEST of 192.168.11.19 on wlan0 to 255.255.255.255 port 67
> DHCPOFFER of 192.168.11.19 from 192.168.11.129
> DHCPACK of 192.168.11.19 from 192.168.11.129
>
>
> ###### now, on to option (2), i add no-dhcp-interface=br-lan
>
> # cat /etc/dnsmasq.conf
> enable-ra
> dhcp-range=tag:anygw,2a00:1508:1:f820::, ra-names
> dhcp-range=tag:anygw,192.168.11.10,192.168.11.249,255.255.255.0,10m
> no-dhcp-interface=br-lan
>
> ### yay! v6 works! i get only one RA, from anygw interface
>
> dnsmasq-dhcp[6464]: RTR-SOLICIT(anygw)
> dnsmasq-dhcp[6464]: RTR-ADVERT(anygw) 2a00:1508:1:f820::
>
> ### but dhcpv4 is broken :( clients don't get OFFERs
>
> dnsmasq-dhcp[6794]: DHCPDISCOVER(anygw) 20:16:d8:65:4d:29
> dnsmasq-dhcp[6794]: DHCPOFFER(anygw) 192.168.11.20 20:16:d8:65:4d:29
> dnsmasq-dhcp[6794]: DHCPDISCOVER(anygw) 20:16:d8:65:4d:29
> dnsmasq-dhcp[6794]: DHCPOFFER(anygw) 192.168.11.20 20:16:d8:65:4d:29
>
> ### tcpdump shows no such DHCPOFFER actually being sent out
>
> ### and here comes the bizarre...
> ### while playing with this back and forth, it started working,
> ### turns out, the lease-file was populated in setup (1). i.e.
> ### if there's a lease for that client already in the lease-file
> ### then the OFFER is actually sent out
>
> dnsmasq-dhcp[7320]: DHCPDISCOVER(anygw) 20:16:d8:65:4d:29
> dnsmasq-dhcp[7320]: DHCPOFFER(anygw) 192.168.11.19 20:16:d8:65:4d:29
> dnsmasq-dhcp[7320]: DHCPREQUEST(anygw) 192.168.11.19 20:16:d8:65:4d:29
> dnsmasq-dhcp[7320]: DHCPACK(anygw) 192.168.11.19 20:16:d8:65:4d:29 preta
>
> ### but no new clients are able to get a first lease.
> ### (and "preta" only got a lease because it was generated by a
> ### previous dnsmasq run, without no-dhcp-interface)

My hunch is that this is something to do with ARP. For an unconfigured 
client (ie doing DHCPDISCOVER) dnsmasq ends up knowing the MAC address 
of the client and its IP address, but the client _doesn't_ know that IP 
address, and so can't respond to a ARP request. To get round this, 
dnsmasq populates the ARP table on the server directly with the IP 
address, MAC address and interface. Then it send the OFFER packet to the 
IP address and the kernel knows how to route it. I think that  you 
"interesting" setup may be confusing this process. In the second 
instance, I suspect that the crucial thing that makes it work is not the 
presence of a lease in the lease-file, but a correct ARP-table entry 
from the previous activity.

Certainly, a few more experiments, and looking at the output of

arp -a

would be instructive.


Looking again - there are more clues:

  ### the OFFER it's sending is a funny mix:
  ### it is sent *from* br-lan MAC and IP (192.168.11.129)

That may be the MAC address thing I talked about, or it may be something 
else. Another experiment: try setting

--dhcp-broadcast

and see what happens then.


Cheers,

Simon


Cheers,

Simon.



More information about the Dnsmasq-discuss mailing list