Date: Wed, 21 Jun 2023 21:33:46 +0200 From: Michael Gmelin <grembo@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: Mark Millard <marklmi@yahoo.com>, freebsd-net@freebsd.org, freebsd-arm@freebsd.org Subject: Re: -current dropping ssh connections Message-ID: <0EB8C74C-C8A0-43EA-8654-BA77E43C66C0@freebsd.org> In-Reply-To: <ZJM7VXyWotSGwAtH@www.zefox.net> References: <ZJM7VXyWotSGwAtH@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 21. Jun 2023, at 20:03, bob prohaska <fbsd@www.zefox.net> wrote: >=20 > =EF=BB=BFOn Wed, Jun 21, 2023 at 10:45:25AM -0700, Mark Millard wrote: >>> On Jun 21, 2023, at 10:24, bob prohaska <fbsd@www.zefox.net> wrote: >>>=20 >>> I've got a Pi4 running -current that seems to selectively drop ssh conne= ctions. >>=20 >> Only when the ssh has text streaming over it? Even when it >> is idle? Any other types of context differences that lead >> to observable differences of some type related to the >> disconnects (vs. lack of them)? >=20 > I can't detect any consistent pattern. For a while I thought load on the > sshd-host end made a difference, but the latest disconnect was on an idle > system with serial console output the only traffic on the dropped connecti= on.=20 >=20 >>> Connections running a shell seem to stay up, but a session running tip t= o a >>> usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours.=20= >>=20 >> The way that reads, ssh to a shell and then running tip in >> that shell would stay up. (Does it?) tip is being run >> without ssh running a shell? May be more detail about the >> two contexts of establishing the connection is needed here? >>=20 >=20 > No, other way 'round. In both cases an ssh connection was made which > started a shell. In one a tip session was started, which seems prone=20 > to dropping. In the other an active shell (typically running buildworld,=20= > or maybe idle) kept running. This makes me think (perhaps wrongly) that=20= > tip is involved with the disconnection. Both shells are started as a > regular user and then su-d to root. >=20 > I'm fairly confident this isn't a client-side or NAT problem, simply becau= se > there are a dozen or so other ssh sessions running from the ssh client to t= he > various Pi2/3/4 hosts in my collection which stay up basically until they'= re > taken down deliberately. >=20 > I seem to (vaguely) recall a discussion of ssh problems over NAT some mont= hs=20 > ago, something about tolerating misssing ts (timestamps?). Is that still p= ossible? You can check if systctl net.inet.tcp.tolerate_missing_ts=3D1. It should be set to 1 by default since 13.1, but maybe it=E2=80=99s differen= t in current. Best
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0EB8C74C-C8A0-43EA-8654-BA77E43C66C0>