From owner-freebsd-arm@freebsd.org Mon Aug 26 17:07:29 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 93513E0AE0 for ; Mon, 26 Aug 2019 17:07:29 +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 46HJN04rMlz4g1k for ; Mon, 26 Aug 2019 17:07:28 +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 x7QH7OCr077065; Mon, 26 Aug 2019 10:07:24 -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 x7QH7OMt077064; Mon, 26 Aug 2019 10:07:24 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201908261707.x7QH7OMt077064@gndrsh.dnsmgr.net> Subject: Re: RPI2 drops _some_ ssh connection In-Reply-To: <20190826170005.GA34339@www.zefox.net> To: bob prohaska Date: Mon, 26 Aug 2019 10:07:24 -0700 (PDT) CC: Paul Mather , freebsd-arm@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: 46HJN04rMlz4g1k 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 [-0.24 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.13)[-0.131,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.951,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.10)[-0.102,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.05)]; 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 17:07:29 -0000 > On Mon, Aug 26, 2019 at 11:48:24AM -0400, Paul Mather wrote: > > 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.) > > > Yes, the cu session is to the serial console of another Pi which spews a > regular stream of security alerts. There are five such sessions, one to > each Pi in my cluster. They are > r351122 ns1 11-stable > r351003 ns2 11-stable > r351178 net 11-stable > r351413 org -current > r351178 com 11-stable > > Admittedly, it's baffling that two machines at r351178 behave differently. > Previous to the latest round of upgrades the machine running -current did > this but has since stopped, with the symptoms moving to only one -stable > machine after the most recent upgrade a few days ago. > > > 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. > > > > I've not set anything explicitly, it's all system defaults. Likewise, > there's no firewall. > > The ssh window ends like this: > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > login: Aug 25 17:19:31 www sshd[61010]: error: PAM: Authentication error for illegal user support from 103.125.191.208 > Aug 25 17:19:31 www sshd[61010]: error: Received disconnect from 103.125.191.208 port 55630:14: No more user authentication methods available. [preauth] > Aug 25 17:55:06 www sshd[61093]: error: PAM: Authentication error for illegal user support from 103.125.191.208 > Aug 25 17:55:06 www sshd[61093]: error: Received disconnect from 103.125.191.208 port 51853:14: No more user authentication methods available. [preauth] > > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > login: packet_write_wait: Connection to 50.1.20.26 port 22: Broken pipe > bob@raspberrypi:~ $ > > There are other ssh sessions open to the failing host which generate no > regular traffic and seem to stay up for days. However, sessions used to > run portmaster interactively seemed inclined to disconnect. > > Superficially it looks as if the _kind_ of traffic makes a difference. > > Thanks for posting! > > bob prohaska Are there any OOM errors in the /var/log/messages or other indications that the system decided to kill a process or a process exited abnormally? -- Rod Grimes rgrimes@freebsd.org