From nobody Mon Sep 13 11:18:38 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5504517B3E3F for ; Mon, 13 Sep 2021 11:18:48 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7PB00kHBz3w2L for ; Mon, 13 Sep 2021 11:18:47 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 18DBIdEw022470; Mon, 13 Sep 2021 13:18:39 +0200 (CEST) (envelope-from freebsd@omnilan.de) X-Authentication-Warning: mx0.gentlemail.de: Host ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800:0:0:0:0:a135] claimed to be mh0.gentlemail.de Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 2D145F99; Mon, 13 Sep 2021 13:18:38 +0200 (CEST) Subject: Re: TCP6 regression for MTU path on stable/13 To: "Andrey V. Elsukov" , "net@FreeBSD.org" References: <8e4f78e5-0717-8002-5364-44df5c8d7dad@omnilan.de> <36d9d998-c484-a4f6-6c62-c6ec103aeb33@yandex.ru> From: Harry Schmalzbauer Organization: OmniLAN Message-ID: <14f7348c-a11f-9ae8-8a4e-77e0333ba478@omnilan.de> Date: Mon, 13 Sep 2021 13:18:38 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 In-Reply-To: <36d9d998-c484-a4f6-6c62-c6ec103aeb33@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4H7PB00kHBz3w2L X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Am 13.09.2021 um 12:37 schrieb Andrey V. Elsukov: > 12.09.2021 14:12, Harry Schmalzbauer пишет: >> Will try to further track it down, but in case anybody has an idea, what >> change during the last view months in stable/13 could have caused this >> real-world problem regarding resulting TCP6 throughput, I'm happy to >> start testing at that point. > > Hi, > > Take a look at: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255749 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248005 > > does the problem described in these PRs is the same as yours? Hi, thank you very much for your attention! Most likely these are unrelated to the regression I'm suffering from, because these affect 13-release and earlier. Mine arose during the last months. And it seems not to be a jumbo frame problem. As a workaround, I kept a MTU of 1500. Remote-SSH to the router itself (same FreeBSD 13-stable) via PPPoE (netgraph/MPD5) IPv6 is fine. Any host behind that router is awfully slow due to 'packet too big' shoutings. I'm not familiar with the exact mechanics involved for IPv6 fragmentation, but this seems to be a bigger issue for IPv6 generally. It's clear the the fixed mtu setting (1492) on the route is ignored (with recent stable/13). But I never had problems communicating with (mtu 1500) IPv6 hosts behind a 1492 mtu router, where the host hasn't had a fixed route mtu but used the nic mtu (1500). Now the pmtu for IPv6 is clearly broken, indipendent of the ignored route mtu. Will try to set up a test environment and track down the commit which introduced the problem. I'm sure that stable/13 from around april was ok. Might be that the problems described in the PRs you list above did apply, but that was more like a optimization issue. The new issue renders IPv6 connections to a 'not working' state. Hope to get back to you soon with more info. Thanks, -harry