Date: Mon, 26 Jun 2023 19:38:22 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Jamie Landeg-Jones <jamie@catflap.org>, freebsd-net@freebsd.org, freebsd-arm@freebsd.org Subject: Re: -current dropping ssh connections Message-ID: <601E35C4-CDE1-47A3-B2D2-29501AB5FB93@yahoo.com> In-Reply-To: <ZJpCqCVzcMGIruMU@www.zefox.net> References: <ZJMyPquk32fXhT%2BI@www.zefox.net> <E84D47F1-4E75-4DA1-8EE2-3E2F36DF0EF1@yahoo.com> <ZJM7VXyWotSGwAtH@www.zefox.net> <202306212305.35LN5ITH069587@donotpassgo.dyslexicfish.net> <ZJR5FzEEFofoh8f1@www.zefox.net> <202306222238.35MMcoQm017939@donotpassgo.dyslexicfish.net> <ZJpCqCVzcMGIruMU@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 26, 2023, at 19:00, bob prohaska <fbsd@www.zefox.net> wrote: > On Thu, Jun 22, 2023 at 11:38:50PM +0100, Jamie Landeg-Jones wrote: >> bob prohaska <fbsd@www.zefox.net> wrote: >>=20 >>> That seems worth a try. >>> The notion of an ssh escape (~. in this case) finding its way into = the data stream is new to me. >>=20 >> Thinking again, that looks like corruption coming down the ssh = connection. >> For the ssh escape char to affect anything (note it needs to be = preceeded >> by a new line) it would have to be sent up the line. >>=20 >> For an example, assuming ssh has the default escape char, look at the = difference between: >>=20 >> printf 'pwd;\n~.;echo sleeping.; sleep 5' | ssh -tt user@host >>=20 >> and with the same printf, but no escape char: >>=20 >> printf 'pwd;\n~.;echo sleeping.; sleep 5' | ssh -tt -e none user@host >>=20 >> You can see how the former closes the connection due to the \n~. >>=20 >> (The -tt forces a terminal/interactive session to be set up - = normally, as we are >> piping input to ssh in this case, the terminal isnt set up, and the = escape character >> isn't used - it's only recongnised in interactive sesions by default) >>=20 >> I personally have "EscapeChar none" in my ssh_config, but I suspect = this >> is probably not the issue here, still, can't hurt to try it! >=20 > Indeed, connection was dropped with escape character set to none. > There does seem to be a some dependence on system load. Connections > survive at light or no load and drop when the sshd side is busy.=20 So how busy is the disk media (really the USB bus) from somewhat before the failures happen to the failure point? The question applies separately to both systems involved in the ssh session. I'll remind that on a RPi2B v1.1, RPi2B v1.2, or RPi3B* the Ethernet and the 4 USB ports all share the one USB2 path at an internal stage for the USB subsystem, if I remember right. Saturating that USB2 path with data transfer bytes to/from disk media might be able to block other activity long enough to cause the Ethernet communications to have problems for all I know. (Amount of data queued for transfer would be relevant.) This might be a reason to avoid settings for the combination vm.pfault_oom_attempts and vm.pfault_oom_wait to values that could contribute to a sustained period of saturating the USB channel. (I have no detailed knowledge of how the tradeoffs work for the competing uses of the USB channel. So I can not validly claim to know that the above is realistic.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?601E35C4-CDE1-47A3-B2D2-29501AB5FB93>