Hi, > On 25/07/13 11:59, Uwe Schindler wrote: > > Hi again, > > > > In addition, I found a relic from the time when the RA_INTERVAL value > > was hardcoded into radv.c. There is still one: > > > > Line 294: put_opt6_long(1800); /* lifetime - twice RA retransmit */ > > > > Should be: put_opt6_long(RA_INTERVAL * 2); /* lifetime - twice RA > > retransmit */ > > Yes, that's a bug. > > > > I am currently looking into the code to find an easy way how to make > > the RA_INTERVAL configureable, maybe I can provide a patch. But if > > it's easy for you, it would be really nice to have this in future > > versions. So the deprecation of addresses no longer used on the > > network interface is not my primary concern, more I would prefer to > > work around the bugs in certain android phones not receiving ICMPv6 > > messages in standby mode, so the RA_INTERVAL should be configureable > > (I want to set it to much lower values than 600s, I have a patched > > version with 6s retransmit running on my debian testing box). > > > > Note that RA_INTERVAL is used in the code for two related things. > > 1) It sets the lifetime values for parameters being sent. At the moment, the > router advertisement is set to three times RA_INTERVAL, the DNS server and > domain-search params are twice RA_INTERVAL, and prefixes are set to (at > least RA_INTERVAL) > > 2) It sets how often unsolicited RA's are sent. > > Clearly these are related, the lifetime of parameters must be at least until > they can be renewed by another RA, and preferably longer, to allow for > packet loss. > > You probably don't want to reduce the lifetimes, that would be counter- > productive for the Android bug. you do want to send RAs more often. > > > The relevant code for that is here: > > if (difftime(param->now, context->ra_short_period_start) < 60.0) > /* range 5 - 20 */ > context->ra_time = param->now + 5 + (rand16()/4400); > else > /* range 3/4 - 1 times RA_INTERVAL */ > context->ra_time = param->now + (3 * RA_INTERVAL)/4 + > ((RA_INTERVAL * (unsigned int)rand16()) >> 18); > > > Which says that for the first minute after an configuration change, we > send RAs every 5- 20 seconds, the actual delay is random. Once the first > minute is up, we wait 3/4 of RA_INTERVAL to RA_INTERVAL. > > > It seems to me that the simplest solution might be lock the "fast" RA > mode, and never drop back to the full RA_INTERVAL delay. on a config > flag as "Android workaround mode"
This is a good idea, it is also easy to implement as a config flag? > Another solution might be to derive the RA retransmit rate from the RA > lifetimes, At the moment if you declare a RA prefix with a short > lifetime, the lifetime gets extended to be as long as RA_INTERVAL, > instead, we could reduce RA_INTERVAL to be the shortest configure > lifetime (or actually half of that to allow for lost packets). In general I like the "fast" RA mode to be enabled with a config flag, but nevertheless, the constant RA_INTERVAL should be configureable, so you can customize it. I agree that lowering RA_INTERVAL currently also makes the lifetimes shorter, which is bad for the android bug. So I would decouple the RDNS, router and prefix lifetimes from RA_INTERVAL and make RA_INTERVAL configureable. In my opinion, the RDNS should have the dhcp--range's lease time as lifetime (minimum RA_INTERVAL). The prefix already has the lease time of the corresponding dhcp-range. The router itself could be in the same lifetime or even longer, especially as the router's link-local address is fixed and never changes. Uwe _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
