Re: more on PMTU issues

From: Eric Dumazet <[EMAIL PROTECTED]> Date: Thu, 01 Dec 2005 21:45:59 +0100 > I wonder if it's possible for an application receiving / sending UDP > frames to many different peers to ask to not add entries to > hostcache ? (ie routecache isnt it ?) Currently, UDP doesn't explicitly update the PM

Re: more on PMTU issues

From: John Heffner <[EMAIL PROTECTED]> Date: Thu, 01 Dec 2005 11:53:44 -0500 > . > > When implementing additional validity checks at a protocol above IP, > these checks are useless if it just uses a cached value from another > pr

Re: more on PMTU issues

On Thu, 01 Dec 2005 12:35:30 -0800 (PST) "David S. Miller" <[EMAIL PROTECTED]> wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Thu, 1 Dec 2005 09:46:22 -0800 > > > Also, there a related IETF draft about ICMP that discusses an number of PMTU > > related issues. > > > > http://www

Re: more on PMTU issues

David S. Miller a écrit : This gives further credence to BSD's hostcache which makes it use PMTU metrics only learned by TCP. I still dislike the reduced granularity of such a scheme, since as we all know ipsec routes can have wildly different metrics and can be keyed by things like port number

Re: more on PMTU issues

From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 1 Dec 2005 09:46:22 -0800 > Also, there a related IETF draft about ICMP that discusses an number of PMTU > related issues. > > http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-05.txt > which has generated lots of discuss

Re: more on PMTU issues

From: John Heffner <[EMAIL PROTECTED]> Date: Thu, 01 Dec 2005 11:53:44 -0500 > Yes it does, and arguably correctly so. As I see it this really comes > down to a question of cached metrics scope. I had a discussion recently > about this with Fernando Gont. See the thread "Improvement for the

Re: more on PMTU issues

From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 01 Dec 2005 23:21:26 +1100 > You could then say > > dst = dst->ops->cow(dst, flow); > dst->update_pmtu(dst, mtu); > > You can also store the returned dst in the socket. I think this is > worthwhile since receiving an PMTU message is usually follow

Re: more on PMTU issues

On Thu, 01 Dec 2005 11:53:44 -0500 John Heffner <[EMAIL PROTECTED]> wrote: > David S. Miller wrote: > > After talking the IPV6 PMTU situation over with Herbert > > this afternoon, we discovered that IPV4 has the same > > problem :-) > > Yes it does, and arguably correctly so. As I see it this re

Re: more on PMTU issues

David S. Miller wrote: After talking the IPV6 PMTU situation over with Herbert this afternoon, we discovered that IPV4 has the same problem :-) Yes it does, and arguably correctly so. As I see it this really comes down to a question of cached metrics scope. I had a discussion recently about

Re: more on PMTU issues

David S. Miller <[EMAIL PROTECTED]> wrote: > > One idea is to pass in a "const struct flowi *flp" into the > dst->ops->update_pmtu() handler which has the src/dest address fields > filled in. I did code something like that up, then threw it away, but > such a simple change is easily rematerializa

more on PMTU issues

After talking the IPV6 PMTU situation over with Herbert this afternoon, we discovered that IPV4 has the same problem :-) It calls ip_rt_frag_needed() unconditionally from net/ipv4/icmp.c:icmp_unreach(), which makes all of the verifications done by TCP (sequence number checks etc.) basically for n