Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 11:27:11AM +0200, Patrick McHardy wrote:
>
>>-static u32 esp4_get_max_size(struct xfrm_state *x, int mtu)
>>+static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
>> {
>> struct esp_data *esp = x->data;
>>- u32 blksize = ALIGN(crypto_tfm_alg_blocksize(esp->conf.tfm), 4);
>>+ u32 align = ALIGN(crypto_tfm_alg_blocksize(esp->conf.tfm), 4);
>>
>>- if (x->props.mode) {
>>- mtu = ALIGN(mtu + 2, blksize);
>>- } else {
>>- /* The worst case. */
>>- mtu = ALIGN(mtu + 2, 4) + blksize - 4;
>>- }
>>- if (esp->conf.padlen)
>>- mtu = ALIGN(mtu, esp->conf.padlen);
>>+ if (esp->conf.padlen > align)
>>+ align = esp->conf.padlen;
>>
>>- return mtu + x->props.header_len + esp->auth.icv_trunc_len;
>>+ mtu -= x->props.header_len + esp->auth.icv_trunc_len;
>>+ mtu &= ~(align - 1);
>>+ mtu -= 2;
>>+
>>+ return mtu;
>
>
> I haven't actually done the math, but I don't think this can be right
> from a quick look. The reason is that transport mode is fundamentally
> different from tunnel mode in that the IP options are not encrypted and
> therefore do not contribute to the encryption block padding.
>
> So as the code doesn't distinguish between transport mode and tunnel
> mode, you might be producing an overestimate for transport mode.
I was wondering why the old code distinguished between transport mode
and tunnel mode, I couldn't spot anything that would be affected. I'll
look into the transport mode case again.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
