lkml.org 
[lkml]   [2012]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] xfrm: take iphdr size into account for esp payload size calculation
On Wed, May 09, 2012 at 06:35:52PM -0400, Benjamin Poirier wrote:
>
> According to what is done, mainly in esp_output(), net_header_len aka
> sizeof(struct iphdr) must be taken into account before doing the alignment
> calculation.

Why do you need to take the ip header into account here? Your patch breaks
pmtu discovery, at least on tunnel mode with aes-sha1 (aes blocksize 16 bytes).

With your patch applied:

tracepath -n 192.168.1.2
1?: [LOCALHOST] pmtu 1442
1: send failed
1: send failed
Resume: pmtu 1442

Without your patch:

tracepath -n 192.168.1.2
1?: [LOCALHOST] pmtu 1438
1: 192.168.1.2 0.736ms reached
1: 192.168.1.2 0.390ms reached
Resume: pmtu 1438 hops 1 back 64

Your patch increases the mtu by 4 bytes. Be aware that adding
one byte of payload may increase the packet size up to 16 bytes
in the case of aes, as we have to pad the encryption payload
always to a multiple of the cipher blocksize.

> -
> - switch (x->props.mode) {
> - case XFRM_MODE_TUNNEL:
> - break;
> - default:
> - case XFRM_MODE_TRANSPORT:
> - /* The worst case */
> - mtu -= blksize - 4;
> - mtu += min_t(u32, blksize - 4, rem);
> - break;

Btw. why we are doing the calculation above for transport mode?


\
 
 \ /
  Last update: 2012-05-10 15:01    [W:0.065 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site