lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <4F44B48B.70504@wakoond.hu> Date: Wed, 22 Feb 2012 10:25:31 +0100 From: "Takács András" <wakoond@...il.com> To: netdev@...r.kernel.org Subject: ip6ip6 tunnel routing issue Dear All, We're using Mobile IPv6 for vehicle communication, and we have found a very annoying issue in IPv6 routing. We're running kernel 2.6.35.14, but we think, that the problem still exists in the latest kernel tree also. The description of the problem: Mobile IPv6 implementation in Linux is using different metric values for each Care-of Addresses, when creates or modifies default routes. This cause, that all of the packets are goes out on the interface which has lowest metric value, independently from the tunnel interface. In practice it cause that the packets which are routed into ip6tnl2 are goes out on eth1, instead of the setup, which binds ip6tnl2 to eth2. I have attached a test script, which reproduces the problem, without Mobile IPv6. The init argument initializes the environment. I have tried to find the problem in the kernel source. I found the followings: In the find_rr_leaf function (net/ipv6/route.c) the iteration goes until the metric is equal to the specified one. If you look the calling environment, you should see, that this metric value is the metric of the first route info entry: http://pastebin.com/XfALRrrY We have two totally same route entries, where only the interfaces and the metric values are different: default via fe80::20c:29ff:fe3b:4d16 dev eth1 proto ra metric 1023 mtu 1500 advmss 1440 hoplimit 0 default via fe80::20c:29ff:fe3b:4d20 dev eth2 proto ra metric 1053 mtu 1500 advmss 1440 hoplimit 0 In this case, the above loop, will call find_match only once, for eth1. If it happens, the find_match function, couldn't find eth2, which belongs to ip6tnl2, and returns with eth1. Unfortunately, the (IPv6) routing mechanism in quite complex in the kernel. I could find only a very ugly workaround for our problem: The attached patch, introduces a new route lookup flag: RT6_LOOKUP_F_IP6TUNNEL. It is passed step-by-step to find_rr_leaf, and it will ignore the metric condition in the loop, if this flag has been enabled. The ip6ip6-metric-fix.patch contains the fix for 2.6.35.14. We had to edit the definition of ip6_route_output. Because of this, the ip6ip6-metric-stuff.patch contains the modification of calling this at any other occurrences. What is your opinion about this problem? What do you think about this workaround? Could anybody help to us to find a more elegant solution for this issue? Best Regards, András Takács View attachment "ip6ip6-metric-fix.patch" of type "text/plain" (5868 bytes) View attachment "ip6ip6-metric-stuff.patch" of type "text/plain" (8462 bytes) Download attachment "test-ip6-tnls.sh" of type "application/x-sh" (5196 bytes)
Powered by blists - more mailing lists