Hi, After some testing and reconnecting PPP connection several times: All works fine. It also recognizes multiple old prefixes and sends all of them as deprecated.
Regarding the Android-Bug: I found out that I still have to enable the "fast" mode (which is only done in the first minute after a config change). The reason is: Although the prefix has a lifetime of 86400 on my dhcp-range, in contrast, the router itself gets a lifetime of 1800 secs (3 times RA_INTERVAL), the RDNS got a lifetime of 1200 secs (2 times RA_INTERVAL). To me this looks a bit inconsequent. The router itself is in my opinion the most stable thing of all, because its link-local-adress is used by clients. The DNS server should in my opinion have the same lifetime as the prefix / dhcp-range - or best would be to use this value: "dhcp-option=option6:information-refresh-time" (maybe you should send the dhcp's range's lease time as information-refresh-time on every dhcp request). I was able to fix the android bug again by reducing the re-transmit time by patcing the code, this time a bit more easy: I changed, as suggested by you, the if-statement in the function "new_timeout(struct dhcp_context *context, time_t now)", to always use the short interval of 5 - 20 secs. This solved the problem. I think if you add a config option to enable the fast retransmit if you have buggy android phones, we are fine. In addition, maybe have a separate config option to change the fast retransmit time (but different from RA_INTERVAL) and RA_INTERVAL itself (as you can do with radvd). Uwe P.S.: FYI, my DNS server address is a private IPv6 address which is assigned to the LAN interface in addition to the global prefix, see my other mail for explanation. So the DNS is stable here, stable as the link-local router address. I would recommend this setup also for router manufacturers. If the DNS server is not stable, the information-refresh-time in the DHCP packets should in any case be specified, otherwise the client never ever asks again for the DNS server. I checked this on windows computer. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- > discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler > Sent: Friday, July 26, 2013 6:50 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? > Deprecate old prefixes? > > Have fun in Berlin! But the new code makes it possible to me to set the > lifetime of the dhcp-lease to good old pre-IPv6 times (86400s) so it is > veeeeery unlikely that the android problem reappears. I have tested it, all is > fine now. > > The Android bug can be worked around by raising the lifetime/lease time in > the DHCP/RA - I raised it now back to 86400 like my already existing IPv4 > dhcp-range. It is very unlikely that the mobile phone is switched off to > standby for longer than one day! So when it wakes up, the prefix is still > valid. > If the prefix changes from the provider, its correctly deprecated, so all is > fine > now. > > One thing I found in my investigations: The lifetime given in the dhcp-range > for IPv6 oly affects the RAs, but not the time for refreshing the DHCP > information request. I had to set it explicitely as dhcp-option6. > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -----Original Message----- > > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > > Sent: Friday, July 26, 2013 5:45 PM > > To: Uwe Schindler > > Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? > > Deprecate old prefixes? > > > > On 26/07/13 16:24, Uwe Schindler wrote: > > > Hi Simon, > > > > > > Perfect! I will rebuild the debian package from the snapshot and > > > try out. As far as I see, you have not yet made the RA_INTERVAL > > > configurable (only for the unsolicited advertisements), > > > > Not yet, but I did split the calculation out into its own function in > preparation. > > > > Off to Berlin for IETF now. I should have some time to keep working on > > this during the conference. > > > > > > > > Cheers, > > > > Simon. > > > _______________________________________________ > 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
