netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bram Yvakh <bram-yvahk@mail.wizbit.be>
To: sd@queasysnail.net
Cc: netdev@vger.kernel.org,
	Steffen Klassert <steffen.klassert@secunet.com>,
	xmu@redhat.com
Subject: Re: [PATCH ipsec] xfrmi: drop ignore_df check before updating pmtu
Date: Tue, 04 Aug 2020 14:32:56 +0200	[thread overview]
Message-ID: <5F295578.4040004@mail.wizbit.be> (raw)
In-Reply-To: <70e7c2a65afed5de117dbc16082def459bd39d93.1596531053.git.sd@queasysnail.net>

On 4/08/2020 11:37, Sabrina Dubroca wrote:
> xfrm interfaces currently test for !skb->ignore_df when deciding
> whether to update the pmtu on the skb's dst. Because of this, no pmtu
> exception is created when we do something like:
>
>     ping -s 1438 <dest>
>
> By dropping this check, the pmtu exception will be created and the
> next ping attempt will work.
>
>
> Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
> Reported-by: Xiumei Mu <xmu@redhat.com>
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> ---
>  net/xfrm/xfrm_interface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
> index b615729812e5..ade2eba863b3 100644
> --- a/net/xfrm/xfrm_interface.c
> +++ b/net/xfrm/xfrm_interface.c
> @@ -292,7 +292,7 @@ xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev, struct flowi *fl)
>  	}
>  
>  	mtu = dst_mtu(dst);
> -	if (!skb->ignore_df && skb->len > mtu) {
> +	if (skb->len > mtu) {
>   

To me dropping the 'ignore_df' check looks incorrect;
When I submitted patches last year for VTI which related to
ptmu/df-bit[1]  I did some testing and also some comparison (also with GRE)
(I also briefly tested with xfrmi but given that the VTI patches were
mostly ignored I did not pursue that further[2])

The conclusion for my testing with GRE: (only the last item is relevant
but rest included for context)
* with 'pmtudisc' set for the GRE device: outgoing GRE packet has the
DF-bit set (this did suffer from some issues when the
to-be-forwarded-packet did not have the DF bit set)
* with 'nopmtudisc' set for the GRE device: outgoing GRE packet copies
DF-bit from the to-be-forwarded packet (this did suffer from some issues
when client did set DF bit..)
* with 'nopmtudisc' and 'ignore-df' bit set: outgoing GRE packet never
has the DF bit set: packet can be fragmented at will

How I understand things (based on my testing last year): when
'ignore-df' is set then the DF-bit should *not* be set. This in turns
means that path-mtu discovery is not possible (which is why it has to be
used in combination with 'nopmtudisc').
In the patch above the 'ignore_df' is removed which looks wrong: if
'ignore_df' is set then the size of the packet should not be checked
since the packet may be fragmented at will.
(I also suppose that means that setting 'ignore_df' is not an option (or
no longer) an option for xfrmi?)

I'm also not sure what the exact case is/was that lead to this patch;
can you shed some light on it?
(What I would expect: if 'ignore_df' is set then pmtu discovery does not
happen.)

[1]:
https://lore.kernel.org/netdev/1552865877-13401-1-git-send-email-bram-yvahk@mail.wizbit.be/
and
https://lore.kernel.org/netdev/1552865877-13401-2-git-send-email-bram-yvahk@mail.wizbit.be/
[2]: https://lore.kernel.org/netdev/5C8EDF7F.2010100@mail.wizbit.be/

>   
>  		skb_dst_update_pmtu_no_confirm(skb, mtu);
>  
>  		if (skb->protocol == htons(ETH_P_IPV6)) {
>   


  reply	other threads:[~2020-08-04 12:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04  9:37 [PATCH ipsec] xfrmi: drop ignore_df check before updating pmtu Sabrina Dubroca
2020-08-04 12:32 ` Bram Yvakh [this message]
2020-08-07 14:47   ` Sabrina Dubroca
2020-08-07 15:41     ` Bram Yvakh
2020-08-10 12:20       ` Sabrina Dubroca
2020-08-10 15:52         ` Bram Yvakh
2020-08-26  8:40         ` Steffen Klassert
2020-08-27  7:08 ` Steffen Klassert

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=5F295578.4040004@mail.wizbit.be \
    --to=bram-yvahk@mail.wizbit.be \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    --cc=steffen.klassert@secunet.com \
    --cc=xmu@redhat.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).