* Linux kernel handling of IPv6 temporary addresses @ 2012-11-14 21:14 George Kargiotakis 2012-11-14 21:29 ` David Miller 0 siblings, 1 reply; 8+ messages in thread From: George Kargiotakis @ 2012-11-14 21:14 UTC (permalink / raw) To: netdev Hello all, Due to the way the Linux kernel handles the creation of IPv6 temporary addresses a malicious LAN user can remotely disable them altogether which may lead to privacy violations and information disclosure. By default the Linux kernel uses the 'ipv6.max_addresses' option to specify how many IPv6 addresses an interface may have. The 'ipv6.regen_max_retry' option specifies how many times the kernel will try to create a new address. Currently, in net/ipv6/addrconf.c,lines 898-910, there is no distinction between the events of reaching max_addresses for an interface and failing to generate a new address. Upon reaching any of the above conditions the following error is emitted by the kernel times 'regen_max_retry' (default value 3): [183.793393] ipv6_create_tempaddr(): retry temporary address regeneration [183.793405] ipv6_create_tempaddr(): retry temporary address regeneration [183.793411] ipv6_create_tempaddr(): retry temporary address regeneration After 'regen_max_retry' is reached the kernel completely disables temporary address generation for that interface. [183.793413] ipv6_create_tempaddr(): regeneration time exceeded - disabled temporary address support RFC4941 3.3.7 specifies that disabling temp_addresses MUST happen upon failure to create non-unique addresses which is not the above case. Addresses would have been created if the kernel had a higher 'ipv6.max_addresses' limit. A malicious LAN user can send a limited amount of RA prefixes and thus disable IPv6 temporary address creation for any Linux host. Recent distributions which enable the IPv6 Privacy extensions by default, like Ubuntu 12.04 and 12.10, are vulnerable to such attacks. Due to the kernel's default values for valid (604800) and preferred (86400) lifetimes, this scenario may even occur under normal usage when a Router sends both a public and a ULA prefix, which is not an uncommon scenario for IPv6. 16 addresses are not enough with the current default timers when more than 1 prefix is advertised. The kernel should at least differentiate between the two cases of reaching max_addresses and being unable to create new addresses, due to DAD conflicts for example. Best regards, -- George Kargiotakis https://void.gr GPG KeyID: 0xE4F4FFE6 GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses 2012-11-14 21:14 Linux kernel handling of IPv6 temporary addresses George Kargiotakis @ 2012-11-14 21:29 ` David Miller 2012-11-14 23:03 ` George Kargiotakis 0 siblings, 1 reply; 8+ messages in thread From: David Miller @ 2012-11-14 21:29 UTC (permalink / raw) To: kargig; +Cc: netdev From: George Kargiotakis <kargig@void.gr> Date: Wed, 14 Nov 2012 23:14:11 +0200 > Due to the way the Linux kernel handles the creation of IPv6 temporary > addresses a malicious LAN user can remotely disable them altogether > which may lead to privacy violations and information disclosure. A malicious user who can emit random packets as root on your LAN can also corrupt your ARP cache with entries that point to the wrong MAC address. What's your point? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses 2012-11-14 21:29 ` David Miller @ 2012-11-14 23:03 ` George Kargiotakis 2012-11-14 23:08 ` David Miller 0 siblings, 1 reply; 8+ messages in thread From: George Kargiotakis @ 2012-11-14 23:03 UTC (permalink / raw) To: David Miller; +Cc: netdev On Wed, 14 Nov 2012 16:29:56 -0500 (EST) David Miller <davem@davemloft.net> wrote: > From: George Kargiotakis <kargig@void.gr> > Date: Wed, 14 Nov 2012 23:14:11 +0200 > > > Due to the way the Linux kernel handles the creation of IPv6 > > temporary addresses a malicious LAN user can remotely disable them > > altogether which may lead to privacy violations and information > > disclosure. > > A malicious user who can emit random packets as root on your LAN can > also corrupt your ARP cache with entries that point to the wrong MAC > address. > > What's your point? Hello, I think it's an issue that a LAN root user can disable a locally enabled kernel "feature" for good. The kernel could provide a somewhat more informative message on such an occasion taking place, since it knows that max_addresses limit has been reached and it's not a DAD failure. My point is that I'd like the kernel to handle this situation a bit differently than it currently does. Best regards, -- George Kargiotakis https://void.gr GPG KeyID: 0xE4F4FFE6 GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses 2012-11-14 23:03 ` George Kargiotakis @ 2012-11-14 23:08 ` David Miller 2012-11-16 21:27 ` Ben Hutchings 2012-12-27 15:57 ` George Kargiotakis 0 siblings, 2 replies; 8+ messages in thread From: David Miller @ 2012-11-14 23:08 UTC (permalink / raw) To: kargig; +Cc: netdev From: George Kargiotakis <kargig@void.gr> Date: Thu, 15 Nov 2012 01:03:24 +0200 > I think it's an issue that a LAN root user can disable a > locally enabled kernel "feature" for good. The kernel could provide a > somewhat more informative message on such an occasion taking place, > since it knows that max_addresses limit has been reached and it's not a > DAD failure. > > My point is that I'd like the kernel to handle this situation a bit > differently than it currently does. Read my example again, it's the same thing for ipv4. The root LAN user can disable all IPV4 communications to arbitrary IP addresses on the local LAN by emitting bogus ARP requests and poisoning everyone's caches. What's the difference between that and this arbitrary ipv6 issue? There is none at all. If you have a root person on your local LAN you're subject to injection of bogus addressing and routing information. This issue is not specific to ipv4 or ipv6 and is fundamental in nature. So it is misleading to bring this up as an ipv6 specific problem, it's not. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses 2012-11-14 23:08 ` David Miller @ 2012-11-16 21:27 ` Ben Hutchings 2012-12-27 15:57 ` George Kargiotakis 1 sibling, 0 replies; 8+ messages in thread From: Ben Hutchings @ 2012-11-16 21:27 UTC (permalink / raw) To: David Miller; +Cc: kargig, netdev On Wed, 2012-11-14 at 18:08 -0500, David Miller wrote: > From: George Kargiotakis <kargig@void.gr> > Date: Thu, 15 Nov 2012 01:03:24 +0200 > > > I think it's an issue that a LAN root user can disable a > > locally enabled kernel "feature" for good. The kernel could provide a > > somewhat more informative message on such an occasion taking place, > > since it knows that max_addresses limit has been reached and it's not a > > DAD failure. > > > > My point is that I'd like the kernel to handle this situation a bit > > differently than it currently does. > > Read my example again, it's the same thing for ipv4. > > The root LAN user can disable all IPV4 communications to arbitrary IP > addresses on the local LAN by emitting bogus ARP requests and > poisoning everyone's caches. What's the difference between that > and this arbitrary ipv6 issue? > > There is none at all. > > If you have a root person on your local LAN you're subject to injection > of bogus addressing and routing information. This issue is not specific > to ipv4 or ipv6 and is fundamental in nature. > > So it is misleading to bring this up as an ipv6 specific problem, it's > not. You're quite right about this, but I think George's point may be that it's harder to recover if and when the malicious traffic is stopped. Poisoned ARP table entries will expire fairly quickly. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses 2012-11-14 23:08 ` David Miller 2012-11-16 21:27 ` Ben Hutchings @ 2012-12-27 15:57 ` George Kargiotakis 2012-12-27 16:54 ` Eric Dumazet 1 sibling, 1 reply; 8+ messages in thread From: George Kargiotakis @ 2012-12-27 15:57 UTC (permalink / raw) To: netdev Hello all, I had previously informed this list about the issue of the linux kernel losing IPv6 privacy extensions by a local LAN attacker. Recently I've found that there's actually another, more serious in my opinion, issue that follows the previous one. If the user tries to disconnect/reconnect the network device/connection for whatever reason (e.g. thinking he might gain back privacy extensions), then the device gets IPs from SLAAC that have the "tentative" flag and never loses that. That means that IPv6 functionality for that device is from then on completely lost. I haven't been able to bring back the kernel to a working IPv6 state without a reboot. This is definitely a DoS situation and it needs fixing. Here are the steps to reproduce: == Step 1. Boot Ubuntu 12.10 (kernel 3.5.0-17-generic) == ubuntu@ubuntu:~$ ip a ls dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0 inet6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic valid_lft 86379sec preferred_lft 3579sec inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global dynamic valid_lft 86379sec preferred_lft 3579sec inet6 fdbb:aaaa:bbbb:cccc:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic valid_lft 86379sec preferred_lft 3579sec inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global dynamic valid_lft 86379sec preferred_lft 3579sec inet6 fe80::5054:ff:fe8b:995d/64 scope link valid_lft forever preferred_lft forever ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.eth0.use_tempaddr = 2 net.ipv6.conf.lo.use_tempaddr = 2 ubuntu@ubuntu:~$ nmcli con status NAME UUID DEVICES DEFAULT VPN MASTER-PATH Wired connection 1 923e6729-74a7-4389-9dbd-43ed7db3d1b8 eth0 yes no -- ubuntu@ubuntu:~$ nmcli dev status DEVICE TYPE STATE eth0 802-3-ethernet connected //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6 ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1 PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes 64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=70.9 ms --- 2a00:1450:4002:800::100e ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 70.994/70.994/70.994/0.000 ms # tcpdump -ni eth0 host 2a00:1450:4002:800::100e 17:57:37.784658 IP6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64 17:57:37.855257 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:ad1f:9166:93d4:fd6d: ICMP6, echo reply, seq 1, length 64 == Step 2. flood RAs on the LAN == $ dmesg | tail [ 1093.642053] IPv6: ipv6_create_tempaddr: retry temporary address regeneration [ 1093.642062] IPv6: ipv6_create_tempaddr: retry temporary address regeneration [ 1093.642065] IPv6: ipv6_create_tempaddr: retry temporary address regeneration [ 1093.642067] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.eth0.use_tempaddr = -1 net.ipv6.conf.lo.use_tempaddr = 2 //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6 ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1 PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes 64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=77.5 ms --- 2a00:1450:4002:800::100e ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 77.568/77.568/77.568/0.000 ms # tcpdump -ni eth0 host 2a00:1450:4002:800::100e 17:59:38.204173 IP6 2001:db8:f00:f00:5054:ff:fe8b:995d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64 17:59:38.281437 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:5054:ff:fe8b:995d: ICMP6, echo reply, seq 1, length 64 //notice the change of IPv6 address to the one not using privacy extensions even after the flooding has finished long ago. == Step 3. Disconnect/Reconnect connection == // restoring net.ipv6.conf.eth0.use_tempaddr to value '2' makes no difference at all for the rest of the process # nmcli dev disconnect iface eth0 # nmcli con up uuid 923e6729-74a7-4389-9dbd-43ed7db3d1b8 ubuntu@ubuntu:~$ ip a ls dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0 inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global tentative dynamic valid_lft 86400sec preferred_lft 3600sec inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global tentative dynamic valid_lft 86400sec preferred_lft 3600sec inet6 fe80::5054:ff:fe8b:995d/64 scope link tentative valid_lft forever preferred_lft forever //Notice the "tentative" flag of the IPs on the device //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6 ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1 PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes ^C --- 2a00:1450:4002:800::100e ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms # tcpdump -ni eth0 host 2a00:1450:4002:800::100e 18:01:45.264194 IP6 ::1 > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64 Summary: Before flooding it uses IP: 2001:db8:f00:f00:ad1f:9166:93d4:fd6d After flooding it uses IP: 2001:db8:f00:f00:5054:ff:fe8b:995d --> it has lost privacy extensions After disconnect/reconnect it tries to use IP: ::1 --> it has lost IPv6 connectivity Best regards, -- George Kargiotakis https://void.gr GPG KeyID: 0xE4F4FFE6 GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses 2012-12-27 15:57 ` George Kargiotakis @ 2012-12-27 16:54 ` Eric Dumazet 2012-12-28 17:19 ` Eric Dumazet 0 siblings, 1 reply; 8+ messages in thread From: Eric Dumazet @ 2012-12-27 16:54 UTC (permalink / raw) To: George Kargiotakis; +Cc: netdev On Thu, 2012-12-27 at 17:57 +0200, George Kargiotakis wrote: > Hello all, > > I had previously informed this list about the issue of the linux kernel > losing IPv6 privacy extensions by a local LAN attacker. > Recently I've found that there's actually another, more serious in my > opinion, issue that follows the previous one. If the user tries to > disconnect/reconnect the network device/connection for whatever reason > (e.g. thinking he might gain back privacy extensions), then the device > gets IPs from SLAAC that have the "tentative" flag and never loses > that. That means that IPv6 functionality for that device is from then > on completely lost. I haven't been able to bring back the kernel to a > working IPv6 state without a reboot. > > This is definitely a DoS situation and it needs fixing. > > Here are the steps to reproduce: > > == Step 1. Boot Ubuntu 12.10 (kernel 3.5.0-17-generic) == > ubuntu@ubuntu:~$ ip a ls dev eth0 > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 > link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff > inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0 > inet6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic > valid_lft 86379sec preferred_lft 3579sec > inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global dynamic > valid_lft 86379sec preferred_lft 3579sec > inet6 fdbb:aaaa:bbbb:cccc:ad1f:9166:93d4:fd6d/64 scope global temporary dynamic > valid_lft 86379sec preferred_lft 3579sec > inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global dynamic > valid_lft 86379sec preferred_lft 3579sec > inet6 fe80::5054:ff:fe8b:995d/64 scope link > valid_lft forever preferred_lft forever > > ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr > net.ipv6.conf.all.use_tempaddr = 2 > net.ipv6.conf.default.use_tempaddr = 2 > net.ipv6.conf.eth0.use_tempaddr = 2 > net.ipv6.conf.lo.use_tempaddr = 2 > > ubuntu@ubuntu:~$ nmcli con status > NAME UUID DEVICES DEFAULT VPN MASTER-PATH > Wired connection 1 923e6729-74a7-4389-9dbd-43ed7db3d1b8 eth0 yes no -- > ubuntu@ubuntu:~$ nmcli dev status > DEVICE TYPE STATE > eth0 802-3-ethernet connected > > //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6 > > ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1 > PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes > 64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=70.9 ms > > --- 2a00:1450:4002:800::100e ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 70.994/70.994/70.994/0.000 ms > > # tcpdump -ni eth0 host 2a00:1450:4002:800::100e > 17:57:37.784658 IP6 2001:db8:f00:f00:ad1f:9166:93d4:fd6d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64 > 17:57:37.855257 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:ad1f:9166:93d4:fd6d: ICMP6, echo reply, seq 1, length 64 > > == Step 2. flood RAs on the LAN == > > $ dmesg | tail > [ 1093.642053] IPv6: ipv6_create_tempaddr: retry temporary address regeneration > [ 1093.642062] IPv6: ipv6_create_tempaddr: retry temporary address regeneration > [ 1093.642065] IPv6: ipv6_create_tempaddr: retry temporary address regeneration > [ 1093.642067] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support > > ubuntu@ubuntu:~$ sysctl -a | grep use_tempaddr > net.ipv6.conf.all.use_tempaddr = 2 > net.ipv6.conf.default.use_tempaddr = 2 > net.ipv6.conf.eth0.use_tempaddr = -1 > net.ipv6.conf.lo.use_tempaddr = 2 > > //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6 > > ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1 > PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes > 64 bytes from 2a00:1450:4002:800::100e: icmp_seq=1 ttl=53 time=77.5 ms > > --- 2a00:1450:4002:800::100e ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 77.568/77.568/77.568/0.000 ms > > # tcpdump -ni eth0 host 2a00:1450:4002:800::100e > 17:59:38.204173 IP6 2001:db8:f00:f00:5054:ff:fe8b:995d > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64 > 17:59:38.281437 IP6 2a00:1450:4002:800::100e > 2001:db8:f00:f00:5054:ff:fe8b:995d: ICMP6, echo reply, seq 1, length 64 > > //notice the change of IPv6 address to the one not using privacy extensions even after the flooding has finished long ago. > > == Step 3. Disconnect/Reconnect connection == > // restoring net.ipv6.conf.eth0.use_tempaddr to value '2' makes no difference at all for the rest of the process > > # nmcli dev disconnect iface eth0 > # nmcli con up uuid 923e6729-74a7-4389-9dbd-43ed7db3d1b8 > > ubuntu@ubuntu:~$ ip a ls dev eth0 > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 > link/ether 52:54:00:8b:99:5d brd ff:ff:ff:ff:ff:ff > inet 192.168.1.96/24 brd 192.168.1.255 scope global eth0 > inet6 2001:db8:f00:f00:5054:ff:fe8b:995d/64 scope global tentative dynamic > valid_lft 86400sec preferred_lft 3600sec > inet6 fdbb:aaaa:bbbb:cccc:5054:ff:fe8b:995d/64 scope global tentative dynamic > valid_lft 86400sec preferred_lft 3600sec > inet6 fe80::5054:ff:fe8b:995d/64 scope link tentative > valid_lft forever preferred_lft forever > > //Notice the "tentative" flag of the IPs on the device > > //ping6 2a00:1450:4002:800::100e while in another terminal: tcpdump -ni eth0 ip6 > > ubuntu@ubuntu:~$ ping6 2a00:1450:4002:800::100e -c1 > PING 2a00:1450:4002:800::100e(2a00:1450:4002:800::100e) 56 data bytes > ^C > --- 2a00:1450:4002:800::100e ping statistics --- > 1 packets transmitted, 0 received, 100% packet loss, time 0ms > > # tcpdump -ni eth0 host 2a00:1450:4002:800::100e > 18:01:45.264194 IP6 ::1 > 2a00:1450:4002:800::100e: ICMP6, echo request, seq 1, length 64 > > Summary: > Before flooding it uses IP: 2001:db8:f00:f00:ad1f:9166:93d4:fd6d > After flooding it uses IP: 2001:db8:f00:f00:5054:ff:fe8b:995d --> it has lost privacy extensions > After disconnect/reconnect it tries to use IP: ::1 --> it has lost IPv6 connectivity > > Best regards, We should only rate limit, and not disable forever. If I cook a patch, are you willing to compile a kernel and test it ? Thanks ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux kernel handling of IPv6 temporary addresses 2012-12-27 16:54 ` Eric Dumazet @ 2012-12-28 17:19 ` Eric Dumazet 0 siblings, 0 replies; 8+ messages in thread From: Eric Dumazet @ 2012-12-28 17:19 UTC (permalink / raw) To: George Kargiotakis; +Cc: netdev On Thu, 2012-12-27 at 08:54 -0800, Eric Dumazet wrote: > We should only rate limit, and not disable forever. > Something like : diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index dd52d51..32d51e2 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1282,7 +1282,7 @@ max_desync_factor - INTEGER Default: 600 regen_max_retry - INTEGER - Number of attempts before give up attempting to generate + Number of attempts per second before give up attempting to generate valid temporary addresses. Default: 5 diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h index 9356322..8f206cf 100644 --- a/include/net/if_inet6.h +++ b/include/net/if_inet6.h @@ -70,6 +70,7 @@ struct inet6_ifaddr { struct list_head tmp_list; struct inet6_ifaddr *ifpub; int regen_count; + u32 regen_stamp; #endif struct rcu_head rcu; }; diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 408cac4a..c41925c 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -980,6 +980,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i int max_addresses; u32 addr_flags; unsigned long now = jiffies; + u32 stamp; write_lock(&idev->lock); if (ift) { @@ -994,18 +995,22 @@ retry: in6_dev_hold(idev); if (idev->cnf.use_tempaddr <= 0) { write_unlock(&idev->lock); - pr_info("%s: use_tempaddr is disabled\n", __func__); + pr_info_ratelimited("%s: use_tempaddr is disabled\n", __func__); in6_dev_put(idev); ret = -1; goto out; } spin_lock_bh(&ifp->lock); + stamp = jiffies / HZ; + if (stamp != ifp->regen_stamp) { + ifp->regen_stamp = stamp; + ifp->regen_count = 0; + } if (ifp->regen_count++ >= idev->cnf.regen_max_retry) { - idev->cnf.use_tempaddr = -1; /*XXX*/ spin_unlock_bh(&ifp->lock); write_unlock(&idev->lock); - pr_warn("%s: regeneration time exceeded - disabled temporary address support\n", - __func__); + pr_warn_ratelimited("%s: regeneration time exceeded - disabled temporary address support\n", + __func__); in6_dev_put(idev); ret = -1; goto out; ^ permalink raw reply related [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-12-28 17:19 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-14 21:14 Linux kernel handling of IPv6 temporary addresses George Kargiotakis 2012-11-14 21:29 ` David Miller 2012-11-14 23:03 ` George Kargiotakis 2012-11-14 23:08 ` David Miller 2012-11-16 21:27 ` Ben Hutchings 2012-12-27 15:57 ` George Kargiotakis 2012-12-27 16:54 ` Eric Dumazet 2012-12-28 17:19 ` Eric Dumazet
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox