Date: Mon, 26 Aug 2019 10:07:24 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: bob prohaska <fbsd@www.zefox.net> Cc: Paul Mather <paul@gromit.dlib.vt.edu>, freebsd-arm@freebsd.org Subject: Re: RPI2 drops _some_ ssh connection Message-ID: <201908261707.x7QH7OMt077064@gndrsh.dnsmgr.net> In-Reply-To: <20190826170005.GA34339@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Aug 26, 2019 at 11:48:24AM -0400, Paul Mather wrote: > > On Aug 25, 2019, at 7:06 PM, bob prohaska <fbsd@www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201908261707.x7QH7OMt077064>