From owner-freebsd-arm@freebsd.org Mon Aug 26 15:48:32 2019 Return-Path: Delivered-To: freebsd-arm@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 E34B7DE88F for ; Mon, 26 Aug 2019 15:48:32 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HGcv6zp2z4ZDS for ; Mon, 26 Aug 2019 15:48:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather-dld-1.lib.vt.edu (pmather-dld-1.lib.vt.edu [128.173.51.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 16F9A8B; Mon, 26 Aug 2019 11:48:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI2 drops _some_ ssh connection From: Paul Mather In-Reply-To: <20190825230623.GA30925@www.zefox.net> Date: Mon, 26 Aug 2019 11:48:24 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <1A92437A-157F-4EF9-A07D-916BAED14CF2@gromit.dlib.vt.edu> References: <20190825230623.GA30925@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 46HGcv6zp2z4ZDS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-3.04 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.64)[ip: (-1.62), ipnet: 128.173.0.0/16(-0.81), asn: 1312(-0.74), country: US(-0.05)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.898,0]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 15:48:32 -0000 On Aug 25, 2019, at 7:06 PM, bob prohaska wrote: > I've an RPI2 running 11.3-STABLE FreeBSD 11.3-STABLE #0 r351178 > which seems to be dropping one of several active ssh connections. > > With four connections active from terminal windows on a Pi3 running > raspbian, the one used to monitor a cu session keeps dropping every > half-hour or so. All the other connections, running ordinary user > processes like top or compiling a port, seem to stay up and running. > > There has been a tendency for -current to do this on a Pi3, but > 11-stable didn't until the latest upgrade a few days ago. > > It doesn't look like a network problem, since all four sessions > are over the same wifi and wired links. Could there be some odd > interaction between cu and ssh? Is the cu session producing regular output? If not, could there be some sort of idle timeout at the remote end disconnecting it? (All the other sessions you mention above [e.g., top] seem like they would be generating regular output.) Are you using the ServerAliveInterval option at the client side of the SSH session to ensure semi-regular traffic is being sent through the connection? This can help prevent the connection state being aged out with some stateful firewall setups. Cheers, Paul.