Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1139481pxb; Fri, 6 Nov 2020 01:54:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJzjiyOzSu2GHQELrRRa1e66LIhJypQoEZQV0cboXZ/RhuwEWFZIzfTT3YMxyS5syaaV3Z23 X-Received: by 2002:a17:906:3087:: with SMTP id 7mr1180022ejv.375.1604656456525; Fri, 06 Nov 2020 01:54:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604656456; cv=none; d=google.com; s=arc-20160816; b=bxVsrvjDFCuYcTSIzUOOvYOWingItLgW/Lkv6hnDu5kj3q2YM1B8isfkFqulRvQnxu Cx+q7Hdf+Xnx2yNoY1IGDpaYr63Y6BBRyZiSSVQQLJXo/LzwPo84pE8vjKhvrs8gkPa5 HND4LjXEu7SIc801BdODdj+r6NrQ9k6Ex/NHK/DUYhSiuDqJETEyW4wYwVZRKnAieeSE yxx465hw+m+N/S0VsFkgoPXu/1rppUw7ie95HwvPUNwAHZIARKOkosEKFfeCeyD7r5gN jnzVRTNaRBLQsfDcklFbAuN/xGSRLZuqm+lyd2+gvFDQ/QZlI8hCRERRtse335g4fz0U E95Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=9IBtvz1xb0AHqlIyVvrG0wyMkGPT2R1uF6Ltx4fuS1Q=; b=zIEgbm27545xdzHrILD6BjZgThkehiQKMk9ivm5q/2Yhbm3TDMDAvRPdiRsZIdMcH6 vdY4OsetjtPXUpTGXNKskbGHiDllb2V4p/5Hk2zAfgqLlXiM4Y8N+E7VR+BI6eiYXztc BJu11Vpwgrz+46eKe9E9TdqIn+Y3CRm+COfmkc6EWPv0QLJlaaF6fiPwPI3kHAuIpLls Rr0fUY31HsK+VUZIEZz2LI8fOHUUftFroMcUeP9SdyIwhSxu6bo2dOTVUP2gxU7dbbDH 5+prmNOdKIYDwJsChKeGf4GMRhj8QlL+daWQHokdq1lgOgAvASa9zs3cQLgReSX1nffZ Nmwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@malat-biz.20150623.gappssmtp.com header.s=20150623 header.b=SAtXTf1X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w14si470903eje.646.2020.11.06.01.53.54; Fri, 06 Nov 2020 01:54:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@malat-biz.20150623.gappssmtp.com header.s=20150623 header.b=SAtXTf1X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726788AbgKFJvf (ORCPT + 99 others); Fri, 6 Nov 2020 04:51:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726165AbgKFJvd (ORCPT ); Fri, 6 Nov 2020 04:51:33 -0500 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E5A6C0613D2 for ; Fri, 6 Nov 2020 01:51:32 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id 7so1074189ejm.0 for ; Fri, 06 Nov 2020 01:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=malat-biz.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=9IBtvz1xb0AHqlIyVvrG0wyMkGPT2R1uF6Ltx4fuS1Q=; b=SAtXTf1XTB2iVd5TsH8z3gKUSMvhnZmXeL+fzOMchO4JYyHTivLWInorPoNF1DFORj j8lXfXmgtXu+LcfNo4JD7X/kZD5JqBa5Sf75iYnWT1zVOVCVhwDLvnHBJQIRBo0PEPpR 2R/cJBBtyoU1IKHW2m2J9wLN0y1SldbIzR4n6eyWustw2bynhVWuiSODN6OzGbBkequZ UYTantj+YB5gOLlQtB/RipsFf4kztiwyb1ksnx/etvPWbpL2Sb/hBy1qM3ryYc2fsIhr sv1si2l3sOINQX3318hskJopCjJYeJ7xWUMTKwi1DyB3OvrKJMzCkm66nBD9cX2p+Lrx jObw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9IBtvz1xb0AHqlIyVvrG0wyMkGPT2R1uF6Ltx4fuS1Q=; b=H56ykH7wZpwFI4crto4SIS/mPkS2YE7MrYbSzTiIyLp7mW8uQGdR1OKAkp25HTwIl5 93cIY27bG7GuPQyBVdyX+fy/zlPD2JJIaUYym7uB4mIBvAAkUIY/NB3D37uJDkmPK1nn vItN3kpK+RbG7ArVL5L7nrtRUcJWY/S1Z1TA9Y6Rszfg7HnOPGI4aRlm/zrxLPqrVgjG /Sz7oln9thSz8AKizX6vxm35XQ/f8hpavNWyw8UdLrHXkHreBQNXS2zD8hHmF3v7tlzy cJAi+7bMf3RdWla7goyWR1SlolGHBJ/aMWL7stPbbih0c2IskwrE6kjQJQhOx2ls1QED c6Ng== X-Gm-Message-State: AOAM531V5XVNWlFd4b4F+AuyUNU4qnbArAI4GGrW3yI//y21Kn6qPzV1 i6G48xTbZ2nwjR6WoW5M/JcgSllhKHwpF6qG X-Received: by 2002:a17:907:264d:: with SMTP id ar13mr1167369ejc.207.1604656290864; Fri, 06 Nov 2020 01:51:30 -0800 (PST) Received: from bordel.klfree.net (bordel.klfree.cz. [81.201.48.42]) by smtp.gmail.com with ESMTPSA id k11sm603182edh.72.2020.11.06.01.51.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Nov 2020 01:51:30 -0800 (PST) Date: Fri, 6 Nov 2020 10:48:24 +0100 From: Petr Malat To: Marcelo Ricardo Leitner Cc: linux-sctp@vger.kernel.org, Vlad Yasevich , Neil Horman , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] sctp: Fix sending when PMTU is less than SCTP_DEFAULT_MINSEGMENT Message-ID: <20201106094824.GA7570@bordel.klfree.net> References: <20201105103946.18771-1-oss@malat.biz> <20201106084634.GA3556@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201106084634.GA3556@localhost.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 06, 2020 at 05:46:34AM -0300, Marcelo Ricardo Leitner wrote: > On Thu, Nov 05, 2020 at 11:39:47AM +0100, Petr Malat wrote: > > Function sctp_dst_mtu() never returns lower MTU than > > SCTP_TRUNC4(SCTP_DEFAULT_MINSEGMENT) even when the actual MTU is less, > > in which case we rely on the IP fragmentation and must enable it. > > This should be being handled at sctp_packet_will_fit(): sctp_packet_will_fit() does something a little bit different, it allows fragmentation, if the packet must be longer than the pathmtu set in SCTP structures, which is never less than 512 (see sctp_dst_mtu()) even when the actual mtu is less than 512. One can test it by setting mtu of an interface to e.g. 300, and sending a longer packet (e.g. 400B): > psize = packet->size; > if (packet->transport->asoc) > pmtu = packet->transport->asoc->pathmtu; > else > pmtu = packet->transport->pathmtu; here the returned pmtu will be 512 > > /* Decide if we need to fragment or resubmit later. */ > if (psize + chunk_len > pmtu) { This branch will not be taken as the packet length is less then 512 > } > And the whole function will return SCTP_XMIT_OK without setting ipfragok. I think the idea of never going bellow 512 in sctp_dst_mtu() is to reduce overhead of SCTP headers, which is fine, but when we do that, we must be sure to allow the IP fragmentation, which is currently missing. The other option would be to keep track of the real MTU in pathmtu and perform max(512, pathmtu) in sctp_packet_will_fit() function. Not sure when exactly this got broken, but using MTU less than 512 used to work in 4.9. Petr