<div dir="ltr">This has been confirmed as a bug in OpenVPN Client for Android, corrected in release 2.15.02:<div><br></div><div>* Fix: The IPv6 Router Advertisement messages sent to local unicast address are not received</div><div><br></div><div>No issue with dnsmasq.</div><div><br></div><div>Rodney<br><br><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: Rodney Hester <<a href="mailto:rhester72@gmail.com">rhester72@gmail.com</a>><br>Date: Mon, Jun 20, 2016 at 11:33 AM<br>Subject: Reproducible router solicitation issue<br>To: <a href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk">dnsmasq-discuss@lists.thekelleys.org.uk</a> <<a href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk">dnsmasq-discuss@lists.thekelleys.org.uk</a>><br></div><br><br><div dir="ltr"><div class="gmail_quote"><div dir="ltr">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).</div></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div>Using the following IPv6-specific options:</div><div><br></div><div><div>options enable-ra</div><div>options dhcp-range=set:LAN1v6,2001:470:8a59::,ra-stateless,ra-names,604800s</div></div><div><br></div><div>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:</div><div><br></div><div><a href="https://play.google.com/store/apps/details?id=it.colucciweb.openvpn&hl=en" target="_blank">https://play.google.com/store/apps/details?id=it.colucciweb.openvpn&hl=en</a><br></div><div><br></div><div>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:</div><div><br></div><div><div>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</div><div>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</div><div>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</div><div>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</div><div>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</div><div>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</div><div>        hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s</div><div>          prefix info option (3), length 32 (4): 2001:470:8a59::/64, Flags [onlink, auto], valid time 604800s, pref. time 604800s</div><div>          mtu option (5), length 8 (1):  1480</div><div>          source link-address option (1), length 8 (1): 44:d9:e7:9e:47:59</div><div>          dnssl option (31), length 16 (2):  lifetime 604800s, domain(s): lan.</div><div>          rdnss option (25), length 24 (3):  lifetime 604800s, addr: cerberus</div></div><div><br></div><div>Occasionally, it will actually respond as expected:</div><div><br></div><div><div>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</div><div>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</div><div>        hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s</div><div>          prefix info option (3), length 32 (4): 2001:470:8a59::/64, Flags [onlink, auto], valid time 604800s, pref. time 604800s</div><div>          mtu option (5), length 8 (1):  1480</div><div>          source link-address option (1), length 8 (1): 44:d9:e7:9e:47:59</div><div>          dnssl option (31), length 16 (2):  lifetime 604800s, domain(s): lan.</div><div>          rdnss option (25), length 24 (3):  lifetime 604800s, addr: cerberus</div></div><div><br></div><div>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:</div><div><br></div><div><div>interface eth1 {</div><div><span style="line-height:1.5">    IgnoreIfMissing on;</span><br></div><div>    AdvSendAdvert on;</div><div>    AdvOtherConfigFlag on;</div><div>    AdvDefaultLifetime 900;</div><div>    AdvLinkMTU 1480;</div><div>    AdvCurHopLimit 64;</div><div>    AdvReachableTime 0;</div><div>    MaxRtrAdvInterval 300;</div><div>    MinRtrAdvInterval 99;</div><div>    AdvDefaultPreference medium;</div><div>    AdvRetransTimer 0;</div><div>    AdvManagedFlag off;</div><div>    prefix 2001:470:8a59::/64 {</div><div>        AdvPreferredLifetime 604800;</div><div>        AdvAutonomous on;</div><div>        AdvOnLink on;</div><div>        AdvValidLifetime 2592000;</div><div>    };</div><div>    RDNSS 2001:470:8a59::1 {</div><div>    };</div><div>    DNSSL lan {};</div><div>};</div></div><div><br></div><div>with results as follows:</div><div><br></div><div><div>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</div><div>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</div><div>        hop limit 64, Flags [other stateful], pref medium, router lifetime 900s, reachable time 0s, retrans time 0s</div><div>          prefix info option (3), length 32 (4): 2001:470:8a59::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s</div><div>          rdnss option (25), length 24 (3):  lifetime 300s, addr: cerberus</div><div>          dnssl option (31), length 16 (2):  lifetime 300s, domain(s): lan.</div><div>          mtu option (5), length 8 (1):  1480</div><div>          source link-address option (1), length 8 (1): 44:d9:e7:9e:47:59</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div>Rodney</div></div></div></div></div></div></div>