On 02/07/14 07:30, Lung-Pin Chang wrote:
Hi folks,
I'm currently using dnsmasq 2.70 (compiled from source) in my Linux
environment for IPv6 RA/DHCPv6.
The following section is my dnsmasq config:
interface=lbr0
dhcp-range=set:lbr0v60,2002:01ab:68c7:beef::5566,2002:01ab:68c7:beef::5600,64,86400
dhcp-option=tag:lbr0v60,option6:dns-server,[2001:4860:4860::],[2001:4860:4860::8844]
enable-ra
dhcp-leasefile=/etc/dhcpd/dhcpd.conf.leases
dhcp-script=/usr/syno/etc/dhcpd/dhcpd-script.sh
and my interface address configuration:
8: lbr0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue
link/ether 00:00:15:69:67:15 brd ff:ff:ff:ff:ff:ff
inet6 2002:1ab:68c7:beef::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::200:15ff:fe69:6715/64 scope link
valid_lft forever preferred_lft forever
66: 6in4: POINTOPOINT,NOARP,UP,LOWER_UP mtu 1472 qdisc noqueue
link/sit 1.171.104.199 peer 192.88.99.1
inet6 2002:1ab:68c7::1/16 scope global
valid_lft forever preferred_lft forever
inet6 fe80::1ab:68c7/128 scope link
valid_lft forever preferred_lft forever
With logging facilities in my dhcp-script, I noticed that the script
is invoked by the old event when I kill -HUP dnsmasq pid.
The problem is: when my script got invoked, the DNSMASQ_INTERFACE
environment is set to a wrong interface (i.e., 6in4, instead of the
incoming interface lbr0).
After digging a while in the source code, I found that the
find_interface_v6 callback (src/lease.c) might be the cause:
Given several interfaces share common prefix with different prefix length,
current interface searching mechanism (lease_find_interfaces -
iface_enumerate) would
enumerate all the addresses on the host by netlink RTM_GETADDR
request, trying to figure out
which interface is the packet originated from by checking if they're
in the same subnet.
But with the netlink parsing flow, when multiple interfaces match, the
originated interface would
always be the one that comes later in the netlink message. So in my
case, the originated
interface would always be 6in4, even if the prefix length on it is
apparently shorter than lbr0.
Is that a legal interface configuration? IPv6 seems to be capable of
generating endless surprises like this!
I came up with a quick fix[1] to save the interface prefix length in
the lease context,
so longer prefixes are always preferred and the script got invoked
with correct interface.
I think that's fine. The only problem remaining is that
lease_set_interface might be called with the wrong interface, before
it's called with the right interface. I don't think that causes any
serious problems, but it might be worth making the patch a bit more
complex to avoid the problem, to save problems now or in the future.
Determining the correct interface for each lease in a new_interface
field in the lease structure,then calling lease_set_interface() on those
values would do it.
But I'm not sure if this also applies to IPv4, as I'm testing in a
IPv6-only environment in Linux
If the nested-prefixes condition can occur in IPv4, then the same thing
will apply, and the same sort of fix would work. Note that this problem,
if not fixed, will cause serious issues with the ra-names mode, which
uses the interface to find the possible SLAAC addresses of host with a
DHCPv4 lease.
(so I only traced the netlink part).
Cheers,
Simon.
Cheers
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
