Hi,

> > 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).
> 
> The 3 times RA_INTERVAL comes from the default given in RFC 4861, 
> section
> 6.2.1 which also specifies an absolute maximum value of 9000 seconds. 
> I don't know if it's sensible to violate this RFC.

OK that's fine. If the RFC says that, we should not violate! In general this 
means that the lifetime of the prefix does not need to be longer than that 
time, too. Because when the android phone does not get the RAs, its default 
gateway (router) will go away and so the IPv6 address is dead altogether.

In my opinion, if the DNS server information is not limited, it should be set 
to the time of the prefix, too.

> > 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).
> >
> 
> I want to try and avoid making every parameter changable, like Radv does.
> Who can tell what the parameters should be. A flag which says "stay in 
> fast retransmit mode to fix buggy android" seems much more sensible.

That is perfectly fine! So a boolean option to work around the android bug (and 
for other power-saving devices, which ignore ICMPv6 messages in sleep mode) 
would be enough! Ideally we could "detect" android devices and automatically 
switch to that mode once an android device is in the WLAN, but that’s not 
really possible without a large database of MAC address prefixes of broken WIFI 
chips/manufacturers. :-) Maybe Broadcom fixes the bug at some time and later 
Samsung devices does not have this problem (the HTC Desire here is completely 
responsible - with the backside that the ongoing ICMP requests drain battery 
faster, because kernel has to wake up to process the RA).

Finally I found one more small thing in addition to the "deprecated" prefixes: 
radvd sends shortly before exiting one or two last router advertisements to 
deprecate all prefixes it has given out before (this is also part of the 
"DeprecatePrefix" option of radvd). I found out that in the fact of a reboot of 
the router, when it comes back again there is no chance to deprecate the leases 
altogether.

Another option would be to save the "deprecated/used" prefixes in the "lease 
file", so it survives reboots of the router. In that case when somebody 
switches off the router by removing power coord or rebooting it through the web 
interface, it would announce the old prefixes as deprecated (for max 2 hours as 
we do currently). In my opinion, this would be nice to have, but its not 
urgent. At least it should send one or 2 RAs on shut down with 
preferred_lifetime=0 and maximum 2 hrs valid_ lifetime (but not greater than 
the current lifetime). Radvd does this if requested, so shutdown takes approx. 
1 second.

Oone small thing with your new code - maybe a bug, because the comment says 
something else: Although the valid_lifetime of the prefix is now lower (30 mins 
on my machine), after deprecation it raises the valid_lifetime again up to 2 
hrs. This is unneeded. It should use the lower of the current valid_lifetime or 
2 hrs (this is what it explains in the RFC): " then the IPv6 CE router MUST 
immediately advertise the old prefix with a Preferred Lifetime of zero and a 
Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which 
must be decremented in real time)". BTW: The 2 hours are a special number: it 
is the minimum time a router can use to reannounce the valid lifetime if it is 
currently higher. Otherwise a client would ignore this message - this is to 
prevent malicious clients from spoofing a router. This is why it must use a 
minimum of the current lifetime but never more than 2 hours to deprecate the 
prefix. The code should look like: Once a prefix is deprecated, use the current 
lifetime in the last RA and decrement it from now on.

Uwe


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to