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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 17 Mar 2010 18:32:53 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH] xfrm: cache bundle lookup results in flow cache

Timo Teräs wrote:
>>> Also. With this and your recent flowi patch, I'm seeing pmtu
>>> issues. Seems like xfrm_bundle_ok uses the original dst which
>>> resulted in the creation of the bundle. Somehow that dst
>>> does not get updated with pmtu... but the new dst used in
>>> next xfrm_lookup for same target does have proper mtu.
>>> I'm debugging right now why this is happening. Any ideas?
>>
>> The dynamic MTU is always maintained in a normal dst object in
>> the IPv4 routing cache.  Each xfrm_dst points to such a dst
>> through xdst->route.
>>
>> If you were looking at the xfrm_dst's own MTU then that may well
>> cause problems.
> 
> I figured the root cause. The original dst gets expired
> rt_genid goes old. But xfrm_dst does not notice that so it
> won't create a new bundle. xfrm_bundle_ok calls dst_check,
> but dst->obsolete = 0, and ipv4_dst_check is a no-op anyway.
> 
> Somehow the rtable object should be able to tell back to
> xfrm that the dst is not good anymore. Any ideas?

Checked ipv6, it does like xfrm: sets obsolote to -1 and
on dst_check checks the genid. We need to do same in for
ipv4. I just wrote an hack, and tested it. It solves the
pmtu issues.

I will post a proper patch soon.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ