From nobody Tue Jul 05 14:02:18 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 8265E1CF8537 for ; Tue, 5 Jul 2022 14:02:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (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 4LckrZ1snpz3jtP for ; Tue, 5 Jul 2022 14:02:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657029741; bh=Tu436f7wYjKa5i9PKcuBVcIPUURtLopLzIHAfyf91ak=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tuZEs3lelQPYmsSK/i6sWz3gQlQ86hPNxu9JjVd48a8OnYhYaHEXt7RFilfdxqWDN9+Z8qyErztAxPB4GyWwKm4r8/x21PojsuPjmv2PI+HI1d+vzmsiV3WavzGKvyPcV9tcFj+QCN88GBPQJa9V4ysAleTdlqn7IAucKNbzQ9URX9J4ZoZiYpLH9JVXw3YRDXf/Zb4dj2DQt7lo9Rs3WwMO696ZhXBlppTIEA3/l45H+nmddhJwACJksBnBl3b0K9gz2aAom97jlF/7VEAT/kTr2hSCDrM9mhUHo216GNwaQ3rKiysR+r7oJdXnknVNYNSdLi9+PLg1yCuWWpX3Vg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657029741; bh=v+2GYBBIPe6BnUIbjuSqeRIL+qZ12ompP7HO/seb/FK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZXrDonHo3CPSie6SwchXFyfvG6KchCpYxAEy7oOQMalXMrpA9w+HsTjLSjWxoC1W75CKIahH77064ltiMa2gP7J1E36jd1IoKB2LsXo9kO/E2cWR3Um42MeBOX1VSMOsdGC3bA9LNGAV9u0rDocaIdltBnzL+XJ0Q4JHA620k/E50QBHrDBWfEx8nde64BIDt3WSXwhcHIP9zhe6RZDauJJ0wvqSdXV+CyKfYj1rCtXOI+XIEAdwH4TVYTcmx1WULLsxJpg4FWhrjfrtUQ0mBTM8/Rkumex4dy/fl/QqGwqRLC4VXbPfvag1CAhAeO+sMQc18u1CDA1wWJTwHLz+rw== X-YMail-OSG: oblnvqcVM1kjfV2tiK6.SdVpWs_60wgjg5EiToDEG55h5efqA843MR8A6OIInPV SiWy4e4FSqgKENAFb7gaRu2Z2k1Vcv1zkhK.nX_8Qs2NuZh4Vo_j9OH5IW3olBU0M1DwNyWGcR.L 11HW7LGAWK5P22dxTaFpoyFT_hrrp2f211xsQy8l6ZdLv_eBUjBwRslSl3NnfDibXOn8ZGO_0Yn0 .IUNus4jEYBGRgZ2TxC0nQ6x_qQbWYOjMnUc7rVbVTtEtTy9lAjwRkw6R9wFDNStQYVyk6MFg1Gz CUfPoT0dluvkZPEx7HS1xFaW9vO0Ljb1RIkS47KYl_rbEaxzD3gb4ZStRsU3fMcUdiGs13HES5mk v3.RBYIZs_Vb4i.zyzljKC0kI_x2CWuv6iARW86Mtb3HZDNjKoy5qm9OpX9fyO1V2Qaf1_qo7Pkt 9zKGJUCo2AnlABOadS_DbOXyIiNp9IjqY3J3.X0_o514Zr5RMvLQB.8_It.T2I6U5GLkOeWLbuUl yZSeqJpVHI4_tZQmUQ12Np9wJ67KFgvHIEUIwnFk74vo4RoQsmT9u5ZW_jTBxUXk.J6jvtiN4lIN CBWphd2GKVGhDQ9ji0ihXSBPB942B5B.clnJrkTKjrt6Sf_0my._Eskey6azpDrLGVaG3o3ZAdhR tRJKpRDgEUtBULGTBjpVo0rBfDujJ7Kwgjs0p4pd.bwPTYSDWx6PXj4X3iPr7o2ImTcpRK6c1yDE hqaVPX_JCAVXIOjaKbADf7KTgE.nlZd7XN7MMr8wxlM97yR.J4zzr1y_rF7OeXsqOm_s9p.CSui7 X0VMdq.AcQiqH3fISQ06SREKGjl_vrmZlo1JJjH2LC1iY_KJtOJjRPIQGq1xN4Ket2wIelm5dJZ5 Rg_ZAanq9MIf_iLo1GEG4.kZr9vN7ZQtE6QDB1xdhLA3WIH40O1CqpA0QBXkerXx7WPduZyGD2pC AA5.K0wt__rVZWB17_gAHCO_w1JhWlgGsfXPM1pazz2CXExV72R2ta8C6n2ErABr_IbELmtMlKph I2JPHkjWVKRS51WaMIZOXi9VdsQMpIQShpg.pA1tDI5al7.O4W7aEIdm_WGUPYTqCrnTzGZFjVZk N2mvIhBnUqmEpkn33h43H.ZH2W08hQ429k1.fhu.0ERBwk7itQgEb3O7eJu.DjnjlkBepYYrqUDP _RXjmCWnAqzFYBDrP9J3ZjZUbjcKde363nCq5sCmk0f4pR1IXJX.DAPLNnBohNYV89XU1lPvVpmJ RxeuIqOzK.FIspvTTVgvbJPHLCiOPA5JvXeLky0Zkzzhqs7jnCrXiHxU0sRZFvQpGRIBxRN.RPLC 9onRGdGZ4OMfK95ZdfhWbiCR6yOoW8gu_FnVByMniA5zy1RrgBFR.KnvjwY_MsHhTjv.T7oFfJL9 _9joo.HvTsOUGN6yJ.UYNgI.tUbvOxq.vXYGbKNuUr.gzVeZ7fn6zokC1rX_8ruLLsp0dTXaHN72 jj.E8ulkikrwHk_jN0u_fedLlnnJp8ep_.H5SFDNJ2ljnj3oMkIQhW_zj3wuHgqwjey6GkOK67md IbM3p9TF7xyskqHA33jYOl8l8khZUbpHOWGx1lKQjObr0i1Dq5c1eH0fczwFhWy6ksEQgD_ZKyxL lXCnvhmwNfp95jfJFckGfm3BRDCyA2APHclzh3lRAmYgdfm1_ZhRQZ6HJnRhQVBGYn_R9uiNHOt_ JOJMqVmiGoaqAMLapxvFqJI2zK0I7xWUoqJ6hTQ2UbutC5G6TX1_C703U5pmsAclmfNe4KG1K0ih w31ZTX7n5HZScwsmpNdP.eALLszDhNtOLt7Xgv01Hp0qHeCKaFrpF4p8RM4IqD0ZQrGpEOaoJNTC k8NkJn1M0Y8BxeEGOOBMQ6037WrZeVeG9xb.glyhYtrzGMMQjdjxWbzptrJHT9tOWCAG_2RClzIQ fTE8eJ214ZH0b7BcSB4kokvZADAkjTxKkqs1JdPSijl.4T0QFU0nufH0qINsbl8ORqWZYSCr3SIT YvskE.3Iiom4S04YreqCjnqf7D9Ul0mXjC3OUvfO3tYS8aDo4SZ4KsqO6hqoZQhp5UZYrjUKkxdO sXT8n2rqm4r..3AIEcUqqARu8vjlOuBf.mLqEhTTJgIVCOpYPky7XDUoa32Ja4fi_eypaGDoKezz BLSJlWPnnpa3H0712VcATiP.LQIzieKh0oHeNuFs2j5HH39o1BIxHnw.XPypUUqkuFNc9OdFDRIT o1dNtexUoZSlK0Pz9CEmP2Bwlak.Tjnc6xD98LVvKDoPYBP2sIkCx6W6S4m.2BtSHb.7ruciEBEw Q4Qxk8Z_LXM0ODAIe6vjxKwpyPDELbZDiwyeb96YeDo_eVeENoSGba.woLpRU X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 14:02:21 +0000 Received: by hermes--production-gq1-56bb98dbc7-jzpzw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ef5c3a2dc2b54e76484b8337dba9b5f; Tue, 05 Jul 2022 14:02:19 +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: duplicate MAC - Re: 13.1R problems on Pi3 From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <1645012198.135.1657014956867@localhost> Date: Tue, 5 Jul 2022 07:02:18 -0700 Cc: Karl Denninger , bob prohaska , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@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> <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com> <1645012198.135.1657014956867@localhost> To: Ronald Klop X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LckrZ1snpz3jtP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tuZEs3le; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.19 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.69)[-0.687]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N [It may be that you got your TO: and CC: list a little mixed up. But I was listed as the TO: and Bob P. as a CC: . I'm answering on that basis but Bob P. is one with 2 RPi* that have the same MAC address in use.] On 2022-Jul-5, at 02:55, Ronald Klop wrote: > Van: Mark Millard > Datum: maandag, 4 juli 2022 20:47 > Aan: bob prohaska > CC: Karl Denninger , freebsd-arm@freebsd.org > Onderwerp: Re: 13.1R problems on Pi3 >=20 > On 2022-Jul-4, at 11:25, bob prohaska wrote: >=20 > > On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote: > >> > >> On 7/4/2022 11:28, bob prohaska wrote: > >>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote: > >>> > >>> 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. > >> > >> 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. > >> > > > > Looks like that's the problem. There's only one cable between = switches, but > > here's what I get from ifconfig on each host: > > > > 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:~ % > > bob@www:~ % uname -a > > FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE = releng/13.1-n250148-fc952ac2212 GENERIC arm64 > > bob@www:~ % > > > > On the machine running an updated stable/13 system attached to = switch 1: > > 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:~ % > > 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 > > > > > > Thinking it over, I added the extra switch some time ago and didn't > > immediately notice any problems. Both Pi3s started out on the first > > switch (NetGear), with no obvdious problems. Later I probably moved > > one Pi3 to the second switch (D-Link) and started to notice = troubles. > > Does this story make sense? > > > >> 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. > >> > >> 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. > >> > > [example ifconfig output snipped] > >> > >> 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. > >> > > > > Any pointers to MAC-setting methods appreciated..... >=20 > My example is not the best fit because it is for DHCP > but in /etc/rc.conf I use (but showing "??"s): >=20 > ifconfig_dwc0=3D"ether ??:??:??:??:??:?? DHCP" >=20 > to avoid its random assignment at power up. FYI: The example system that has random assignment is a Rock64, not a RPi* . I got the example line from the Rock64's /etc/rc.conf file in order to show it to Bob P. I do not have such a line on any RPi* that I have access to. > So for you I would guess: >=20 > ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask = 255.255.255.0" >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 > =20 >=20 >=20 > Hi, >=20 > My Rpi3B+ does not have a random MAC on ue0. Niether would the RPi3B that I have access to or any of the other RPi* that I have access to. > NB: It uses the muge driver: > # devinfo | more > ... > bcm283x_dwcotg0 > usbus1 > uhub0 > uhub1 > uhub2 > muge0 > miibus0 > ukphy0 > ... >=20 > Your current MAC is officially from the Raspberry Pi Foundation: = https://hwaddress.com/oui-iab/B8-27-EB/ . Not for a Rock64 --but true of the RPi* that I have access to. > Could you have hardcoded the MAC in a *.dtb file or other config in = the /boot directory and copied that over to the other RPI? Bob P. is the one that reported 2 fixed MAC addresses on two RPI3*'s that are equal (duplicates). I was trying to help him make the machines not present a duplication. > If you are going to assign some MAC yourself take a look at = https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local_(U/L_bit) = to choose a locally administered MAC. I expect that Bob P. will do something like that. =3D=3D=3D Mark Millard marklmi at yahoo.com