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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 8 Apr 2014 16:57:19 +0200 From: Hannes Frederic Sowa <hannes@...essinduktion.org> To: "Ilya V. Matveychikov" <i.matveychikov@...uritycode.ru> Cc: netdev@...r.kernel.org Subject: Re: question: update_pmtu doesn't update dst mtu On Tue, Apr 08, 2014 at 01:03:43PM +0400, Ilya V. Matveychikov wrote: > Just another related question that gets me into trouble. Imagine that there is > an SKB that wants to be transmitted via that tunnel. Let's say that when it > comes to the TUNNEL device it has an MTU1 value. Now, someone updates the PMTU > for the route and mtu decreasing from MTU1 to MTU2, so MTU2 < MTU1. > > Given that, I suppose that our SKB must be (re)fragmented with ip_fragment as > it's size might be slightly bigger then the path can pass. The problem is that > ip_fragment uses dst_mtu(skb_dst(skb)) to determine the fragment size but it > still has MTU1 value as even update_pmtu(MTU2) was called as it doesn't leads to > real dst MTU updating. > > So the question is do I need to relookup the route or can I use the following > hack before ip_fragment: > > // dst_mtu(dst) shows MTU1 > dst->ops->update_pmtu(dst, ..., MTU2) > ... > skb_rtable(skb)->rt_pmtu = MTU2; This might be a cached dst and you would alter the mtu for more nexthops than you intended. > dst_set_expires(dst, 1); With this you won't get around the time_after_eq check. You would have to tweak it manually to not retrieve dst_metrics value (this is what you intended?). > ... > // now, ip_fragment knows about real MTU value > ip_fragment(skb, output...) Check if you can something do like skb_dst_drop(skb); new_dst = ip_route_output*(..., &fl4, ...); skb_dst_set(_noref)(skb, new_dst); This should be a very unlikely path, I assume, so should not degrade performance that much. I wonder why you update the mtu in the output path. Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists