cache forver in 3.2.0-rc2-00400-g866d43c ?

Hello,

I'm using  my notebook in two different networks, suspending and resuming from 
ram between.

Network A (192.168.1.0/24) has server with IP 87.204.99.133 in the same lan. 
Now when I suspend, go to totally different network B (different provider, 
different lan, 192.168.0.0/24) and resume then I'm unable to connect to 
87.204.99.133.

Looks like network stack thinks that 87...133 is still directly reachable on 
eth1and I'm unable to make it forget that.

[root@t400 ~]# ip ne flush dev eth1; ip r flush table cache
[root@t400 ~]# ip r show table cache to 87.204.99.133
[root@t400 ~]# ping -c 1 87.204.99.133
PING 87.204.99.133 (87.204.99.133) 56(84) bytes of data.
From 192.168.0.5: icmp_seq=1 Destination Host Unreachable

--- 87.204.99.133 ping statistics ---

1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

zsh: exit 1     ping -c 1 87.204.99.133
[root@t400 ~]# ip r show table cache to 87.204.99.133
87.204.99.133 dev eth1  src 192.168.0.5
    cache <redirected>  ipid 0x2838 rtt 17ms rttvar 12ms cwnd 10
87.204.99.133 from 192.168.0.5 dev eth1
    cache <redirected>  ipid 0x2838 rtt 17ms rttvar 12ms cwnd 10
[root@t400 ~]# ip ne show to 87.204.99.133
87.204.99.133 dev eth1  FAILED

tcpdump in meantime sees this:
19:06:26.907153 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
87.204.99.133 tell 192.168.0.5, length 28
19:06:27.908379 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
87.204.99.133 tell 192.168.0.5, length 28
19:06:28.907084 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
87.204.99.133 tell 192.168.0.5, length 28
19:06:29.907145 IP (tos 0xc0, ttl 64, id 34465, offset 0, flags [none], proto 
ICMP (1), length 112)
    192.168.0.5 > 192.168.0.5: ICMP host 87.204.99.133 unreachable, length 92
        IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), 
length 84)
    192.168.0.5 > 87.204.99.133: ICMP echo request, id 17590, seq 1, length 64

Any ideas?

Thanks,
-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Le mercredi 23 novembre 2011 à 19:10 +0100, Arkadiusz Miśkiewicz a
écrit :

Hmm, could you check you have this fix in your tree ?

http://git2.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=9cc20b268a5a14f5e57b8ad405a83513ab0d78dc

On Wednesday 23 of November 2011, Eric Dumazet wrote:

Le mercredi 23 novembre 2011 à 19:10 +0100, Arkadiusz Miśkiewicz a

écrit :

quoted

Hello,

I'm using  my notebook in two different networks, suspending and resuming
from ram between.

Network A (192.168.1.0/24) has server with IP 87.204.99.133 in the same
lan. Now when I suspend, go to totally different network B (different
provider, different lan, 192.168.0.0/24) and resume then I'm unable to
connect to 87.204.99.133.

Looks like network stack thinks that 87...133 is still directly reachable
on eth1and I'm unable to make it forget that.

[root@t400 ~]# ip ne flush dev eth1; ip r flush table cache
[root@t400 ~]# ip r show table cache to 87.204.99.133
[root@t400 ~]# ping -c 1 87.204.99.133
PING 87.204.99.133 (87.204.99.133) 56(84) bytes of data.
From 192.168.0.5: icmp_seq=1 Destination Host Unreachable

--- 87.204.99.133 ping statistics ---

1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

zsh: exit 1     ping -c 1 87.204.99.133
[root@t400 ~]# ip r show table cache to 87.204.99.133
87.204.99.133 dev eth1  src 192.168.0.5

    cache <redirected>  ipid 0x2838 rtt 17ms rttvar 12ms cwnd 10

87.204.99.133 from 192.168.0.5 dev eth1

    cache <redirected>  ipid 0x2838 rtt 17ms rttvar 12ms cwnd 10

[root@t400 ~]# ip ne show to 87.204.99.133
87.204.99.133 dev eth1  FAILED

tcpdump in meantime sees this:
19:06:26.907153 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
87.204.99.133 tell 192.168.0.5, length 28
19:06:27.908379 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
87.204.99.133 tell 192.168.0.5, length 28
19:06:28.907084 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
87.204.99.133 tell 192.168.0.5, length 28
19:06:29.907145 IP (tos 0xc0, ttl 64, id 34465, offset 0, flags [none],
proto ICMP (1), length 112)

    192.168.0.5 > 192.168.0.5: ICMP host 87.204.99.133 unreachable,
    length 92
    
        IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1),

length 84)

    192.168.0.5 > 87.204.99.133: ICMP echo request, id 17590, seq 1,
    length 64

Any ideas?

Thanks,

Hmm, could you check you have this fix in your tree ?

http://git2.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=9cc20b2
68a5a14f5e57b8ad405a83513ab0d78dc

Mine 00400-g866d43c was after 6fe4c6d466e95d31164f14b1ac4aefb51f0f4f82 (which 
is merge of ipv4: fix redirect handling), so I have it.

(I'm using pure linus git repo)
-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Le mercredi 23 novembre 2011 à 19:31 +0100, Arkadiusz Miśkiewicz a
écrit :

Mine 00400-g866d43c was after 6fe4c6d466e95d31164f14b1ac4aefb51f0f4f82 (which 
is merge of ipv4: fix redirect handling), so I have it.

(I'm using pure linus git repo)

OK thanks for this information, I am working on a patch.

Le mercredi 23 novembre 2011 à 19:37 +0100, Eric Dumazet a écrit :

Le mercredi 23 novembre 2011 à 19:31 +0100, Arkadiusz Miśkiewicz a
écrit :

quoted

Mine 00400-g866d43c was after 6fe4c6d466e95d31164f14b1ac4aefb51f0f4f82 (which 
is merge of ipv4: fix redirect handling), so I have it.

(I'm using pure linus git repo)

OK thanks for this information, I am working on a patch.

Please test the following patch, thanks !

 include/net/inetpeer.h |    1 +
 net/ipv4/route.c       |   10 +++++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
index 78c83e6..e9ff3fc 100644
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h

@@ -35,6 +35,7 @@ struct inet_peer {
 
 	u32			metrics[RTAX_MAX];
 	u32			rate_tokens;	/* rate limiting for ICMP */
+	int			redirect_genid;
 	unsigned long		rate_last;
 	unsigned long		pmtu_expires;
 	u32			pmtu_orig;

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 0c74da8..be8643da 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c

@@ -131,6 +131,7 @@ static int ip_rt_mtu_expires __read_mostly	= 10 * 60 * HZ;
 static int ip_rt_min_pmtu __read_mostly		= 512 + 20 + 20;
 static int ip_rt_min_advmss __read_mostly	= 256;
 static int rt_chain_length_max __read_mostly	= 20;
+static int redirect_genid;
 
 /*
  *	Interface to generic destination cache.

@@ -837,6 +838,7 @@ static void rt_cache_invalidate(struct net *net)
 
 	get_random_bytes(&shuffle, sizeof(shuffle));
 	atomic_add(shuffle + 1U, &net->ipv4.rt_genid);
+	redirect_genid++;
 }
 
 /*

@@ -1391,8 +1393,10 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
 
 				peer = rt->peer;
 				if (peer) {
-					if (peer->redirect_learned.a4 != new_gw) {
+					if (peer->redirect_learned.a4 != new_gw ||
+					    peer->redirect_genid != redirect_genid) {
 						peer->redirect_learned.a4 = new_gw;
+						peer->redirect_genid = redirect_genid;
 						atomic_inc(&__rt_peer_genid);
 					}
 					check_peer_redir(&rt->dst, peer);

@@ -1701,6 +1705,8 @@ static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
 		if (peer) {
 			check_peer_pmtu(dst, peer);
 
+			if (peer->redirect_genid != redirect_genid)
+				peer->redirect_learned.a4 = 0;
 			if (peer->redirect_learned.a4 &&
 			    peer->redirect_learned.a4 != rt->rt_gateway) {
 				if (check_peer_redir(dst, peer))

@@ -1852,6 +1858,8 @@ static void rt_init_metrics(struct rtable *rt, const struct flowi4 *fl4,
 		dst_init_metrics(&rt->dst, peer->metrics, false);
 
 		check_peer_pmtu(&rt->dst, peer);
+		if (peer->redirect_genid != redirect_genid)
+			peer->redirect_learned.a4 = 0;
 		if (peer->redirect_learned.a4 &&
 		    peer->redirect_learned.a4 != rt->rt_gateway) {
 			rt->rt_gateway = peer->redirect_learned.a4;

On Wednesday 23 of November 2011, Eric Dumazet wrote:

Le mercredi 23 novembre 2011 à 19:37 +0100, Eric Dumazet a écrit :

quoted

Le mercredi 23 novembre 2011 à 19:31 +0100, Arkadiusz Miśkiewicz a

écrit :

quoted

Mine 00400-g866d43c was after 6fe4c6d466e95d31164f14b1ac4aefb51f0f4f82
(which is merge of ipv4: fix redirect handling), so I have it.

(I'm using pure linus git repo)

OK thanks for this information, I am working on a patch.

Please test the following patch, thanks !

Applied and running, results in a few days (since using net A only once per 
day).

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

On Wednesday 23 of November 2011, Arkadiusz Miśkiewicz wrote:

On Wednesday 23 of November 2011, Eric Dumazet wrote:

quoted

Le mercredi 23 novembre 2011 à 19:37 +0100, Eric Dumazet a écrit :

quoted

Le mercredi 23 novembre 2011 à 19:31 +0100, Arkadiusz Miśkiewicz a

écrit :

quoted

Mine 00400-g866d43c was after
6fe4c6d466e95d31164f14b1ac4aefb51f0f4f82 (which is merge of ipv4:
fix redirect handling), so I have it.

(I'm using pure linus git repo)

OK thanks for this information, I am working on a patch.

Please test the following patch, thanks !

Applied and running, results in a few days (since using net A only once per
day).

Two days and no problems. More tests possible in next week.

Thanks!
-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Le vendredi 25 novembre 2011 à 18:53 +0100, Arkadiusz Miśkiewicz a 

Two days and no problems. More tests possible in next week.

Thanks!

Thansk to you, I'll send official submission in a couple of minutes
then.

Now inetpeer is the place where we cache redirect information for ipv4
destinations, we must be able to invalidate informations when a route is
added/removed on host.

As inetpeer is not yet namespace aware, this patch adds a shared
redirect_genid, and a per inetpeer redirect_genid. This might be changed
later if inetpeer becomes ns aware.

Cache information for one inerpeer is valid as long as its
redirect_genid has the same value than global redirect_genid.

Reported-by: Arkadiusz Miśkiewicz <redacted>
Tested-by: Arkadiusz Miśkiewicz <redacted>
Signed-off-by: Eric Dumazet <redacted>
---
 include/net/inetpeer.h |    1 +
 net/ipv4/route.c       |   10 +++++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
index 78c83e6..e9ff3fc 100644
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h

@@ -35,6 +35,7 @@ struct inet_peer {
 
 	u32			metrics[RTAX_MAX];
 	u32			rate_tokens;	/* rate limiting for ICMP */
+	int			redirect_genid;
 	unsigned long		rate_last;
 	unsigned long		pmtu_expires;
 	u32			pmtu_orig;

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index fb47c8f..5c28472 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c

@@ -131,6 +131,7 @@ static int ip_rt_mtu_expires __read_mostly	= 10 * 60 * HZ;
 static int ip_rt_min_pmtu __read_mostly		= 512 + 20 + 20;
 static int ip_rt_min_advmss __read_mostly	= 256;
 static int rt_chain_length_max __read_mostly	= 20;
+static int redirect_genid;
 
 /*
  *	Interface to generic destination cache.

@@ -837,6 +838,7 @@ static void rt_cache_invalidate(struct net *net)
 
 	get_random_bytes(&shuffle, sizeof(shuffle));
 	atomic_add(shuffle + 1U, &net->ipv4.rt_genid);
+	redirect_genid++;
 }
 
 /*

@@ -1391,8 +1393,10 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
 
 				peer = rt->peer;
 				if (peer) {
-					if (peer->redirect_learned.a4 != new_gw) {
+					if (peer->redirect_learned.a4 != new_gw ||
+					    peer->redirect_genid != redirect_genid) {
 						peer->redirect_learned.a4 = new_gw;
+						peer->redirect_genid = redirect_genid;
 						atomic_inc(&__rt_peer_genid);
 					}
 					check_peer_redir(&rt->dst, peer);

@@ -1701,6 +1705,8 @@ static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
 		if (peer) {
 			check_peer_pmtu(dst, peer);
 
+			if (peer->redirect_genid != redirect_genid)
+				peer->redirect_learned.a4 = 0;
 			if (peer->redirect_learned.a4 &&
 			    peer->redirect_learned.a4 != rt->rt_gateway) {
 				if (check_peer_redir(dst, peer))

@@ -1857,6 +1863,8 @@ static void rt_init_metrics(struct rtable *rt, const struct flowi4 *fl4,
 		dst_init_metrics(&rt->dst, peer->metrics, false);
 
 		check_peer_pmtu(&rt->dst, peer);
+		if (peer->redirect_genid != redirect_genid)
+			peer->redirect_learned.a4 = 0;
 		if (peer->redirect_learned.a4 &&
 		    peer->redirect_learned.a4 != rt->rt_gateway) {
 			rt->rt_gateway = peer->redirect_learned.a4;

Le samedi 26 novembre 2011 à 23:13 +0100, Eric Dumazet a écrit :

Now inetpeer is the place where we cache redirect information for ipv4
destinations, we must be able to invalidate informations when a route is
added/removed on host.

As inetpeer is not yet namespace aware, this patch adds a shared
redirect_genid, and a per inetpeer redirect_genid. This might be changed
later if inetpeer becomes ns aware.

Cache information for one inerpeer is valid as long as its
redirect_genid has the same value than global redirect_genid.

Reported-by: Arkadiusz Miśkiewicz <redacted>
Tested-by: Arkadiusz Miśkiewicz <redacted>
Signed-off-by: Eric Dumazet <redacted>
---

Arg, patch title was not complete, it could be :

[PATCH] inet: add a redirect generation id in inetpeer

Sorry :(

From: Eric Dumazet <redacted>
Date: Sat, 26 Nov 2011 23:16:30 +0100

Le samedi 26 novembre 2011 à 23:13 +0100, Eric Dumazet a écrit :

quoted

Now inetpeer is the place where we cache redirect information for ipv4
destinations, we must be able to invalidate informations when a route is
added/removed on host.

As inetpeer is not yet namespace aware, this patch adds a shared
redirect_genid, and a per inetpeer redirect_genid. This might be changed
later if inetpeer becomes ns aware.

Cache information for one inerpeer is valid as long as its
redirect_genid has the same value than global redirect_genid.

Reported-by: Arkadiusz Miśkiewicz <redacted>
Tested-by: Arkadiusz Miśkiewicz <redacted>
Signed-off-by: Eric Dumazet <redacted>
---

Arg, patch title was not complete, it could be :

[PATCH] inet: add a redirect generation id in inetpeer

It happens :-)  Applied, thanks Eric.