From nobody Thu Jan 11 22:51:47 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 4TB0Kd0sclz56j40 for ; Thu, 11 Jan 2024 22:52:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4TB0Kc06FJz4Qcm for ; Thu, 11 Jan 2024 22:52:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MvdZ43Fy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705013520; bh=YYI6cKFFATsaPe4vk874ayZDWukjpqTkqjczT3f8wxI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MvdZ43Fy6v4csf1VWQ5N8ABvFii/+kNlQbR3xB9tDn5Ty5nRl+dtEfWCLtt014RDdsF2u+3Od6rAVF5i5M8vXoFnS0C4Ou32huAaAUPbzBs1wWLuG+OY8KMmLpfLTJlTtWx1Az7wyxB9En9USyToU9r/SVi7EpjnwHWIno3aeF7oBa1z45EJwGnV4V4ZnFfEHTF2lBhSwxYNdHHvwbRuVsaxXzQjsupbTRDDQrCWLtF79lEWhpDjIbYj8sdfL+Mti4ej+WitI4ksTNOlk6Azg65xQWWp7fypccTcm0VKUI/u/hkYc58lypRRJi34f8bGcQK3ZJZneJgpAzDDRbyRFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705013520; bh=198UO23JNlqiiXuMsd1LUKvFySoxpN56LMnTX7vtJgX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZGPgYUxHtCgXCrtEguUJsuiCoUQTxNbzP8C3lBXn+puTdsJwjAWlXff8dWDwpxQ3TndtJhiuFNx8CeYDCfS2XDy5kyanVZjK2YLqPwc/9MN9KbPZSAIATDeIy5VyA8iXnvy5+TiwZpVPyMD4owwPzA1ELZsw+HspsO/6MO3YGVu0OC/y93VS4hYlhqDnni1H0AH+thx9gXec3RrUkTZWY3kAHhvWNkJWspsAOpjA4dnC0UReFiJnnMsHflVOrqAH4F4s3ObsvomWY/AXvVh4Ii/nWQtfghVIsyVKQV/T12hJ1e+fuDBxHfCrGfx3ICYiOSNapI1RNCjbWRRQi1iQ9g== X-YMail-OSG: JVmCqckVM1nVH4VsMGuhN46e3Eiwqs9zVoyQgHDmAHuqwZ_OYq3UG2p4UUSHGwp _6n2YT1Ppi7MV2u_kN_tfqeTgLNEyhdENk4BDgWMeBDoN4_OSYeDcO2iomP0lR16Ix0wrcBYSH9G vS1D75G1vmGvrGGnzUsmH1reqP86JDOA18MrKARmpORbnwzUKU7i_eoB_hyfBFW2y0bd3QmEWQSu SUqGOsuHOg_ikAydSQkxDVxa08Nnc7F2w_A7dTlwPyTG2PO0zzctQZCpFkOxwl3qVRX3EUsO78K0 tesClJ8BtNAM6vj0xnwRfdv4Haek8hqQKMZwUvd_VC2OseS8xgpRCCo15MwftEAcOGNjoJfVzJDE 48Ag_smxfMKFo4Fkfs5w_Z1JNTHm_QPLG2oVVLnPMP.mYs.Yx78y8lc5OrOA3hOUDzFdplYpwCnE MdS.x6CRkbISu51PTVhKSRwY4IqNBVwkzyGuo2n5kNBsZ78KK1K3Wqe2C2a7EeGytqImT_gVdoJC jv4V6x083k7oyMaK5uRAqWBL6xGlq20Muq.YDhPRPJOiOk.Q2QjHl0n84so_djp91cHI6DdA2mXB n8Wzlfv_hV_uQomjuhivrWEBPiw3QL2j8lsdgfI9wkxk2HjaEWU3OY4WaAVBIRTppbMq_PpcTD.F SsbRckhWbgWeILgcCADkh.dEHSDGBIBOeOOb6edXdUQ07w81gsRmPQ15w6r7NNayGM4Tw9QUVouB e_nVjZYAec8TvelSr2TYfmvBhUJDeAxFRpk3z6_rz_wuMFtTelQDmyZ5flL_XIY3JbOMJdfMuthk h_3ZOvGkCC89bU7KI2rpsuOzlj.kZSJ10MQErhSQjNcnIx3D_MdNoQpFLeh41Xrd3gPDwk7qvM_u zSEMv4QpW2VZgsym3y30nmi1WYx3WmkG7gi7Fbh2sfu993uGBZFb.47v4PEt46H2WBH5MOuJD.26 p6kZKjeTzakoBxscEyAJd2TuQZorsnTSz0fC0Vuv2OEj5s36iTn1WGdtII1zht7qPLZ9qDYd2QIg 1HQn.iqk8b.4yV0xLqjYsm9uAtt4spN.AoYnut3oWGvCNdJiN5SXhkFfcCgDZ8m1NeZ.aqn2EwgT t27lfr7UMp6UYdKX6fvXjMAMUyLoEjTiwJcprnO1_f.lgnK_0ySAFtII1wZR.NwrrJDeDTstQ54c Z2TMULgUAyBFbzqKY97e.NTheMws6mtaIA_DGC8eM.Yw7ZdM1H1EEDOBUE7u4SCPMO6SsLhPejEl hwBsAenRU0i0i.tsWlGgQaCcD2_VJ0RPJlOmqAElX.lQbRWcTseOCvO_W_1z3AMofdeGmpjxRhgS 0evf7v72tzoHMdPQ9mop124Geqb1uRLvA8qw68p7B2AhVkG4wXm4PHpS_MQHvJLD1WggWhlGR9A. WvKK1dgcc62EB0C1fChAlMzbHNGmdzaaezcYB2fM0NIIHr8MFdpJbLGVzC_OPX73vLGIlT7XYhS4 CItFpzzh3waUTE_c_RI_s6Q63sY4Sn2.aOaIts.B4G7OCCE2kFjTSIkil5wrsDxjcQRfWT0kXrXe 8cV_sngdGdmhkzn_6bAB01NcEx1UHowzdRillq5jrNpwb064c2ozPTFbu4KM3rLc8MoWDKlx600_ WCrvKIH98ZzzlRQpMT0YGrXEWTBdUbkjcYk1NLFDxOS8TPrv1gHie4z.EyKclOp530vL5EKGJQLn yJkgwngz17RMO7ciehzNAwkdiDZbKMoTdnUkO5LD8NDXpT_6dizXpNi.7EKliMujd6oVANMPoBy6 0J0ujxZU3mGnUU11krFn5BUIc9Em4amM5BpmOuiONOp1JglgRDGJHA674twRPRAgrkvpG5yaXHc7 k9sfKo1arq83Dx3BNiDUzF7uZfxP3hjA3yBTvWs3k6COiO9IHWvNyla3VekqXdWnDtVR9sfp_ka2 2icNNjDkwkUzRUnEWk8_z_2g1CZYgBY5teI_fr5kgxmArcqhU5RcC_4FebDKq9WbHXu3XL84Wi1z tAgBWpLZ7t2503afG7ntMakPxeChC6vwH_NjZknQ3rqwnPtwX_2Yrj_AvDFnn.oPr13bazpMhFgx iDD4VImfVAckDb.DbZZwGx.uTMyzhFf__hy2jIj98jwXQWAGtNr3X9AdaDhQJObjqPjwpAO6.q6z 2QiEMX5B5jcP5SaX02T_fs.ncXUzo3ikiaSP1cj8YnGgJG0C6oIjQAcjfy20rtgGVpY6p6t2L9Wm 7nX4gO0bL4AFP.LjDaeZR_Kz5s3a_SwDctYN6V7aqeIak4VqRf3igQgCo_rfZosTlo0anmbnBmiy EdQ-- X-Sonic-MF: X-Sonic-ID: e754feef-7281-4775-ae95-425069f72ca6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jan 2024 22:52:00 +0000 Received: by hermes--production-gq1-78d49cd6df-5s2z2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f4d5e941ee0c35d7f7ee8ccf6d820bec; Thu, 11 Jan 2024 22:51:57 +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: <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> Date: Thu, 11 Jan 2024 14:51:47 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> References: <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from] X-Rspamd-Queue-Id: 4TB0Kc06FJz4Qcm On Jan 11, 2024, at 13:28, Mark Millard wrote: > On Jan 11, 2024, at 12:12, bob prohaska wrote: >=20 >> On Wed, Jan 10, 2024 at 09:34:00PM -0800, Mark Millard wrote: >>>=20 >>> "&" creates background processes that are still killed when >>> their parent tty or controlling process goes away. nohup >>> avoids that kill. >>=20 >> Not sure what's going on, but if I use=20 >> make buildworld & >> on one of my RPi* hosts and log out or otherwise drop >> the connection, the job keeps going. Maybe use of tcsh? >>=20 >>>=20 >>> 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 . >>>=20 >>> But there is no information here about which of those was the >>> one to start the failure on nemesis.zefox.com : >>>=20 >>> A) Was it the tip process? >>> B) Was it the shell process? >>> C) Was it the nemesis.zefox.com side of the ssh? >>>=20 >>=20 >>=20 >> I've put relevant excerpts from /var/log/messages from >> ns2.zefox.net (the console host) and nemesis.zefox.com >> (the terminal server) at >> http://www.zefox.net/~fbsd/tiptrouble/ >> They've been trimmed to the tip failure timeframe. >=20 > Note the "ucom_close" and "ucom_shutdown" and "ucom_cfg_close" > in: >=20 > Jan 10 14:12:54 nemesis syslogd: last message repeated 1 times > Jan 10 14:16:35 nemesis kernel: ucom_outwakeup: sc =3D = 0xffffa00002466088 > Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=3D1 > Jan 10 14:16:35 nemesis kernel: ucom_get_data: cnt=3D0 > Jan 10 14:16:35 nemesis kernel: ucom_inwakeup: tp=3D0xffffa00001979800 > Jan 10 14:16:35 nemesis syslogd: last message repeated 1 times > Jan 10 14:26:40 nemesis syslogd: last message repeated 1 times > Jan 10 14:29:48 nemesis syslogd: last message repeated 3 times > Jan 10 14:29:48 nemesis kernel: ucom_close: tp=3D0xffffa00001979800 > Jan 10 14:29:48 nemesis kernel: ucom_shutdown:=20 > Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff =3D 0 > Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x00, off=3D0x01 > Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff =3D 1 > Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x02, off=3D0x00 > Jan 10 14:29:48 nemesis kernel: ucom_cfg_close:=20 > Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 >=20 > Note the time frame vs. your reported: >=20 > QUOTE > 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 > bob@raspberrypi:~ $=20 > END QUOTE >=20 > Looks to me like something lead to ucom stopping on > nemesis.zefox.com . >=20 > The ns2.zefox.net shows: >=20 > QUOTE > Jan 10 14:12:41 ns2 sshd[48506]: error: PAM: Authentication error for = illegal user shutdown from 185.11.61.234 > Jan 10 14:26:28 ns2 sshd[48524]: error: = Fssh_kex_exchange_identification: Connection closed by remote host > Jan 10 14:43:28 ns2 sshd[48546]: error: PAM: Authentication error for = illegal user test from 85.209.11.226 > Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 20 = seq 2 [preauth] > Jan 10 15:14:29 ns2 sshd[48603]: error: kex protocol error: type 30 = seq 3 [preauth] > END QUOTE >=20 > It does not suggest ns2.zefox.net as starting the sequence. >=20 >=20 >> There is a link to a copy of nemesis's sshd_debug.log file at >> http://nemesis.zefox.com/~bob/fbsd/sshd_debug.log >> The file seems too big to search interactively via a >> browser, but it might be possible to download it in >> one pass and then grep locally. For some reason it >> isn't timestamped in any way I recognize.=20 >>=20 >>> 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. >>>=20 >>>=20 >>> 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? >>>=20 >>>=20 >> I tried, but the naming is very different from FreeBSD and I >> didn't recognize any obvious candidates. I'll look more later. >=20 > Looking around I found in: >=20 > = https://askubuntu.com/questions/26237/difference-between-var-log-messages-= var-log-syslog-and-var-log-kern-log >=20 > QUOTE > 2020 update >=20 > You may still stumble upon syslog; but the defaults have changed. > journald has replaced syslog, in quite a big portion of systems, = including Ubuntu. >=20 > This is relevant because you won't be finding /var/log/messages that = often anymore. journald doesn't write plaintext logs =E2=80=94 it uses = its own, compressed and partially authenticated format. >=20 > Search online for e.g. journalctl cheatsheet, or just study man 8 = systemd-journald, man 1 journalctl yourself. >=20 > Syslog and journald are, to a degree, cross-compatible; you can = transport logs between them in either direction. However, you won't get = plaintext logs a-la /var/log/messages with journald; and you won't get = structured (journalctl -o json-pretty) and authenticated logging with = syslog. > END QUOTE >=20 >> Meanwhile, the non-ssh-mediated tip session from=20 >> nemesis.zefox.com to ns2.zefox.net's console gpio pins >> remains up. >>=20 >=20 > Looks like the 110 MiByte or so file will take an hour > or so to transfer from when I started it. >=20 The big file does have exactly one example of: Fssh_send_error: write: Broken pipe (This ignores "Connection from " lines that report "Broken pipe".) =3D=3D=3D Mark Millard marklmi at yahoo.com