From owner-freebsd-current@freebsd.org Tue Apr 6 17:02:47 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 074395D7DD9; Tue, 6 Apr 2021 17:02:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FFDNj6Wjpz3rMZ; Tue, 6 Apr 2021 17:02:45 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 136H2he0006399; Tue, 6 Apr 2021 10:02:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 136H2hZh006398; Tue, 6 Apr 2021 10:02:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202104061702.136H2hZh006398@gndrsh.dnsmgr.net> Subject: Re: TCP Connection hang - MSS again In-Reply-To: <8d211e78-bccc-47a0-ab91-bfbf5d22911c@grosbein.net> To: Eugene Grosbein Date: Tue, 6 Apr 2021 10:02:43 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net , freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4FFDNj6Wjpz3rMZ X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.90 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.59.192.140:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[69.59.192.140:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-net,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 17:02:47 -0000 > 06.04.2021 19:54, Rodney W. Grimes wrote: > >> 05.04.2021 19:44, Rozhuk Ivan wrote: > >> > >>>>> As I understand, in some cases remote host does not reply with MSS > >>>>> option, and host behind router continue use mss 8960, that dropped > >>>>> by router. > >>>> If the peer does not provide an MSS option, your local FreeBSD based > >>>> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is > >>>> 536. So I don't think this should be a problem. > >>> > >>> Thats it! > >>> Thanks, it was ~64k in mine config. > >> > >> This is also per-host setting, you know :-) > >> > >> It is generally bad idea using MTU over 1500 for an interface facing public network > >> without -mtu 1500. You see, because TCP MSS affects only TCP and there is also UDP > >> that happily produces oversized datagramms for DNS or RTP or NFS or tunneling like L2TP or OpenVPN etc. > >> relying on IP fragmentation. > >> > >> I still recommend using -mtu 1500 in addition to mssdflt in your case. > > > > I do not recommend such a setting. That would defeat any jumbo frame usage > > locally! > > Why? Default route should not be used for local delivery. Your right, but we are both making assumptions, I assumed that most likely the only route on the system is the default route, and your assuming that they are running with something more than a default route. > > The gateway/router that is forwarding packets to the internet connection > > needs its upstream interface mtu set properly, and configured to properly > > return icmp need fragement messages on the interfaces towards the > > internal network. > > This results in extra delays and retransmission during outgoing data transfer, not good. > The mechanics is much more fragile than default route's mtu attribute. The delay should be pretty slight, the router is going to return an icmp message, and if configured to do so frag the packets and forward them on, no retransmission would occur as the DF flag is not normally set unless explicitly requested. It still makes no since to me to increase the interface MTU and then crank it back down by using a route MTU. You might as well just leave the MTU alone and not have 2 configurations items more or less doing nothing. -- Rod Grimes rgrimes@freebsd.org