On 27/07/13 19:11, Uwe Schindler wrote:
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).
git repo now has --force-fast-ra. I'm currently hacking on a tiny
netbook without access to my normal test harness, so this is untested.
It's simple enough that I probably haven't broken it :)
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.
Hmm, deprecate prefixes when dnsmasq goes down but the router doesn't,
but don't deprecate prefixes when the router goes down. That sounds
exactly backwards. I know I probably restart dnsmasq more often than
most (here at dnsmasq central, we eat our own dogfood....) but the idea
that stopping dnsmasq would kill all IPv6 connectivity on the network
sounds like a bad one to me.
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.
Fixed now, see previous message.
Cheers,
Simon.
Uwe
_______________________________________________ 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
