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 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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.
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.
iproute-2.6.35-2.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/iproute-2.6.35-2.fc14
iproute-2.6.35-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update iproute'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/iproute-2.6.35-2.fc14
iproute-2.6.35-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
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.