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: > > On 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: >>> >>> I've got a Pi4 running -current that seems to selectively drop ssh connections. >> >> 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)? > > 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 connection. > >>> Connections running a shell seem to stay up, but a session running tip to a >>> usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. >> >> 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? >> > > 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 > to dropping. In the other an active shell (typically running buildworld, > or maybe idle) kept running. This makes me think (perhaps wrongly) that > tip is involved with the disconnection. Both shells are started as a > regular user and then su-d to root. > > I'm fairly confident this isn't a client-side or NAT problem, simply because > there are a dozen or so other ssh sessions running from the ssh client to the > various Pi2/3/4 hosts in my collection which stay up basically until they're > taken down deliberately. > > I seem to (vaguely) recall a discussion of ssh problems over NAT some months > ago, something about tolerating misssing ts (timestamps?). Is that still possible? You can check if systctl net.inet.tcp.tolerate_missing_ts=1. It should be set to 1 by default since 13.1, but maybe it’s different 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>