netdev - Re: question: update_pmtu doesn't update dst mtu

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Apr 2014 13:03:43 +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 03.04.2014 16:27, Ilya V. Matveychikov wrote:
> On 03.04.2014 16:14, Hannes Frederic Sowa wrote:
>> On Thu, Apr 03, 2014 at 04:07:21PM +0400, Ilya V. Matveychikov wrote:
>>> On 03.04.2014 15:58, Hannes Frederic Sowa wrote:
>>>> On Thu, Apr 03, 2014 at 03:37:33PM +0400, Ilya V. Matveychikov wrote:
>>>>> Looking through the code gives me that rt_pmtu is always 0 for the skb->dst
>>>>> entry and ipv4_mtu that called via the dst->ops->mtu() uses dev->mtu :(
>>>>
>>>> At this point you have to drop skb_dst and have to relookup the route. During
>>>> that a new dst will be created which gets the mtu value from the next hop
>>>> exception, which got created by update_pmtu.
>>>>
>>>> Normally routes are checked with dst_check if they are still valid
>>>> and a relookup should happen. In your example just do the relookup
>>>> unconditionally.
>>>>
>>>
>>> Does it mean that the next packet must have an updated route without any
>>> problems? I meant that if the first packet xmitting leads to updating the route
>>> PMTU via the exception creating (or updating) so the next packets must have an
>>> updated route? Am I right?
>>
>> In case the next packet causes a lookup in the routing table, yes. Or
>> if it does cache the routing lookup in some structure and checks the
>> route with dst_check and conditionally does a relookup (which kernel
>> implementation should already do) then you should also get the updated
>> mtu value.
>>
> 
> OK, seems that I understand the logic. Thanks a lot.

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;
	dst_set_expires(dst, 1);
	...
	// now, ip_fragment knows about real MTU value
	ip_fragment(skb, output...)

--
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