From nobody Thu Jan 11 05:34:00 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9YJ80Jlzz56Vk3 for ; Thu, 11 Jan 2024 05:34:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9YJ72gVqz47Yn for ; Thu, 11 Jan 2024 05:34:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704951253; bh=TGeK0jGvK+KQXQfIO2IBxRtIWjA4mN8BhaUafIMYRyw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ia+xrw9lu13u2aR7cLdbPBZAeF/WYm51vBmV3I5wd8ag8Vpc0e/1GSju4QHF1gdOSQz7l4GoSFfjuQ+97M+fzP0WGQdZUm15a3sSiT5hzcmu2lcCrwbAp0NlzsslOirUwOAPZJ3Rzi9cRFH3x4dACdJoSmO6HBkizBhVPBktnJo58N/SMaPVuGgZiJHeYdVk6j0yBIMYDXw0YW9HS4lk2LKB6x83XDxjq+oojkmw8nSleW8P7UEx+MbL9ZjLgycG0PBOhssht/4xSZoNjCVsGOEAZvyGaZXfz2M3PEGfRNUdtSP0OEHC7YEoQPwBtLmKflXwjabCH2M23qNx74ySFg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1704951253; bh=qmWgWhcNfRBsL+eH5AzuDQpHz4+Tkz28/2RBAkcQKcZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fsurxg7axoL7OqnKDn026jNpuyh7r0z05PPpGUyM9RuHvsmo8+dPviSMFSslyUs8N0sogdKqUxVXMkqzGMxoJIEF+M3XWjwL9bix8t6RnCiCjeJYL6/vi92n8B/BclZz51tV/280OM3zZnVGmhQoz172U5Oh+cc9GPpsGDvEEv5AFtLXq4QWHTVmhFJpVVC/f/k7bdc7PcM9sjQ0DXD9mc3DURDzzFzzbN1lcrTbXYOdQ8L4QczCXMaLwyL07n2OqpPCKPR8Qql2Nh4hE6j7x+1/9aO6f56Sb26f9+vER2k91tXNrIN/PgKf/BYvATuWxWU+oA77xriEOZ2XKSNaJg== X-YMail-OSG: BQSTQXsVM1kFmhtmdO9sijwYEDP1b4BPAG7nZJvCyHua4OrRpt8u2gBzrQChVQ2 a7W8lFwpzZVbpBbVeC6rn.5KqBRzCUSxXlRSlZ.ViBSXMaOtcB9tsZNVe46pPJDSngIUvmeHlNPf bF1gYwk2WzIQabCKfghVEKxhKjgK1Whvdz1AOAH2ZtcFnZtJuU9ADFa13IcOdFFn2BTJBF1WlxWs AJCrUWzlHpXDegJ.i0ogCXQFn0rMk6jz.WVVQIIW.kUn0nrMFJJS1NR.io_WpwqbWqoYsz4FIylN jLPyuUQw5zFCIVEo4AZz.4o96eyzWxK6vXLf34KQULewDxW9QT1YtsYBqPBGRlVr1819h80NtkXx eYmIyXwgEY8tG3lYXgD1cnRWVHjvvSsMrGGBsJGtkVcOxAzsam.IbSm61vxtOrbQ5FNOs9wed3kr D9v_BLr.bHcEUnbP3ehLh5Vucx5tiBrV1V9qX2BTGTlQdEQUfFu_HQoP5mu6AjMIHuYNzp7dv98Z _4nvcs9UQ9cj6G6RVlIJDVrMMh2MOBafCXG2viJezq1e4SuQllhzQxkvnjCPGye2Bs8MeIAKHPMn VrZreY6DdJXJW23o_tLwYYhEL35CfHhtN0z5LliKSQ6mUuvsZL09ccukLGbsB.TUi0H7LFgx.n8U VC74_tGedyJTsIFEeqZumg5btYpPaqPEhKOv980lQEXsS2.jBHPmLSC7whX5gBYhqJvOUNXqzdUs FwaTxpVE7wlwtGVwm1dKlumUFsmpmQoO195TKOHA_EcQ2Bt08kugQvB71swvtszmjbUJxNUPbEH6 eBmrvKlwtnOa5jzU0gf6SZI1jsxCW6g8KeK0UmPvCSPO1xhEAkQ7arZkpQGiTfVhU2EjQnFyizMY 6Mi.dUXi3n0pmo2qfcbrTT8wgtXTQT1CYqtb8wCf4NizQkDLe6RfSfRW6r6qfuenh.ufKAMlqivz 4QZdeqRVuLgQyqxuWB_hq.NcTavHOsrgO962FYQz6_MGl8UHcPZ088bZfno7TdELTsEiiplNNvbo oq0IzKQKJsE7oSyR.nvWa9Cl9RvwkUL9ym2.rU6zZyjMROsFNiFzmnuCtwXGWgY1LktsnSKRSCxP InoP63tF8DJlTuL2Evy03rTY.kho_yrmHZDBqiWjEHfifqCz3in.5hEYfLtptMeelqOkgF3ac6eS Ln4jr2NYiI84fcJOTRVhjpgkZLOzjiDlwnfHOAlsxou9Pmt5ZajVLtGluM1ApfBnYHdfQ6.XwwWk .oU5Tp95AXk9wFqWX20oOiVIyBm3trNZZLjzhdziuHlhOE40Q0cUcA.VV.yPhub8GVGIvhj74m2F KMOeqaGi06cPsuMyqdMujt4fsfG3F4LVKkvk6.37QnInPkoiBgrcXKM3DX3ZF5es_XNSC8VEx38e FZVtYaxGeaB2JKA9mzTkMzDD574hwUHImngR5N0ZwWWA.JLTvdYsm8A1XB9TDuewLuSftyXllslg oDT5Lv8mmVFB3Y8jTtjGvAR0k0MoWZi2JAaezHNxASZYRsLBFJ4QzsCKziB0rwTfdtHWMImuHLXc no4sh6amNGHPpZPGlQfLdlo3a40Yx4Wg0FsQDq6b7sF3XBWe4m005Tv_mNIF7fZxEu8ur6uAp7uD 6HgfxGfoDVfpaxrAdsShaHTU_OWQD0FB7stowh6wNLVkoI3McC6VK9P3dTfTu_hGhVQC66Yz4LEm qiEVqGF2h7nFMXB46J502j7nPMeIwUNsb9HGuyufxdDuj0kuGmfwse6sGsFtEeCIAgKiB0BrxAha 4PAt9qJvnuTjvXNd1y56jPJYACZvckVuThy9RwuytGcwTX.Y83Zw5I8gMhg9XrF2E2At99wpi6Wu Bfh4ZlPjqIsmQna04AZmtA8uUWOERmnJe5GXdF8ymD5urkdZJGBX.Ggdibrl1xL5UPgF_sgqLZZr 47GHGaqn0OY7VoNuHCliY3wUan0oROeo8czkSMZO6pnsWb4ObpwYdzxx2JcsvqVsh7nYQawNt0SE R1rqhNKuwgAsNmGta.a.hQXWhdPFcci0WZXyUVXe2YfWYPL_WL3pXAEx9Yc633v90vi.1uOOFLKK 4c7ltRhRwHtdlUwdfkfBOXQjuHEm59h8stVgbrffp_bK_CknJ47KlePNpfxtovR2SZoHW0lkupUK io8MU5zmAXZdkfJoBAeCtO4K1ORFt7BVvxGVm5_BexOruVHVATLt8KOTigsDphL_DjvGMEL4LNTb H_Xh6Cngo5PnoxPj75xwk3DxpasewYvUGSWCK2gp_vPcaoYZfaOIMJBCzyR1Br.YP.uQAuxW7EQ- - X-Sonic-MF: X-Sonic-ID: 1c8e9025-4a02-4452-ac8b-132969021058 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 05:34:13 +0000 Received: by hermes--production-gq1-78d49cd6df-vkd75 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a506b8a9e0ad6acce669c50d2820a71f; Thu, 11 Jan 2024 05:34:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Wed, 10 Jan 2024 21:34:00 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> References: <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4T9YJ72gVqz47Yn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 10, 2024, at 15:55, bob prohaska wrote: >=20 > On Wed, Jan 10, 2024 at 11:30:28AM -0800, Mark Millard wrote: >> On Jan 10, 2024, at 11:21, Mark Millard wrote: >>=20 >>> On Jan 10, 2024, at 10:16, bob prohaska wrote: >>>=20 >>>> On Tue, Jan 09, 2024 at 05:03:42PM -0800, Mark Millard wrote: >>>>> . . . >>>>=20 >>>> In general the tip session is used only for observation or >>>> troubleshooting. Ssh connections are used for other activity,=20 >>>> including OS build/install cycles, poudriere, etc. They are >>>> usually placed in the background, writing to log files so that >>>> accidental disconnects from the workstation don't stop them. >>>=20 >>> Are you using: >>>=20 >>> NAME >>> nohup ??? invoke a utility immune to hangups >>>=20 >=20 > The OS build commands end with &, which I gather does nohup=20 > among other things (not sure what). =20 "&" creates background processes that are still killed when their parent tty or controlling process goes away. nohup avoids that kill. man signal reports: Num Name Default Action Description 1 SIGHUP terminate process terminal line hangup https://en.wikipedia.org/wiki/SIGHUP describes it via: QUOTE With the decline of access via serial line, the meaning of SIGHUP has = changed somewhat on modern systems, often meaning a controlling pseudo = or virtual terminal has been closed. If a command is executed inside a = terminal window and the terminal window is closed while the command = process is still running, it receives SIGHUP.[1] If the process receiving SIGHUP is a Unix shell, then as part of job = control it will often intercept the signal and ensure that all stopped = processes are continued before sending the signal to child processes = (more precisely, process groups, represented internally by the shell as = a "job"), which by default terminates them.[2] . . . Firstly, the Single UNIX Specification describes a shell utility = called nohup, which can be used as a wrapper to start a program and make = it ignore SIGHUP by default. . . . END QUOTE (I omitted an alternate way that does not apply to FreeBSD.) nohup avoids using that "which by default terminates them" status. But I'll also note that: = https://www.gnu.org/software/libc/manual/html_node/Operation-Error-Signals= .html reprots: QUOTE Macro: int SIGPIPE Broken pipe. If you use pipes or FIFOs, you have to design your = application so that one process opens the pipe for reading before = another starts writing. If the reading process never starts, or = terminates unexpectedly, writing to the pipe or FIFO raises a SIGPIPE = signal. If SIGPIPE is blocked, handled or ignored, the offending call = fails with EPIPE instead. Pipes and FIFO special files are discussed in more detail in Pipes and = FIFOs. Another cause of SIGPIPE is when you try to output to a socket that = isn=E2=80=99t connected. See Sending Data. END QUOTE >>> That only ssh sessions that in turn run tip fail suggests that the >>> tip session gets the initial problem and then things propagate. I >>> want more than a suggestion. For example: direct tip runs that >>> are not in any ssh session: still get some form of failures? >>=20 >=20 > As it happens, the tip connection between nemesis.zefox.com (terminal > server) and ns2.zefox.net (console host) dropped. The display = reported: >=20 > login: Jan 10 09:42:46 ns2 sshd[48003]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 10:51:54 ns2 sshd[48135]: error: PAM: Authentication error for = illegal user shell from 185.11.61.234 > Jan 10 10:53:03 ns2 sshd[48138]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 10:55:47 ns2 sshd[48152]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 11:22:26 ns2 sshd[48203]: error: PAM: Authentication error for = illegal user test from 85.209.11.226 > Jan 10 12:24:21 ns2 sshd[48300]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 13:12:06 ns2 sshd[48380]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 13:14:06 ns2 sshd[48381]: fatal: Timeout before authentication = for 59.56.110.106 port 50300 > Jan 10 13:34:34 ns2 sshd[926]: error: beginning MaxStartups throttling > Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for = illegal user shutdown from 185.11.61.234 >=20 >=20 > FreeBSD/arm (ns2.zefox.net) (ttyu0) >=20 > login: client_loop: send disconnect: Broken pipe Note: "client_loop" is a function in: /usr/main-src/crypto/openssh/clientloop.c "send disconnect" is reported after a signal stops the looping: /* Terminate the session. */ =20 /* Stop watching for window change. */ ssh_signal(SIGWINCH, SIG_DFL); =20 if ((r =3D sshpkt_start(ssh, SSH2_MSG_DISCONNECT)) !=3D 0 || (r =3D sshpkt_put_u32(ssh, SSH2_DISCONNECT_BY_APPLICATION)) = !=3D 0 || (r =3D sshpkt_put_cstring(ssh, "disconnected by user")) !=3D = 0 || (r =3D sshpkt_put_cstring(ssh, "")) !=3D 0 || /* language = tag */ (r =3D sshpkt_send(ssh)) !=3D 0 || (r =3D ssh_packet_write_wait(ssh)) !=3D 0) fatal_fr(r, "send disconnect"); Note that the code just above is executing on "pi4 RasPiOS workstation" trying to write to the pipe involved --but it ends up reporting the "send disconnect". fatal_fr uses ssh_err(...), which in turn can use strerror(...) that can get the text "Broken pipe" (SIGPIPE). The "Broken pipe" indicates the type of signal that stopped client_loop, indicating that on nemesis.zefox.com there was no longer any process around set up to read the data from the pipe. What was running on nemesis.zefox.com was its side of the ssh that in turn was attached to the shell that in turn was running tip --until those exited/were-killed on nemesis.zefox.com . But there is no information here about which of those was the one to start the failure on nemesis.zefox.com : A) Was it the tip process? B) Was it the shell process? C) Was it the nemesis.zefox.com side of the ssh? We only know that the end result was lack of anything reading the pipe on nemesis.zefox.com : by then the ssh side on nemesis.zefox.com had stopped being set up to read the pipe. > bob@raspberrypi:~ $=20 >=20 > Interestingly, there's a MaxStartups warning. I discovered the failure > somewhat before 15:17 hours. The link had been up for a couple of > days IIRC. >=20 > I logged in on nemsis.zefox.com's hdmi console and usb keyboard (the = only Pi > in my collection set up for video console logins), opened x11, started = an > xterm, su'd to root and ran tip to connect to ns2.zefox.net. Did you then look at /var/logs/messages on ns2.zefox.net ? What, if anything, did such have from around the failure time frame? Did you look at /var/logs/messages on nemsis.zefox.com ? What, if anything, did such have from around the failure time frame? Did you look at /var/logs/messages [or the analogous linux place(s)] on "pi4 RasPiOS workstation"? What, if anything, did such have from around the failure time frame? I'll note that /var/logs/messages (or the like) need not be an exact match to what the console reports. > The connection was normal, no problem with needing to power-cycle the=20= > usb-serial adapter using usbconfig; tip connected and displayed a = brief > string of mixed printable and non-printing characters, ending with a > login prompt on the same line. Next came two reports from ns2 of=20 > "... kex protocol error...." =20 >=20 >=20 >=20 >=20 >=20 >>> Specifies the maximum number of concurrent = unauthenticated >>> connections to the SSH daemon. Additional connections = will be >>> dropped until authentication succeeds or the = LoginGraceTime >>> expires for a connection. The default is 10:30:100. >>>=20 >>> Alternatively, random early drop can be enabled by = specifying the >>> three colon separated values start:rate:full (e.g. = "10:30:60"). >>> sshd(8) will refuse connection attempts with a = probability of >>> rate/100 (30%) if there are currently start (10) = unauthenticated >>> connections. The probability increases linearly and all >>> connection attempts are refused if the number of = unauthenticated >>> connections reaches full (60). >=20 > If sshd mixed up new with existing sessions it might kill one running = tip, > but it'd likely kill others from time to time. So far that hasn't = happend, > at least not often. >=20 >>>=20 >>> It does suggest that testing isolated from the source(s) of >>> unauthenticated sessions could be worth while in case handling >>> the load from such sessions when already heavily loaded with >>> buildworld/builkernel or the like leads to other problems (and >>> denial of service consequences?). >>>=20 >>> I do not expect that this issue is all that likely but >>> expectations are not evidence of their own accuracy/inaccuracy. >=20 > It's my (very) subjective impression the ssh/tip problems are more > frequent when ssh attacks are more abundant. Nemesis.zefox.com is > public and sees a certain amount of doorknocking but for some=20 > reason considerably less than www.zefox.org. =20 >=20 > As an aside, during some stages of testing with pelorus.zefox.org > the host was on the LAN and so not subject to attack. It certainly > didn't prevent failure of tip sessions. Now pelorus.zefox.org is > on a public IP and seeing at least sporadic doorknocking. =3D=3D=3D Mark Millard marklmi at yahoo.com