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: Wed, 9 Apr 2014 12:17:33 +0400 From: "Ilya V. Matveychikov" <i.matveychikov@...uritycode.ru> To: Hannes Frederic Sowa <hannes@...essinduktion.org> CC: <netdev@...r.kernel.org> Subject: Re: question: update_pmtu doesn't update dst mtu On 08.04.2014 18:57, Hannes Frederic Sowa wrote: > 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?). > Well, I missed it. Also, that was a hack and it's not the best solution... >> ... >> // 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); > Works fine, thanks! By the way, could you briefly explain why routes are separated to input and output? What are the benefits? > This should be a very unlikely path, I assume, so should not degrade > performance that much. Sure. > > I wonder why you update the mtu in the output path. Well, the problem is that I don't know how to properly handle packets whose DSTs have changed while processing. The simple solution is to drop them. But I think it's not the best case as we can re-fragment them if new MTU value is lesser than the older one. -- 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