On 26/07/13 22:19, Uwe Schindler wrote:
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).
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.
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.
Simon.
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.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
