From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BFE97C00A89 for ; Thu, 5 Nov 2020 04:42:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EB2622083B for ; Thu, 5 Nov 2020 04:42:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TxlzhO4Y"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="mj7WaTYL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB2622083B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NfJuf12T2zwHt4IYYETt79ywc6OOV72KMNXvIAMOiRw=; b=TxlzhO4Yr1nM+PnydJsK5urUD sKojTvMTNlLdprfMQGIPD8yvPWB2ub8H728yXdghX4jWNbAq53sII98cEWtsDwV0VYFCbC+KL0GOs Co8MG6B7fnkLxGdwz3g4BATYla8FrkVy32P9Mp8bTO+sCOUjihkBskJsAoytOdlDjIwlnageGXHJj Ytfo5XKWisRzpDdOl/Zy6jFVLSSObtoZ4Zco8ElvwlWoiTE4fUfoRWsP5kWZ0qfQ7U8h2CH3CTZyF CIVPtbKLp7b4urwJ/Rk24VS65Gs6FQHYTBfsgs/P5pjNCfX8YrjI4Fl92pPrGJQ5gRUFF93bVE4p8 fibAITIFg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaX65-00061m-GI; Thu, 05 Nov 2020 04:42:05 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaX5y-0005wE-RF for linux-arm-kernel@lists.infradead.org; Thu, 05 Nov 2020 04:42:00 +0000 Received: by mail-io1-xd44.google.com with SMTP id u19so497655ion.3 for ; Wed, 04 Nov 2020 20:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Duq9dQW5Jzdb3ujMdT0fiNUQPULoX6VzrLszCWfIuRA=; b=mj7WaTYLQl8Z8R2+cxErwAk6QYCYtuk0BSwcy4Vo6G0ibhWEaIHAlS9ZYRLPxt+FCx Ehwxe3anN94g13po/UTX3cYHwWT4ZbCnWjCnCH9k2rHZXv4p+2T1zSd7KTQhEGsiNqDL z/BB4MVSBP/8yJStYTBVtCP72D+noVuyGO1qFuFka+VAnKVKL7lF5R7BrKeFDZdfiZOn sHHoU8m7LaCUdbERPUlYZ0YudsrKxdNhNthytEuK4SJiXAsU99bI537BL0UE9YN0cWNy sDTdTQWAMMIEftHdjNxEL+SE6RyqW9gln7MNiTb2LiXaDtzkU65EEilv3cmgskHuQ5vN JKmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Duq9dQW5Jzdb3ujMdT0fiNUQPULoX6VzrLszCWfIuRA=; b=rb8Q5ld2UF5KRPRO/+TJzvwZcFPVpcMGO1KUiHhEdLqd/4iDGpvbnD3noxnE7vNmeB KEvlBg71dLSfnrWzZ8sm8PovbK2ZeGIYRC8iGsswL5Fa2CKguiU1vEJpGxHDF0/4HctU 91YNWCT4ZeKF2QAp+SS0hUf3OcmBsw4rFml+Uf5LBS8ujw/jA3QW67mwr17AtAY8MnpP CyHSApr+Xp+xRhzE+RQd3lXdZ1AZjxZsHPXSglePSjBph53OmtA6qjM/WVkNjPrbeoQ4 SOwp7/KhP9bxKuXKBfST/jroCdC3cvLiSs/ctzDqrvRasyj85TSpC/rqtfOCxvVQ5+Dx 5dNw== X-Gm-Message-State: AOAM532SowiadymAXdBH3Z7itl/N8SWtW9XadlEm/iXqRxVyPIecP7Hy lZsZENw5B9Q9xvDFMHNjU3Gh5WEo/VAOvIKJqczq4g== X-Google-Smtp-Source: ABdhPJx1PyyQdfrnX4KUFq0a8rT1VNgnT1Ph8zJ9ue/a9y+4slW5/MkhfLkG8nrxOVPwFfwBEqkdYaKGgzycLmiPxEY= X-Received: by 2002:a02:cc77:: with SMTP id j23mr722712jaq.20.1604551314784; Wed, 04 Nov 2020 20:41:54 -0800 (PST) MIME-Version: 1.0 References: <20200909062613.18604-1-lina.wang@mediatek.com> <20200915073006.GR20687@gauss3.secunet.de> <1600160722.5295.15.camel@mbjsdccf07> <20200915093230.GS20687@gauss3.secunet.de> <1600172260.2494.2.camel@mbjsdccf07> <20200917074637.GV20687@gauss3.secunet.de> <1600341549.32639.5.camel@mbjsdccf07> <1604547381.23648.14.camel@mbjsdccf07> In-Reply-To: <1604547381.23648.14.camel@mbjsdccf07> From: =?UTF-8?Q?Maciej_=C5=BBenczykowski?= Date: Wed, 4 Nov 2020 20:41:43 -0800 Message-ID: Subject: Re: [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface To: "lina.wang" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201104_234159_075861_74B78BD7 X-CRM114-Status: GOOD ( 26.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Steffen Klassert , Herbert Xu , Hideaki YOSHIFUJI , Linux NetDev , Kernel hackers , linux-mediatek@lists.infradead.org, Jakub Kicinski , Matthias Brugger , Alexey Kuznetsov , Greg Kroah-Hartman , "David S . Miller" , linux-arm-kernel@lists.infradead.org, Lorenzo Colitti Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 4, 2020 at 7:53 PM lina.wang wrote: > > Besides several operators donot fragment packets even DF bit is not set, > and instead just drop packets which they think big, maybe they have a > consideration--- fragmentation is expensive for both the router that > fragments and for the host that reassembles. > > BTW, ipv6 has the different behaviour when it meets such scenary, which > is what we expected,ipv4 should follow the same thing. otherwise, > packets are drop, it is a serious thing, and there is no hints. What we > do is just fragmenting smaller packets, or is it possible to give us > some flag or a sysctl to allow us to change the behaviour? > > On Thu, 2020-09-17 at 19:19 +0800, lina.wang wrote: > > But it is not just one operator's broken router or misconfigured > > router.In the whole network, it is common to meet that router will drop > > bigger packet silently.I think we should make code more compatible.and > > the scenary is wifi calling, which mostly used udp,you know, udp > > wouldnot retransmit.It is serious when packet is dropped > > > > On Thu, 2020-09-17 at 09:46 +0200, Steffen Klassert wrote: > > > On Tue, Sep 15, 2020 at 08:17:40PM +0800, lina.wang wrote: > > > > We didnot get the router's log, which is some operator's.Actually, after > > > > we patched, there is no such issue. Sometimes,router will return > > > > packet-too-big, most of times nothing returned,dropped silently > > > > > > This looks like a broken router, we can't fix that in the code. > > > > > > > On Tue, 2020-09-15 at 11:32 +0200, Steffen Klassert wrote: > > > > > On Tue, Sep 15, 2020 at 05:05:22PM +0800, lina.wang wrote: > > > > > > > > > > > > Yes, DF bit is not set. > > > > > > > > > > ... > > > > > > > > > > > Those two packets are fragmented to one big udp packet, which payload is 1516B. > > > > > > After getting rid of tunnel header, it is also a udp packet, which payload is > > > > > > 1466 bytes.It didnot get any response for this packet.We guess it is dropped > > > > > > by router. Because if we reduced the length, it got response. > > > > > > > > > > If the DF bit is not set, the router should fragment the packet. If it > > > > > does not do so, it is misconfigured. Do you have access to that router? I'm afraid I don't really understand the exact scenario from the description of the patch. However... a few questions come to mind. (a) why not set the DF flag, does the protocol require > mtu udp frames (b) what is the mtu of the inner tunnel device, and what is the mtu on the route through the device? - shouldn't we be udp fragmenting to the route/device mtu? maybe stuff is simply misconfigured... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel