From: Xiao Liang <shaw.leon@gmail.com>
To: Radu Nicolau <radu.nicolau@intel.com>
Cc: Konstantin Ananyev <konstantin.ananyev@huawei.com>,
Akhil Goyal <gakhil@marvell.com>,
Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [EXT] [PATCH] ipsec: fix NAT-T length calculation
Date: Fri, 7 Jul 2023 21:17:00 +0800 [thread overview]
Message-ID: <CABAhCOR=cwzed-nyAzacv_z+Tm5wdm0tg1Brz6w_vW3pWCEO+A@mail.gmail.com> (raw)
In-Reply-To: <CABAhCORqwXL6pb+4cihwVVWUWYdAnJ4nub8mg0DFrBmXPHCHkg@mail.gmail.com>
The context
hlen = sa->hdr_len + sa->iv_len + sizeof(*esph);
...
ph = rte_pktmbuf_prepend(mb, hlen - l2len);
...
update_tun_outb_l3hdr(sa, ph + sa->hdr_l3_off, ph + hlen,
mb->pkt_len - sqh_len, sa->hdr_l3_off, sqn_low16(sqc));
assumes L2 header length included in sa->hdr_len.
Even if hdr_len doesn't include L2, then mb->pkt_len won't either, so
UDP datagram length should still be
mb->pkt_len - sqh_len - sa->hdr_len + sizeof(struct rte_udp_hdr);
On Fri, Jul 7, 2023 at 8:51 PM Xiao Liang <shaw.leon@gmail.com> 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?
next prev parent reply other threads:[~2023-07-07 13:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 8:46 Xiao Liang
2023-07-05 13:49 ` [EXT] " Akhil Goyal
2023-07-06 9:08 ` Konstantin Ananyev
2023-07-06 10:20 ` Radu Nicolau
2023-07-07 2:06 ` Xiao Liang
2023-07-07 3:12 ` Xiao Liang
2023-07-07 8:59 ` Radu Nicolau
2023-07-07 12:51 ` Xiao Liang
2023-07-07 13:17 ` Xiao Liang [this message]
2023-07-07 13:26 ` Radu Nicolau
2023-07-10 9:24 ` Konstantin Ananyev
2023-07-10 9:38 ` Radu Nicolau
2023-07-10 9:20 ` Konstantin Ananyev
2023-07-11 2:13 ` [PATCH v2] ipsec: fix NAT-T header " Xiao Liang
2023-07-11 2:18 ` Xiao Liang
2023-07-11 8:48 ` [EXT] " Akhil Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABAhCOR=cwzed-nyAzacv_z+Tm5wdm0tg1Brz6w_vW3pWCEO+A@mail.gmail.com' \
--to=shaw.leon@gmail.com \
--cc=dev@dpdk.org \
--cc=gakhil@marvell.com \
--cc=konstantin.ananyev@huawei.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=radu.nicolau@intel.com \
--cc=vladimir.medvedkin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).