[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150518225043.GA25702@gondor.apana.org.au>
Date: Tue, 19 May 2015 06:50:44 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Florian Westphal <fw@...len.de>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
hannes@...essinduktion.org, edumazet@...gle.com
Subject: Re: [PATCH -next] net: preserve geometry of fragment sizes when
forwarding
On Mon, May 18, 2015 at 11:33:29PM +0200, Florian Westphal wrote:
>
> > Every objection has been of the form "this special case" (this time
> > SIP) is not easy.
>
> Yes, but these objections are not some random hand-waving gesture.
> It presents us with certain dilemmas, e.g. single udp packet:
>
> 1280 1280 1280 542
>
> sip nat helper has to do nat/pat and replaces 10.2.3.4 with 192.168.2.3
> (lets assume we'd have helpers that deal with addresses split over 2
> fragmented skbs so we can deal with 10.2 appearing in fragment #2
> and .3.4 in fragment #3)
>
> We can then end up with something like
> 1283 1281 1282 542
>
> ... and what should we do then?
I think what David is saying that you can apply your special
logic to these edge cases, e.g., linearise them and on output
use your MTU cap to refragment.
However, for the vast majority of fragments that you receive,
which would not be modified by NAT, they should retain their
original geometry.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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