[Dnsmasq-discuss] Reproducible router solicitation issue

[Rodney Hester]

This has been confirmed as a bug in OpenVPN Client for Android, corrected
in release 2.15.02:

* Fix: The IPv6 Router Advertisement messages sent to local unicast address
are not received

No issue with dnsmasq.

Rodney

---------- Forwarded message ---------
From: Rodney Hester <rhester72 at gmail.com>
Date: Mon, Jun 20, 2016 at 11:33 AM
Subject: Reproducible router solicitation issue
To: dnsmasq-discuss at lists.thekelleys.org.uk <
dnsmasq-discuss at lists.thekelleys.org.uk>


I'm seeing a very, very, very odd bug in dnsmasq 2.75 (through the latest
git, actually, so I don't think it's version-specific).

Using the following IPv6-specific options:

options enable-ra
options dhcp-range=set:LAN1v6,2001:470:8a59::,ra-stateless,ra-names,604800s

provides timed and solicited RA messages properly to all devices on my
network (Windows, Android, Apple iDevices, Nest, you name it) as expected,
except my Android phone running the "rootless tap" version of OpenVPN found
here:

https://play.google.com/store/apps/details?id=it.colucciweb.openvpn&hl=en

On at least half of the connection attempts from that VPN client (success
or failure seems sporadic), every single router solicitation is ignored
until the last (default 5) attempt times out (after a default of 1 second),
and *then* dnsmasq responds:

00:00:00.000000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8)
fe80::16:3eff:fe2c:2f9d > ip6-allrouters: [icmp6 sum ok] ICMP6, router
solicitation, length 8
00:00:01.005421 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8)
fe80::16:3eff:fe2c:2f9d > ip6-allrouters: [icmp6 sum ok] ICMP6, router
solicitation, length 8
00:00:00.997793 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8)
fe80::16:3eff:fe2c:2f9d > ip6-allrouters: [icmp6 sum ok] ICMP6, router
solicitation, length 8
00:00:01.000927 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8)
fe80::16:3eff:fe2c:2f9d > ip6-allrouters: [icmp6 sum ok] ICMP6, router
solicitation, length 8
00:00:01.006930 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8)
fe80::16:3eff:fe2c:2f9d > ip6-allrouters: [icmp6 sum ok] ICMP6, router
solicitation, length 8
00:00:01.114724 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload
length: 104) fe80::1 > fe80::16:3eff:fe2c:2f9d: [icmp6 sum ok] ICMP6,
router advertisement, length 104
        hop limit 64, Flags [other stateful], pref medium, router lifetime
1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2001:470:8a59::/64, Flags
[onlink, auto], valid time 604800s, pref. time 604800s
          mtu option (5), length 8 (1):  1480
          source link-address option (1), length 8 (1): 44:d9:e7:9e:47:59
          dnssl option (31), length 16 (2):  lifetime 604800s, domain(s):
lan.
          rdnss option (25), length 24 (3):  lifetime 604800s, addr:
cerberus

Occasionally, it will actually respond as expected:

00:00:18.551061 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8)
fe80::16:3eff:fe2c:2f9d > ip6-allrouters: [icmp6 sum ok] ICMP6, router
solicitation, length 8
00:00:00.002004 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload
length: 104) fe80::1 > fe80::16:3eff:fe2c:2f9d: [icmp6 sum ok] ICMP6,
router advertisement, length 104
        hop limit 64, Flags [other stateful], pref medium, router lifetime
1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2001:470:8a59::/64, Flags
[onlink, auto], valid time 604800s, pref. time 604800s
          mtu option (5), length 8 (1):  1480
          source link-address option (1), length 8 (1): 44:d9:e7:9e:47:59
          dnssl option (31), length 16 (2):  lifetime 604800s, domain(s):
lan.
          rdnss option (25), length 24 (3):  lifetime 604800s, addr:
cerberus

If I instead use radvd with the following configuration (disabling RA from
dnsmasq and switching dhcp-range to static), it responds every single time
after the first solicitation without fail:

interface eth1 {
    IgnoreIfMissing on;
    AdvSendAdvert on;
    AdvOtherConfigFlag on;
    AdvDefaultLifetime 900;
    AdvLinkMTU 1480;
    AdvCurHopLimit 64;
    AdvReachableTime 0;
    MaxRtrAdvInterval 300;
    MinRtrAdvInterval 99;
    AdvDefaultPreference medium;
    AdvRetransTimer 0;
    AdvManagedFlag off;
    prefix 2001:470:8a59::/64 {
        AdvPreferredLifetime 604800;
        AdvAutonomous on;
        AdvOnLink on;
        AdvValidLifetime 2592000;
    };
    RDNSS 2001:470:8a59::1 {
    };
    DNSSL lan {};
};

with results as follows:

00:00:13.330352 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8)
fe80::16:3eff:fe2c:2f9d > ip6-allrouters: [icmp6 sum ok] ICMP6, router
solicitation, length 8
00:00:00.001310 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104)
fe80::1 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length
104
        hop limit 64, Flags [other stateful], pref medium, router lifetime
900s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2001:470:8a59::/64, Flags
[onlink, auto], valid time 2592000s, pref. time 604800s
          rdnss option (25), length 24 (3):  lifetime 300s, addr: cerberus
          dnssl option (31), length 16 (2):  lifetime 300s, domain(s): lan.
          mtu option (5), length 8 (1):  1480
          source link-address option (1), length 8 (1): 44:d9:e7:9e:47:59

This can be reproduced at will with no more than 3-4 connection attempts
max.  Altering the number of solicitations or the timeout (on OpenVPN) has
no effect - dnsmasq will continue to consistently immediately respond only
after the last solicitation has expired.

Any clue how I might go about troubleshooting this?  It seems likely to be
a rather obscure dnsmasq bug, but I've no idea how to identify/correct it.

Rodney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160622/da2fb989/attachment.html>