[EXT] [PATCH] ipsec: fix NAT-T length calculation
Konstantin Ananyev
konstantin.v.ananyev at yandex.ru
Mon Jul 10 11:24:52 CEST 2023
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.
More information about the dev
mailing list