Date: Mon, 26 Aug 2019 10:00:05 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: RPI2 drops _some_ ssh connection Message-ID: <20190826170005.GA34339@www.zefox.net> In-Reply-To: <1A92437A-157F-4EF9-A07D-916BAED14CF2@gromit.dlib.vt.edu> References: <20190825230623.GA30925@www.zefox.net> <1A92437A-157F-4EF9-A07D-916BAED14CF2@gromit.dlib.vt.edu>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190826170005.GA34339>