Re: TCP6 regression for MTU path on stable/13

From: Harry Schmalzbauer <>
Date: Mon, 13 Sep 2021 11:18:38 UTC
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:
> 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' 

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.