From nobody Mon Jul 04 18:47:23 2022 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 0F0461C75F42 for ; Mon, 4 Jul 2022 18:47:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4LcFD845cKz4v35 for ; Mon, 4 Jul 2022 18:47:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656960449; bh=5KrJthDPwdSr5urdB2FzZbak7tpyw6lofF6/NEBgALw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fmkDfY4LrqjImeR7/V2e8yf226ri0/VRIo8phOtI2vhIbIXhB5VPhJURp6iz4MxptrToNnUHuPpla9ueusYbKSbSIUZUSHf7x8XxpXb6s2R31eAyfKyQz4dD+KIHDjhtoqFmnjSstv9FG6ACYGDebGSU7rca2e/8lByKq2dkBK4zJyC+GBvUNaabIwVjsmti6fkXK+Qu3v3TjPFNLeoXH0s1gmbpuVZksCK6mf8kP9Cj8OWQPr/7DWrM2B7tCBBlifkAmJFwoFG01FnLUXGazRCW0NoCfzPLBEjsAmlxrC3x2jX0ZX5/+7uMVHHIQKejlvnEw6+a1cS8p2izCSAqDw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656960449; bh=3cHxNL/in6bFtXynZEEDEqr+ymE1XNKWe+iRYe5i7Qv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Mr244115ntl8uqirZGzTlfO5GJ++koWNqdfEX0udxAcU7qNo+z3UMU2e5piCgw6hqjoV09BJTBM6cK0HM5NMZXq69NVJJM8APE9hbaeQmhPKDFR7rpdsMrULOyrd3mXpnhNiBoS4QfGpwvKw6xYS9/JBTeySCS9CA9xhhULoG7QLXFGav4kTmGz6wHgAzGI9Kk3i1tCPe3DoFwAblpINbaE7QnME8oHTPfTqklTAGf91BYy8yqJ183ZIgxkpxOk+yGoCdvgGpI3OGPZxGZ97RXicM4fFHr++rNX1LXmvcrv3ePmxgZSoVYN5rqYOvMxhjO8KKczs3riJQtAmCqsiHQ== X-YMail-OSG: UEmBjRsVM1mv.Y0i_Rsj_N6SHa4wGiNysjfsxMto5O5ngEwCPjNaswrzy0xfab5 R1TzXvZQPsaLFGFitY5J3Z.0_YEzLYYNhvPVwYUm31I63RcN2YUldugVTqLLrtetGX20e3bQ4jtK c_WknM5J8KH1dMxczVaND5Zy306pIXY2BNePAOgelEgx5yFCpCx_I9qeUe8UPKvUR2mMKMuazbfo h.rPgqfp4dbyX6fLT9aaq0OHZKBFkwXJ5HK0jbUauXkgAujwc5f5yBYcC.MfrHOJjP0S5BThHEb3 g6yBMJqXH2U.Bg7XRX5bTllxhKlo5YrGjT2dg3E9MGbon5E4unY4hXHYAGOaSHqhhSncjlBkwmWJ P775tOIPWZnLycsH.qBrrdCc5_kRHOMrgOH4WyhDWjghiItrwXaW1LaXveSZoZfgEtf23l8y2Sl1 6AiAiV6Rw63OQiDrVZSwirPtzcSySDk14P1.bG23kDJ3a9s1WWkIC8uL8S80br6gPvdp1ln9MZVN ntnmsLr.aycZqI1m9RpM_CqOMgowOnMAIyPixRTztEetBw105PCOpDF83FBHf_8okcxlHuR.650k uGXFNTaykOErJfAegYx_ZxrxHYsavEVtn9uNbmlbN_I8nedWiXSWByYm14co5RzcugQWnpUyLqHg uFdZE5wUPw3EUO7nnfbSfR2.5nQaSwtou4t0CSzrWSO7JbUsr5eXr1s97SatmK.ypsQ5haPSKSmf zwdxgwdDlBFF1OQLJQ6kbnMLriXK9VhhX9YsOtPGe0GYCK6Cw8p.kXxHnAl5PJ2Nz.XgDrL8MfpP ctHVMpPF99dmxqFhsgHru8I4p11L56LK77DbC5HNMRhYyd0HGvVWTbGN6dMKhKsJCByVdJK6aTyl ud88QNYlBUNGopdvHHjg0bFXnVgNuurTv563J38PbYPoDoKGVntrU908mSOxyRpYL5hvPomIwFJn ZtNdtjtdLfZhv89jFpeyewTCLkJ37GbReo0D2Fx296oRNnUrBAXSYzskweLOOpm9JJmOsTsH4j5P bM5wWT84vujHnHN93jDMpzYUPch.UK2G_kGm_F5sx7EzYEOLbYIlGuLBe5hTXoZ7lED9UT1eDn.z d6_kx8vzvAsv8Wu3q9z44DfD6KGmxT_uUqEIzHrYaZr4rX7DxYQKMfftEmBvkJPq_0.VG8LJey0R Xew6gN0XPwvrZNJWqbKJFt2vq37QCioQ9s0CKPYYrzWEaRa0NtHnuxL_192OFQl1B4qnFV_Ff9Fu 13MdHXPThMx50xmRCV9a_6bw99gSo7rIfJswePao7y297ikr64lOZbtvi.4Hngpjs9_1K4f1wSWO X6vn46apRhrCsPL.CPuVaChMOnHbq_IKlP0SLwev_mfR6422Wwq62X_loHJwc0pTS7kfyI4c_Vsg Ts5chXpJa9tkfSD3ny6bG5eIhvYPdFYDVjoM7PLKe7aBu6T2aR4uhwND3p2JBhSHCD3Yvt68IRTW ohLjXTXDco1.cg2kO0SFZWUqLWObpw5dKIa_EK.NdxjEHJEiDJuALtCcAQw5JB56Ed8PYpzfmajy F8.C9abmXM_mTqe4Pu7wfw3gJPQ3l.43yg0RzWwnE7.vI7jk0yzfaPYrwVHT1YwFitCbW.gRtR7n 9SQBxdBkvEbtLO53lkoag1E5RQ96uPbcWClqMiA4YL6g9xU..FQ4zDRiu0hOr49ZCvOwPmdUjT.t cNUmYHkEObTkSrnqpb1Sv1QN96HvqXIZDzlKh06odhGAlu_L1WS1lvZKJrg4_pEelAaP7wgGidq_ eZVEUAfH07h5KUyKFA1VLpfYxchn0MzRjuFz5ZfwGhJ19DOfNld2c8bOhpN_O.KjnW2BR3uEMRRS 2BPXSWz.RsvJlcveguX9YkGVx0tWkEl65AtSRuppIQUqDn0qmnIOV8YhDU9YD4ehGzsS.cMjYANI 8JGR2_qc3lrIifYD2P_yChakHL9v6z8AGP7_VqS8bI631W8nOGxmJ2cBKcx9gjvMxmIBSVOCH7LZ f_A978.dF317bLzfkcFLNOVGLjc8i1cNf37FlLg6TzXdJrjQahvhjiqbOpnfCjS_z_oMR4if8Z0O dOxYqK.mt_La2WrmmGzyr1YgX1xy9gwe_WeZosGiui_7WkRqw1l_ByCgV1IH0oL1JJiOntVgboIz QjSZQw201m5NZRUb8Y_XBdZd7KfFSueOeosheVz1iw1jVn0CiEnB67I2H2lC7rr6lfwA_5T4k9Ge W3gu0RSvvIVhDl0cZgvZ5Gns61l8uwlIjCFfywnsoZM_3ZM8_LD6tBZrgbnPyzOjzevgbCEKnsW. xaV4b X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Jul 2022 18:47:29 +0000 Received: by hermes--production-ne1-7864dcfd54-mdwhz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b407c1d08c1685a2dd3233ca9cfa693b; Mon, 04 Jul 2022 18:47:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 14.0 \(3654.120.0.1.13\)) Subject: Re: 13.1R problems on Pi3 From: Mark Millard In-Reply-To: <20220704182526.GB1771@www.zefox.net> Date: Mon, 4 Jul 2022 11:47:23 -0700 Cc: Karl Denninger , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com> References: <20220704003639.GA1165@www.zefox.net> <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com> <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net> <20220704152834.GA1771@www.zefox.net> <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net> <20220704182526.GB1771@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LcFD845cKz4v35 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fmkDfY4L; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-4, at 11:25, bob prohaska wrote: > On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote: >>=20 >> On 7/4/2022 11:28, bob prohaska wrote: >>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote: >>>=20 >>> Can any sense be made of the few ping responses obtained when ntp >>> is coming up? It's looks as if something happens after ntp runs >>> that blocks subsequent network traffic, but why starting an outbound >>> ping should partly unblock things is obscure to me. >>=20 >> Yes.?? The odds are reasonably high that there is confusion as to = which MAC >> address maps to which device.?? This implies there's a loop between = the two >> switches (e.g. there is more than one way for packets to get into and = out of >> each said switch to the other) or the two devices are claiming the = same MAC >> address and thus when each "speaks" and performs ARP it "grabs" the = map >> which works until the next one pipes up and it grabs it. >>=20 >=20 > Looks like that's the problem. There's only one cable between = switches, but > here's what I get from ifconfig on each host: >=20 > On the machine running 13.1-R attached to switch 2: > bob@www:~ % ifconfig > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D680003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21 > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D80009 >>>>>>>> ether b8:27:eb:71:46:4e > inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > bob@www:~ % hostname > www.zefox.org > bob@www:~ %=20 > bob@www:~ % uname -a > FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE = releng/13.1-n250148-fc952ac2212 GENERIC arm64 > bob@www:~ % >=20 > On the machine running an updated stable/13 system attached to switch = 1:=20 > bob@pelorus:~ % ifconfig > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D680003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21 > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D80009 >>>>>>> ether b8:27:eb:71:46:4e > inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > bob@pelorus:~ % hostname > pelorus.zefox.org > bob@pelorus:~ %=20 > bob@pelorus:~ % uname -a > FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #6 = stable/13-n251601-2353343b324: Sun Jul 3 21:43:04 PDT 2022 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >=20 >=20 > Thinking it over, I added the extra switch some time ago and didn't=20 > immediately notice any problems. Both Pi3s started out on the first > switch (NetGear), with no obvdious problems. Later I probably moved=20 > one Pi3 to the second switch (D-Link) and started to notice troubles.=20= > Does this story make sense?=20 >=20 >> Each interface device from the factory is supposed to have a unique = MAC >> address.?? This can, for most interfaces, be overridden (modern = Android >> phones "randomize" it if told to as a "security" measure) but for = obvious >> reasons doing that can lead to problems. Collisions where multiple = devices >> are using the same MAC will lead to exactly the sort of thing you're = seeing >> because the switch is sending the packets to the wrong place. >>=20 >> I've got a decent number of Pis of everything back to the "2" here = and most >> of the time several of them are on my network at once.?? I've not = seen this >> problem but I wouldn't exclude that both are claiming the same MAC = and, if >> so, that's what's causing the problem. >>=20 > [example ifconfig output snipped] >>=20 >> That MUST be unique on your LAN; the prefix (first three octets) is a = vendor >> code /*and the last three should never be duplicated by a vendor. = */If you >> are not setting it in /etc/rc.conf or elsewhere and there /are = /duplicates >> then a very bad thing happened when those units were manufactured -- = set one >> of them to something else. >>=20 >=20 > Any pointers to MAC-setting methods appreciated..... My example is not the best fit because it is for DHCP but in /etc/rc.conf I use (but showing "??"s): ifconfig_dwc0=3D"ether ??:??:??:??:??:?? DHCP" to avoid its random assignment at power up. So for you I would guess: ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask = 255.255.255.0" =3D=3D=3D Mark Millard marklmi at yahoo.com