* [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
@ 2013-08-14 9:06 Ding Tianhong
2013-08-14 10:15 ` Hannes Frederic Sowa
0 siblings, 1 reply; 9+ messages in thread
From: Ding Tianhong @ 2013-08-14 9:06 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev
A LAN user can remotely disable temporary address which may lead
to privacy violatins and information disclosure.
The reason is that the linux kernel uses the 'ipv6.max_addresses'
option to specify how many ipv6 addresses and interface may have.
The 'ipv6.regen_max_retry' (default value 3) option specifies
how many times the kernel will try to create a new address.
But the kernel is not distinguish between the event of reaching
max_addresses for an interface and failing to generate a new address.
the kernel disable the temporary address after regenerate a new
address 'regen_max_retry' times.
According RFC4941 3.3.7:
---------------------------------------
If DAD indicates the address is already in use,
the node must generate a new randomized interface
identifier as described in section 3.2 above, and
repeat the previous steps as appropriate up to
TEMP_IDGEN_RETRIES times.
If after TEMP_IDGEN_RETRIES consecutive attempts no
non-unique address was generated, the node must log
a system error and must not attempt to generate
temporary address for that interface.
------------------------------------------
RFC4941 3.3.7 specifies that disabling the temp_address must happen
upon the address is already in use, not reach the max_address,
So we have to check the return err and distinguish the correct retry path.
This fixes CVE-2013-0343
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Tested-by: Wang Weidong <wangweidong1@huawei.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Eric Dumazet <edumazet@google.com>
---
net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index da4241c..7b55464 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1134,10 +1134,28 @@ retry:
if (IS_ERR_OR_NULL(ift)) {
in6_ifa_put(ifp);
in6_dev_put(idev);
- pr_info("%s: retry temporary address regeneration\n", __func__);
- tmpaddr = &addr;
- write_lock(&idev->lock);
- goto retry;
+
+ /* According RFC4941 3.3.7:
+ * If DAD indicates the address is already in use,
+ * the node must generate a new randomized interface
+ * identifier as described in section 3.2 above, and
+ * repeat the previous steps as appropriate up to
+ * TEMP_IDGEN_RETRIES times.
+ * If after TEMP_IDGEN_RETRIES consecutive attempts no
+ * non-unique address was generated, the node must log
+ * a system error and must not attempt to generate
+ * temporary address for that interface.
+ * So we have to check the return err and distinguish
+ * the correct retry path.
+ */
+ if (PTR_ERR(ift) == -EEXIST) {
+ pr_info("%s: retry temporary address regeneration\n", __func__);
+ tmpaddr = &addr;
+ write_lock(&idev->lock);
+ goto retry;
+ }
+ /* do not retry if the err code is not -EEXIST */
+ goto out;
}
spin_lock_bh(&ift->lock);
--
1.8.2.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-14 9:06 [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address Ding Tianhong
@ 2013-08-14 10:15 ` Hannes Frederic Sowa
2013-08-15 0:43 ` Ding Tianhong
0 siblings, 1 reply; 9+ messages in thread
From: Hannes Frederic Sowa @ 2013-08-14 10:15 UTC (permalink / raw)
To: Ding Tianhong
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev
On Wed, Aug 14, 2013 at 05:06:54PM +0800, Ding Tianhong wrote:
> A LAN user can remotely disable temporary address which may lead
> to privacy violatins and information disclosure.
>
> The reason is that the linux kernel uses the 'ipv6.max_addresses'
> option to specify how many ipv6 addresses and interface may have.
> The 'ipv6.regen_max_retry' (default value 3) option specifies
> how many times the kernel will try to create a new address.
>
> But the kernel is not distinguish between the event of reaching
> max_addresses for an interface and failing to generate a new address.
> the kernel disable the temporary address after regenerate a new
> address 'regen_max_retry' times.
>
> According RFC4941 3.3.7:
>
> ---------------------------------------
>
> If DAD indicates the address is already in use,
> the node must generate a new randomized interface
> identifier as described in section 3.2 above, and
> repeat the previous steps as appropriate up to
> TEMP_IDGEN_RETRIES times.
>
> If after TEMP_IDGEN_RETRIES consecutive attempts no
> non-unique address was generated, the node must log
> a system error and must not attempt to generate
> temporary address for that interface.
>
> ------------------------------------------
>
> RFC4941 3.3.7 specifies that disabling the temp_address must happen
> upon the address is already in use, not reach the max_address,
> So we have to check the return err and distinguish the correct retry path.
>
> This fixes CVE-2013-0343
I don't think this patch fixes CVE-2013-0343.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> Tested-by: Wang Weidong <wangweidong1@huawei.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index da4241c..7b55464 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1134,10 +1134,28 @@ retry:
> if (IS_ERR_OR_NULL(ift)) {
> in6_ifa_put(ifp);
> in6_dev_put(idev);
> - pr_info("%s: retry temporary address regeneration\n", __func__);
> - tmpaddr = &addr;
> - write_lock(&idev->lock);
> - goto retry;
> +
> + /* According RFC4941 3.3.7:
> + * If DAD indicates the address is already in use,
> + * the node must generate a new randomized interface
> + * identifier as described in section 3.2 above, and
> + * repeat the previous steps as appropriate up to
> + * TEMP_IDGEN_RETRIES times.
> + * If after TEMP_IDGEN_RETRIES consecutive attempts no
> + * non-unique address was generated, the node must log
> + * a system error and must not attempt to generate
> + * temporary address for that interface.
> + * So we have to check the return err and distinguish
> + * the correct retry path.
> + */
> + if (PTR_ERR(ift) == -EEXIST) {
-EEXIST is not the same as "ipv6 address is is already used on the
subnet". I really don't see the point here. IMHO this breaks the intended
regeneration logic.
I fear a fix of CVE-2013-0343 will be a bit more complicated. ;) I give it a
thought.
Greetings,
Hannes
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-14 10:15 ` Hannes Frederic Sowa
@ 2013-08-15 0:43 ` Ding Tianhong
2013-08-15 1:24 ` Hannes Frederic Sowa
0 siblings, 1 reply; 9+ messages in thread
From: Ding Tianhong @ 2013-08-15 0:43 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev
On 2013/8/14 18:15, Hannes Frederic Sowa wrote:
> On Wed, Aug 14, 2013 at 05:06:54PM +0800, Ding Tianhong wrote:
>> A LAN user can remotely disable temporary address which may lead
>> to privacy violatins and information disclosure.
>>
>> The reason is that the linux kernel uses the 'ipv6.max_addresses'
>> option to specify how many ipv6 addresses and interface may have.
>> The 'ipv6.regen_max_retry' (default value 3) option specifies
>> how many times the kernel will try to create a new address.
>>
>> But the kernel is not distinguish between the event of reaching
>> max_addresses for an interface and failing to generate a new address.
>> the kernel disable the temporary address after regenerate a new
>> address 'regen_max_retry' times.
>>
>> According RFC4941 3.3.7:
>>
>> ---------------------------------------
>>
>> If DAD indicates the address is already in use,
>> the node must generate a new randomized interface
>> identifier as described in section 3.2 above, and
>> repeat the previous steps as appropriate up to
>> TEMP_IDGEN_RETRIES times.
>>
>> If after TEMP_IDGEN_RETRIES consecutive attempts no
>> non-unique address was generated, the node must log
>> a system error and must not attempt to generate
>> temporary address for that interface.
>>
>> ------------------------------------------
>>
>> RFC4941 3.3.7 specifies that disabling the temp_address must happen
>> upon the address is already in use, not reach the max_address,
>> So we have to check the return err and distinguish the correct retry path.
>>
>> This fixes CVE-2013-0343
>
> I don't think this patch fixes CVE-2013-0343.
>
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> Tested-by: Wang Weidong <wangweidong1@huawei.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> ---
>> net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
>> 1 file changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index da4241c..7b55464 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -1134,10 +1134,28 @@ retry:
>> if (IS_ERR_OR_NULL(ift)) {
>> in6_ifa_put(ifp);
>> in6_dev_put(idev);
>> - pr_info("%s: retry temporary address regeneration\n", __func__);
>> - tmpaddr = &addr;
>> - write_lock(&idev->lock);
>> - goto retry;
>> +
>> + /* According RFC4941 3.3.7:
>> + * If DAD indicates the address is already in use,
>> + * the node must generate a new randomized interface
>> + * identifier as described in section 3.2 above, and
>> + * repeat the previous steps as appropriate up to
>> + * TEMP_IDGEN_RETRIES times.
>> + * If after TEMP_IDGEN_RETRIES consecutive attempts no
>> + * non-unique address was generated, the node must log
>> + * a system error and must not attempt to generate
>> + * temporary address for that interface.
>> + * So we have to check the return err and distinguish
>> + * the correct retry path.
>> + */
>> + if (PTR_ERR(ift) == -EEXIST) {
>
> -EEXIST is not the same as "ipv6 address is is already used on the
> subnet". I really don't see the point here. IMHO this breaks the intended
> regeneration logic.
>
> I fear a fix of CVE-2013-0343 will be a bit more complicated. ;) I give it a
> thought.
>
> Greetings,
>
> Hannes
>
>
ok, thanks for your feedback, I'll waiting you for more information to fix the problem.:)
> .
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-15 0:43 ` Ding Tianhong
@ 2013-08-15 1:24 ` Hannes Frederic Sowa
2013-08-15 2:16 ` Ding Tianhong
0 siblings, 1 reply; 9+ messages in thread
From: Hannes Frederic Sowa @ 2013-08-15 1:24 UTC (permalink / raw)
To: Ding Tianhong
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
On Thu, Aug 15, 2013 at 08:43:06AM +0800, Ding Tianhong wrote:
> On 2013/8/14 18:15, Hannes Frederic Sowa wrote:
> > On Wed, Aug 14, 2013 at 05:06:54PM +0800, Ding Tianhong wrote:
> >> A LAN user can remotely disable temporary address which may lead
> >> to privacy violatins and information disclosure.
> >>
> >> The reason is that the linux kernel uses the 'ipv6.max_addresses'
> >> option to specify how many ipv6 addresses and interface may have.
> >> The 'ipv6.regen_max_retry' (default value 3) option specifies
> >> how many times the kernel will try to create a new address.
> >>
> >> But the kernel is not distinguish between the event of reaching
> >> max_addresses for an interface and failing to generate a new address.
> >> the kernel disable the temporary address after regenerate a new
> >> address 'regen_max_retry' times.
> >>
> >> According RFC4941 3.3.7:
> >>
> >> ---------------------------------------
> >>
> >> If DAD indicates the address is already in use,
> >> the node must generate a new randomized interface
> >> identifier as described in section 3.2 above, and
> >> repeat the previous steps as appropriate up to
> >> TEMP_IDGEN_RETRIES times.
> >>
> >> If after TEMP_IDGEN_RETRIES consecutive attempts no
> >> non-unique address was generated, the node must log
> >> a system error and must not attempt to generate
> >> temporary address for that interface.
> >>
> >> ------------------------------------------
> >>
> >> RFC4941 3.3.7 specifies that disabling the temp_address must happen
> >> upon the address is already in use, not reach the max_address,
> >> So we have to check the return err and distinguish the correct retry path.
> >>
> >> This fixes CVE-2013-0343
> >
> > I don't think this patch fixes CVE-2013-0343.
> >
> >>
> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> >> Tested-by: Wang Weidong <wangweidong1@huawei.com>
> >> Cc: David S. Miller <davem@davemloft.net>
> >> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >> Cc: Eric Dumazet <edumazet@google.com>
> >> ---
> >> net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
> >> 1 file changed, 22 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> >> index da4241c..7b55464 100644
> >> --- a/net/ipv6/addrconf.c
> >> +++ b/net/ipv6/addrconf.c
> >> @@ -1134,10 +1134,28 @@ retry:
> >> if (IS_ERR_OR_NULL(ift)) {
> >> in6_ifa_put(ifp);
> >> in6_dev_put(idev);
> >> - pr_info("%s: retry temporary address regeneration\n", __func__);
> >> - tmpaddr = &addr;
> >> - write_lock(&idev->lock);
> >> - goto retry;
> >> +
> >> + /* According RFC4941 3.3.7:
> >> + * If DAD indicates the address is already in use,
> >> + * the node must generate a new randomized interface
> >> + * identifier as described in section 3.2 above, and
> >> + * repeat the previous steps as appropriate up to
> >> + * TEMP_IDGEN_RETRIES times.
> >> + * If after TEMP_IDGEN_RETRIES consecutive attempts no
> >> + * non-unique address was generated, the node must log
> >> + * a system error and must not attempt to generate
> >> + * temporary address for that interface.
> >> + * So we have to check the return err and distinguish
> >> + * the correct retry path.
> >> + */
> >> + if (PTR_ERR(ift) == -EEXIST) {
> >
> > -EEXIST is not the same as "ipv6 address is is already used on the
> > subnet". I really don't see the point here. IMHO this breaks the intended
> > regeneration logic.
> >
> > I fear a fix of CVE-2013-0343 will be a bit more complicated. ;) I give it a
> > thought.
> >
> > Greetings,
> >
> > Hannes
> >
> >
> ok, thanks for your feedback, I'll waiting you for more information to fix the problem.:)
[added George Kargiotakis and P J P to Cc and full quote]
I wonder if the easiest solution would be to just drop the max_addresses
limit from ipv6_create_tempaddr. max_addresses protects the kernel from
installing an unlimited amount of addresses on an interface which gets flooded
by RAs. Because we have a direct relation between interface address to temp
address, I don't see that we would create the possiblity of DoS.
Sure, an audit and testing is needed.
Greetings,
Hannes
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-15 1:24 ` Hannes Frederic Sowa
@ 2013-08-15 2:16 ` Ding Tianhong
2013-08-15 17:36 ` Hannes Frederic Sowa
0 siblings, 1 reply; 9+ messages in thread
From: Ding Tianhong @ 2013-08-15 2:16 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
On 2013/8/15 9:24, Hannes Frederic Sowa wrote:
> On Thu, Aug 15, 2013 at 08:43:06AM +0800, Ding Tianhong wrote:
>> On 2013/8/14 18:15, Hannes Frederic Sowa wrote:
>>> On Wed, Aug 14, 2013 at 05:06:54PM +0800, Ding Tianhong wrote:
>>>> A LAN user can remotely disable temporary address which may lead
>>>> to privacy violatins and information disclosure.
>>>>
>>>> The reason is that the linux kernel uses the 'ipv6.max_addresses'
>>>> option to specify how many ipv6 addresses and interface may have.
>>>> The 'ipv6.regen_max_retry' (default value 3) option specifies
>>>> how many times the kernel will try to create a new address.
>>>>
>>>> But the kernel is not distinguish between the event of reaching
>>>> max_addresses for an interface and failing to generate a new address.
>>>> the kernel disable the temporary address after regenerate a new
>>>> address 'regen_max_retry' times.
>>>>
>>>> According RFC4941 3.3.7:
>>>>
>>>> ---------------------------------------
>>>>
>>>> If DAD indicates the address is already in use,
>>>> the node must generate a new randomized interface
>>>> identifier as described in section 3.2 above, and
>>>> repeat the previous steps as appropriate up to
>>>> TEMP_IDGEN_RETRIES times.
>>>>
>>>> If after TEMP_IDGEN_RETRIES consecutive attempts no
>>>> non-unique address was generated, the node must log
>>>> a system error and must not attempt to generate
>>>> temporary address for that interface.
>>>>
>>>> ------------------------------------------
>>>>
>>>> RFC4941 3.3.7 specifies that disabling the temp_address must happen
>>>> upon the address is already in use, not reach the max_address,
>>>> So we have to check the return err and distinguish the correct retry path.
>>>>
>>>> This fixes CVE-2013-0343
>>>
>>> I don't think this patch fixes CVE-2013-0343.
>>>
>>>>
>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>> Tested-by: Wang Weidong <wangweidong1@huawei.com>
>>>> Cc: David S. Miller <davem@davemloft.net>
>>>> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>> Cc: Eric Dumazet <edumazet@google.com>
>>>> ---
>>>> net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
>>>> 1 file changed, 22 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>>> index da4241c..7b55464 100644
>>>> --- a/net/ipv6/addrconf.c
>>>> +++ b/net/ipv6/addrconf.c
>>>> @@ -1134,10 +1134,28 @@ retry:
>>>> if (IS_ERR_OR_NULL(ift)) {
>>>> in6_ifa_put(ifp);
>>>> in6_dev_put(idev);
>>>> - pr_info("%s: retry temporary address regeneration\n", __func__);
>>>> - tmpaddr = &addr;
>>>> - write_lock(&idev->lock);
>>>> - goto retry;
>>>> +
>>>> + /* According RFC4941 3.3.7:
>>>> + * If DAD indicates the address is already in use,
>>>> + * the node must generate a new randomized interface
>>>> + * identifier as described in section 3.2 above, and
>>>> + * repeat the previous steps as appropriate up to
>>>> + * TEMP_IDGEN_RETRIES times.
>>>> + * If after TEMP_IDGEN_RETRIES consecutive attempts no
>>>> + * non-unique address was generated, the node must log
>>>> + * a system error and must not attempt to generate
>>>> + * temporary address for that interface.
>>>> + * So we have to check the return err and distinguish
>>>> + * the correct retry path.
>>>> + */
>>>> + if (PTR_ERR(ift) == -EEXIST) {
>>>
>>> -EEXIST is not the same as "ipv6 address is is already used on the
>>> subnet". I really don't see the point here. IMHO this breaks the intended
>>> regeneration logic.
>>>
>>> I fear a fix of CVE-2013-0343 will be a bit more complicated. ;) I give it a
>>> thought.
>>>
>>> Greetings,
>>>
>>> Hannes
>>>
>>>
>> ok, thanks for your feedback, I'll waiting you for more information to fix the problem.:)
>
> [added George Kargiotakis and P J P to Cc and full quote]
>
> I wonder if the easiest solution would be to just drop the max_addresses
> limit from ipv6_create_tempaddr. max_addresses protects the kernel from
> installing an unlimited amount of addresses on an interface which gets flooded
> by RAs. Because we have a direct relation between interface address to temp
> address, I don't see that we would create the possiblity of DoS.
>
> Sure, an audit and testing is needed.
>
> Greetings,
>
> Hannes
>
I am afraid that if remove the max limit from the ipv6_create_tempaddr, the tool flood_route26 attack will create huge address to the temp_list, it will be a huge list,
may it destroy something or not?
Best regards
Ding Tianhong
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-15 2:16 ` Ding Tianhong
@ 2013-08-15 17:36 ` Hannes Frederic Sowa
2013-08-15 19:07 ` Hannes Frederic Sowa
0 siblings, 1 reply; 9+ messages in thread
From: Hannes Frederic Sowa @ 2013-08-15 17:36 UTC (permalink / raw)
To: Ding Tianhong
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
On Thu, Aug 15, 2013 at 10:16:51AM +0800, Ding Tianhong wrote:
> I am afraid that if remove the max limit from the ipv6_create_tempaddr, the tool flood_route26 attack will create huge address to the temp_list, it will be a huge list,
> may it destroy something or not?
I just tested, no it does not. Because it will only create a temporary address
for each prefix received, which still is limited by max_addresses. But of
course, more review is needed here. Maybe there is still a possibility to DoS?
Now we have to check why these addresses don't go out of tentative state.
Greetings,
Hannes
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-15 17:36 ` Hannes Frederic Sowa
@ 2013-08-15 19:07 ` Hannes Frederic Sowa
2013-08-16 0:48 ` Ding Tianhong
0 siblings, 1 reply; 9+ messages in thread
From: Hannes Frederic Sowa @ 2013-08-15 19:07 UTC (permalink / raw)
To: Ding Tianhong, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
On Thu, Aug 15, 2013 at 07:36:03PM +0200, Hannes Frederic Sowa wrote:
> Now we have to check why these addresses don't go out of tentative state.
Just looked at it. flood_router26 just emits pretty high values for
RetransTime:
21:05:52.050159 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 192) fe80::c:2a47:1360:1101 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 192
hop limit 255, Flags [none], pref high, router lifetime 65535s, reachable time 16384000ms, retrans time 1966080ms
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
We are completly in spec here. Just DAD needs a lot of time to finish.
Greetings,
Hannes
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-15 19:07 ` Hannes Frederic Sowa
@ 2013-08-16 0:48 ` Ding Tianhong
2013-08-16 11:07 ` Hannes Frederic Sowa
0 siblings, 1 reply; 9+ messages in thread
From: Ding Tianhong @ 2013-08-16 0:48 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
On 2013/8/16 3:07, Hannes Frederic Sowa wrote:
> On Thu, Aug 15, 2013 at 07:36:03PM +0200, Hannes Frederic Sowa wrote:
>> Now we have to check why these addresses don't go out of tentative state.
>
> Just looked at it. flood_router26 just emits pretty high values for
> RetransTime:
>
> 21:05:52.050159 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 192) fe80::c:2a47:1360:1101 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 192
> hop limit 255, Flags [none], pref high, router lifetime 65535s, reachable time 16384000ms, retrans time 1966080ms
> mtu option (5), length 8 (1): 1500
> 0x0000: 0000 0000 05dc
>
> We are completly in spec here. Just DAD needs a lot of time to finish.
>
> Greetings,
>
> Hannes
>
>
Great job, more and more close to the truth, let's find a better way to finish it.
> .
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
2013-08-16 0:48 ` Ding Tianhong
@ 2013-08-16 11:07 ` Hannes Frederic Sowa
0 siblings, 0 replies; 9+ messages in thread
From: Hannes Frederic Sowa @ 2013-08-16 11:07 UTC (permalink / raw)
To: Ding Tianhong
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
On Fri, Aug 16, 2013 at 08:48:44AM +0800, Ding Tianhong wrote:
> On 2013/8/16 3:07, Hannes Frederic Sowa wrote:
> > On Thu, Aug 15, 2013 at 07:36:03PM +0200, Hannes Frederic Sowa wrote:
> >> Now we have to check why these addresses don't go out of tentative state.
> >
> > Just looked at it. flood_router26 just emits pretty high values for
> > RetransTime:
> >
> > 21:05:52.050159 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 192) fe80::c:2a47:1360:1101 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 192
> > hop limit 255, Flags [none], pref high, router lifetime 65535s, reachable time 16384000ms, retrans time 1966080ms
> > mtu option (5), length 8 (1): 1500
> > 0x0000: 0000 0000 05dc
> >
> > We are completly in spec here. Just DAD needs a lot of time to finish.
> >
> > Greetings,
> >
> > Hannes
> >
> >
> Great job, more and more close to the truth, let's find a better way to finish it.
Thanks! :)
I just sent out a patch with the removal of the max_addresses
check. Please have a look!
I tested it with flood_router26 and modified it to also change the
retrans_time, because it affects in which interval addresses get
regenerated. We always were on the safe side.
Greetings,
Hannes
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-08-16 11:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-14 9:06 [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address Ding Tianhong
2013-08-14 10:15 ` Hannes Frederic Sowa
2013-08-15 0:43 ` Ding Tianhong
2013-08-15 1:24 ` Hannes Frederic Sowa
2013-08-15 2:16 ` Ding Tianhong
2013-08-15 17:36 ` Hannes Frederic Sowa
2013-08-15 19:07 ` Hannes Frederic Sowa
2013-08-16 0:48 ` Ding Tianhong
2013-08-16 11:07 ` Hannes Frederic Sowa
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.