[EXT] [PATCH] ipsec: fix NAT-T length calculation
Radu Nicolau
radu.nicolau at intel.com
Mon Jul 10 11:38:29 CEST 2023
On 10-Jul-23 10:24 AM, Konstantin Ananyev wrote:
> 07/07/2023 14:26, Radu Nicolau пишет:
>>
>> On 07-Jul-23 1:51 PM, Xiao Liang wrote:
>>>> sa->hdr_len and prm->tun.hdr_len don't include L2 length so both
>>>> should
>>>> start in the diagram at the end of the ETH header.
>>>>
>>>> So the right way to compute datagram length is
>>>>
>>>> dgram_len = mb->pkt_len - sqh_len - sa->hdr_l3_off - sa->hdr_len +
>>>> sizeof(struct rte_udp_hdr)
>>>>
>>> |<- mb->pkt_len - sqh_len ->|
>>> |<- sa->hdr_l3_off ->|<- sa->hdr_len ->|
>>> |<- udph->dgram_len ->|
>>>
>>> +--------------------+------------+-----+-----+---------+-----+
>>> | ETH | IP | UDP | ESP | payload | sqh |
>>> +--------------------+------------+-----+-----+---------+-----+
>>>
>>> |<- sa->hdr_l3_off ->|<- l3_len ->|
>>> |<- sa->hdr_len ->|
>>>
>>> If hdr_len doesn't include L2 length, I would agree that
>>>
>>> dgram_len = mb->pkt_len - sqh_len - sa->hdr_l3_off - sa->hdr_len +
>>> sizeof(struct rte_udp_hdr)
>>>
>>> But then what's the point of
>>> sa->hdr_len - sa->hdr_l3_off
>>> in lib/ipsec/sa.c?
>>
>> I will defer to Konstantin for a definite answer, that is if
>> sa->hdr_len is supposed to include l2 length / offset or not. If it
>> does, then the change that triggered this discussion is correct and
>> we don't need to account for hdr_l3_off there.
>>
>
>
> Ok, have to revive my memories here.
> So, actually hdr_len stands for all tunell headers users want to add.
> It consits of optional l2_len (could be zero) plus outer ip len, plus
> in that case udp hdr len.
> hdr_l3_off is an offset withih hdr_len where outer ip header starts.
> So yep, initial patch looks ok to me, I just acked it.
> Sorry for being a bit sloppy at reviewing it.
This fix should also be CC'ed to stable at dpdk.org
Acked-by: Radu Nicolau <radu.nicolau at intel.com>
More information about the dev
mailing list