+++ This bug was initially created as a clone of Bug #622782 +++

Description of problem:
iproute 2.6.35 loses routing to the other end of a PPP link.

After bringing up a PPP VPN link with 2.6.34-5, the routing table looks like:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.173.32.21   192.168.2.1     255.255.255.255 UGH       0 0          0 wlan0
128.173.32.21   0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
198.82.0.0      0.0.0.0         255.255.0.0     U         0 0          0 ppp0
128.173.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ppp0
0.0.0.0         192.168.2.1     0.0.0.0         UG        0 0          0 wlan0

Everything goes out wlan0, except for the 2 /16's at work, which get routed across the ppp0 link instead.  Those packets get encapsulated and sent via wlan0 to the other end of the ppp0 link, and everything is good.

Upgrading to 2.6.35-1 I get this instead:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.173.32.21   0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
198.82.0.0      0.0.0.0         255.255.0.0     U         0 0          0 ppp0
128.173.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ppp0
0.0.0.0         192.168.2.1     0.0.0.0         UG        0 0          0 wlan0

The route to 128.173.32.21 via wlan0 is gone. As a result, any attempt to send a packet out the ppp0 interface to the 2 destination /16s results in a routing loop - the encapsulated packets for the other end of the ppp0 loop get enqueued for the ppp0 link not wlan0.  And since it's an encapsulated packet, each time around it starts off with a new packet TTL so looping packets don't expire, they just get bigger (after a few seconds, watching with 'tcpdump' gets painful as each packet takes 50-60 lines to display). Backing off to  iproute-2.6.34-5 and changing nothing else makes it start working again.


Version-Release number of selected component (if applicable):
iproute-2.6.35-1.fc14.x86_64

--- Additional comment from Petr Šabata on 2010-08-17 08:36:32 EDT ---

Valdis,

I assume you're running 2.6.35 kernel.
Can you reproduce this issue with the following build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=2406749

Also, I'd like to ask:

How do you configure your routing table?
Could you post the steps or attach the script you use?

Thank you.

--- Additional comment from Valdis Kletnieks on 2010-08-17 09:33:40 EDT ---

Confirming the 2.6.35-2 build works. Looks like iproute2-2.6.35-routing.patch was the fix for my issue.

The routing table entries were created thusly:

pppd call vt-ipv6
sleep 4
ip route add '128.173.0.0/16' dev 'ppp0'
ip route add '198.82.0.0/16' dev 'ppp0'

so the failing entry was created by pppd.

--- Additional comment from Phil Sutter on 2015-11-23 14:22:50 EST ---

The patch allegedly fixing the described issue has been rejected upstream. Policy forbids us to ship this change then. On the other hand, I really don't see how this change could influence the described behaviour at all. It touches code which is used exclusively for printing the routing table, and it affects IPv6 only.

Note that the patch has already been removed from Rawhide and Fedora23 prior to it's release. If you see the problem again with Fedora23, feel free to reopen this ticket and we'll find the real solution.