On Fri, Aug 04, 2006 at 01:51:24PM +0200, Patrick McHardy wrote:
>
> + if (!x->props.mode)
> + mtu -= blksize - 4;
You probably want to check for overflows here since mtu is unsigned.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTE
On Fri, Aug 04, 2006 at 01:50:15PM +0200, Patrick McHardy wrote:
>
> Now I get it, thanks :) I missed that the IP header isn't part of the
> length when it is aligned. So the worst-case increases by block-size
> - 4 (- 8 for IPv6). How does this look?
That should work.
If you want to be fancy yo
Patrick McHardy wrote:
> Now I get it, thanks :) I missed that the IP header isn't part of the
> length when it is aligned. So the worst-case increases by block-size
> - 4 (- 8 for IPv6). How does this look?
Forgot the patch ..
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9c5ee9f
Herbert Xu wrote:
> I've reread your patches and your handling of ESP padding is spot on.
> It's anyone's guess whether the current code gets it right or not :)
>
> However, I believe that the transport mode handling does run into
> problems with IP options. Basically, your calculation returns a
On Fri, Aug 04, 2006 at 09:16:04PM +1000, herbert wrote:
>
> Are you talking about the ESP padding case, or transport mode in
> general?
I've reread your patches and your handling of ESP padding is spot on.
It's anyone's guess whether the current code gets it right or not :)
However, I believe th
Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 01:11:19PM +0200, Patrick McHardy wrote:
>
>>>Of course it gets hairier if you have ESP padding. I'm not even sure
>>>if the current code gets that right.
>>
>>Unless I'm missing something, the padding caused by IP options
>>is always less than the wors
On Fri, Aug 04, 2006 at 01:11:19PM +0200, Patrick McHardy wrote:
>
> > Of course it gets hairier if you have ESP padding. I'm not even sure
> > if the current code gets that right.
>
> Unless I'm missing something, the padding caused by IP options
> is always less than the worst case that can hap
Herbert Xu wrote:
> On Fri, Aug 04, 2006 at 12:09:18PM +0200, Patrick McHardy wrote:
>
>>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.
>
>
> The problem is
On Fri, Aug 04, 2006 at 12:09:18PM +0200, Patrick McHardy wrote:
>
> 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.
The problem is basically you don't know a
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_bl
On Fri, Aug 04, 2006 at 11:27:11AM +0200, Patrick McHardy wrote:
>
> [XFRM]: Improve MTU estimation
>
> Replace the probing based MTU estimation, which usually takes 2-3
> iterations to find a fitting value and may underestimate the MTU,
> by an exact calculation.
Thank
> + if (x->km.state == XFRM_STATE_VALID &&
> + x->type && x->type->get_mtu)
> + res = x->type->get_mtu(x, mtu);
> + else
> + res = mtu;
> + spin_unlock_bh(&x->lock);
> return res;
> }
by two bytes with ESP and should be a bit faster, so it still
looks useful.
[XFRM]: Improve MTU estimation
Replace the probing based MTU estimation, which usually takes 2-3
iterations to find a fitting value and may underestimate the MTU,
by an exact calculation.
Signed-off-by: Patrick McHardy
13 matches
Mail list logo
