Bug 758701

Summary:	Routing cache table contains bogus entries after switching network
Product:	[Fedora] Fedora	Reporter:	Andreas Wolf <awolf+redhat>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, nhorman
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-09 16:16:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Andreas Wolf 2011-11-30 14:08:45 UTC

Description of problem:

When using cabled network at work and reconnecting to my home network after suspend, the routing cache contains some bogus entries. The routing table (output of "route"/"ip route show") is ok, but some IPs are not ping-able. When calling "ip route get <IP>" for one of these, it shows the gateway of the old network; the source IP is my new one. The non-working IPs seem to be those that were contacted regularly on the old network (e.g. Google or my mail server).

It is not possible to get rid of these entries by setting a new route with "ip route add <IP> gw <my home gw>". Flushing the route table does not help, neither does restarting Network Manager.

This problem started appearing with kernel 3.1.x. I have recently updated from F15 to F16, but I don't know if 2.6.40/3.0.0 also had this problem (I didn't use it very often due to the power management problems on Intel-based laptops). Kernel 2.6.38 (from F15) does not show this behaviour.

Version-Release number of selected component (if applicable):

Kernel version 3.1.2-1.fc16

How reproducible:

I heard from other people who have the same problem, though not on Fedora. As they experienced it also with older kernel versions, their problem might be unrelated to this one.

Steps to Reproduce:
(presumably)
1. Connect to a network
2. Suspend, wake up and connect to another network
3. Try to ping or otherwise connect to a host that was contacted on the "old" network.

Actual results:

Network connections to some IPs do not work.

Expected results:

Hosts are not reachable.

Comment 1 Neil Horman 2011-11-30 14:23:58 UTC

Does the problem occur if you disconnect the cable or issue a disconnect in networkmanager prior to suspending?  I wonder if the problem is that NetworkManager is not getting notifications about network state changing

Comment 2 Andreas Wolf 2011-12-01 17:48:43 UTC

Nope, the problem persists after disconnecting the wired network while running and connecting to wifi afterwards.

This is an example of what I got after doing the network switch:

$ ip route get 88.198.63.xx
88.198.63.xx via 129.13.238.xx dev wlan0  src 141.3.220.xx
    cache <redirected>  ipid 0x05b4 rtt 28ms rttvar 20ms cwnd 10

[this is apparently broken]

$ ip route get 129.13.238.yy
129.13.238.yy via 141.3.208.xx dev wlan0  src 141.3.220.xx 
    cache  ipid 0x4f0e

[this works]


This setup is a different case than what I originally described - I connected to a wifi network on campus here, so both networks belong to my university network, though they are in different subnets and VLANs, so this should not really make a difference.

Comment 3 Andreas Wolf 2011-12-01 18:50:25 UTC

Disconnecting the wired network in Network Manager first and then disconnecting the cable does not help either.

"ip -s route show cache" shows quite some entries for different IPs. I can't see a pattern, except that most of the IPs seem to have been used shortly before suspending. Some others, like e.g. bugzilla.redhat.com, do not appear however.

Comment 4 Andreas Wolf 2011-12-17 15:41:14 UTC

FYI, this problem seems to be fixed with the most recent Fedora kernel (3.1.5-2.fc16.x86_64 according to `uname -r`).

I will further monitor this and close the report if the problem is really fixed.

Comment 5 Neil Horman 2012-03-09 16:16:57 UTC

no report in 3 months, closing