From nobody Mon Jul 04 20:29:59 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 5910E1CF8366 for ; Mon, 4 Jul 2022 20:30:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4LcHVW1jkFz3MlF for ; Mon, 4 Jul 2022 20:30:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656966604; bh=NQn5Po4irgQUllBcv69at8Ea420J0BagA6TdDRntL+g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ftVNHM8ueJLy/x+m9Ie2NL5qI+JN+wmcNDbnJdNI+LHwkqNDurFcjn4EaFHPrtkQf/tqOlwI8X6UsnCPZI0pfXdxeXbRZpJqjPS0E/eIXTMw1neqLVweygfW9tP6bupyDofNVJIrgviuCEKgM/gBInHwBZg6ydlR1VGOWMooJpQqouxKb4V1jnyU9jBZhUcEvpUoKSi6mk6b/Njj4dXfm5jINCW4hwI7C5AAqMMNcaIoDl4o8vmJ886civiYTAeca+DXWSwe+px2KtKXwDC2brx/NPjk0594kSQwZB3oJcQFAWEmUh+CS+u45JUwCfeFhnaWlbduk7JjBXTbWN9OdA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656966604; bh=JGln6mTSCJs0kLgO1DQ2ztkceXxYsltq7LQMyWPndY1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QupEMW+w29mSnqN0fX88o9bDzJhuOFTg13A8hNMoG7YJKaHFe2fQgW1+jyFyFiGtFA9fx2brTqawRSCInivof3PoN6qmEUXMeLntBx+mk6Y/K9zNyqVoMsFkA2L7BASduXDcBqsnptgO5QieDR+Bpwo6+uGPts7qfICBz0ITY1qLYOlSH9Syq768bthm3jP+unJxvypFBUHDgCLdIKpqOBQV5lvjVJvEV5zjIL/+lqphTaj9RktIL248Ffq0wxmuk9ZcE5huBgtBq08K7VD/oXjrGriwVkQmsGGjrGGPxWeafIJdcLznUfx2g40kZieKAYlra2fXV9dPuf87R8Wvfg== X-YMail-OSG: SNrLOy0VM1nXBtA6Lsd8TDOJbayrgHp4CXzNz0MDoXTdxPT4Ep7aiECEKWTCzGc RJ6bRY.QrE5UbtF8366hbkppxehiZ9EN6JEH3LOgWgOFAxCexBnsmBxmZ_J8JJh.OaXpO9bxjF1d .mRP_xf8cHBHXVd2B6JI5k9SqZUvg_BGmYoUm9A1HPrgOfANFSe3oHjqN8jS9mL6w5d0BPmuH561 zjQJ4cPjQYCLa.Klq2Z4AgvwT6Re_LqDYWrVNjMU.PuO5Hs9I4iP_2cTatMgYh9FEWHt2KXy5tZa vsVTmiifSTKiJmsSUU8F45QwLpF5dTpqtxQbDXQr6e.MOU6OLCFdd7HJMnoeRPiZzBOqP4GlTDOH 7UuF2X27Kf0j5poCywqcdm6EKrl5Mn8sTIdQEhrgsxOfVLasQair0XkCx7fCs8hCg1yw5zDyZqJi M9aey4E._I3OzBMECfCP5WN1kcs9eo3IPe.yeOKqPNbBAwWlMPBZR0x2jStDrnqdZxOcW1tJ.hgR LdwoT0qRBzBdyiAERyvn86izJJKYcCrcEnEZjw5DR1h062wTpPE47HsshBhtOcaypYRlBxxBfCcS 4QAfnwOzavsQZWzeyJt2BQi5bA65OUGBVgCqxvl.srF_MAz8gfoe9bWOBXWdTETb_PQUDUVBXIv8 XDZ1U2k64TWGcwvFksQe30dkZJ_hD8gK4ENmZXFXrORz.y4iSEzm04ogBAGeh1GwOzezvqMBwWWE 3WH4YQwlWBSruH2rwHr5.eCwOC1WP0jX6hyW7tg3Ggpk.aofWptqeXJoQ50WrhQSN4HMsiaUyUsV JiC8RF_3Q_77BnV62nXRUfhnYBhrXNRSpKYn3JTYHXnbMewNai_FbFnbigS.Mw5oN.CdHLzrOjYh oO326ySRehSP6b8.1L8jx8jm923IFeDXiVbtp6ZTmyum5K5n_896fmp8iAzcwmCMuRzeXxMjm7mb 8HHY4e.Pb_W8iKERYkcNxwSHFcW7lu30imdt5__f4JCLg2TnNYa7TqpVCtVWFtg_s6RcZQ_JhXoI WNM2OZbpLjzVYXWaOLSGHLUyuOMnQCXTCApJpqg7BwUaL3cCL1kwK7w6KHpYZGZzfnXS5VSQw5ky bLxrBC62j.s1NSMc.a3dXAljjGBSY7eFwXOWty1Hy9id0SjwzrDVGMoxc3Ef2BFVf4JLf7qOZFsJ VxhXt.Myr8CgkBYQeT3s1lsQ6KCgUlo1JSjUK5BCeERo.hhh316kr9p5LqoJvv61aYQMK6ahyhlb 5NuhOTqrqPVpri0uqPpwPVsUeOe5s0MgzWZIgK2oLuKBark28knjbm2w.h2iugdRfpqdPkfYNRV7 5pSkmHUeDvUYBkZtgzRNTC61QPu0ua3n4nQhjW.S9fSfep5HLCLThzFylk0Ut3.j.fmmb4kUqg4y i7yBRNRv3bwcjVU6vfMSWk25.CUcC5AIxEDTVfJC3yQKmcFDFB0Nyj80d_wX_6FxIq0rNZZFZv4s vV4KhRpnIGUSFH1H2ggMqImv6qUbDMDID2676p3XJky5SwbSwFskiGLcei3UakPVau.EmDNm9r94 Jw8GuU9sqG_AdmGi1nsKQbZ0Y1BLCFzZvg9Xrlp7Xc1yNhC0HD3_RBE2BydK1bZpz6S124nuM1J5 29R7kDS02WPEreynWjMupFQRMiKFRQ5tUaot1jv1_LhLIMDl55T_lD6grRGGvzBhbK0TRfGf0Sak 7Sk5lO67Z8JdD2N5D92DimCs9ONrFHfNkbiv38bk9Dsxa6ZiFp0U0UHyceEYKwtK9cJpHkqMfD46 25xa1eCkD7ChhyMht5dTJmXrqYYFpt9Xf2bdjQA2hNi9dhl8E8J4Yp4mY2MaL7AvF2UhOuVKyPrL EDK4kAlVlfZQXII0yHmT9e9DQ8ooktzvKR91FFZo9eQ0VlLr28Z1TwSO19YLyvXUiQUQ7ywbxAYS G34tG_zOnc_1DXzPpev3KCKVIv3mgPJ_OTmO4VcpofcY_cZ0TMO4vqpZNxD_g12qzHohg1izZn9k M2aDlZPjkXH0GbALBBCuG0mhDaz0EXvUPBEWG9EnqtF1slvBfkQLIx_FEnRVNAyj9zD2mhsqZuNv wuEqV0FoaLI1ZIWDyoWzAOT1lWDkU3vSFXJSzZsBgVt4b_vB4duCJdKm3LUYnym_yELwsCjPhlch s9YiM.C5fmyvhYcbxuC6Zc.tYx3UnSPyDWwjAFmpOzzPOO4GD3WH8QlpOu_FnD5hPp99QwogLMsu nukoGHhLELk5vW80SPbmSc5N62tqLTvEEvzJ6TRKMCDNtekxddsmLjKPPgD68TAgqAaTUGIU3r21 LKnL8PRI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Jul 2022 20:30:04 +0000 Received: by hermes--production-ne1-7864dcfd54-dxcrc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 45ce5fddcd8a01ee04aa87ef736860a1; Mon, 04 Jul 2022 20:30:01 +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: <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com> Date: Mon, 4 Jul 2022 13:29:59 -0700 Cc: Karl Denninger , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8755F460-D5A5-4ED1-857F-37B894A9B875@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> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LcHVW1jkFz3MlF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ftVNHM8u; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.61 / 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)[]; NEURAL_SPAM_SHORT(0.89)[0.887]; 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.65.31:from]; 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 [This ends with a possible config.txt way to control the default Ether MAC address used, independent of which OS happens to be running. Possibly better than using the only-FreeBSD technique.] On 2022-Jul-4, at 11:47, Mark Millard wrote: > On 2022-Jul-4, at 11:25, bob prohaska wrote: >=20 >> 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 Did you get the two RPi3*'s in the same purchase? Ending up with 2 that both happen to have b8:27:eb:71:46:4e seems odd unless possibly the means of setting the values at the factory was not varying the values like it should in some production lot (or over some range of lots). Independent purchases at different times would make it seem even odder. >> 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..... >=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. "its": a Rock64, not a RPi* . > So for you I would guess: >=20 > ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask = 255.255.255.0" >=20 Of course, I listed a specific inet of yours. It appears that for before the RPi4B* based RPi*'s, the serial number and the mac address were related. =46rom the network booting material at: = https://www.raspberrypi.com/documentation/computers/remote-access.html#eth= ernet-mac-address there is: QUOTE Ethernet MAC address Before configuring network boot, make a note of the serial number and = mac address so that the board can be identified by the TFTP/DHCP server. On Raspberry Pi 4 the MAC address is programmed at manufacture and there = is no link between the MAC address and serial number. Both the MAC = address and serial numbers are displayed on the bootloader HDMI = diagnostics screen. To find the Ethernet MAC address: ethtool -P eth0 To find the serial number: grep Serial /proc/cpuinfo | cut -d ' ' -f 2 | cut -c 8-16 END QUOTE You might want to use some variant of RaspiOS to look up the serial numbers and mac addresses on both RPi3*'s: Did you also end up with duplicated serial numbers? Another way to look is to use (in a RaspiOS variant): # vcgencmd otp_dump Row "28:" has the serial number and the last 6 digits should match the last 6 from the MAC address for a RPi3* . Rows "64:" and "65:" together hold the MAC address. Some folks have end up with rows "65:" and "66:" matching, which should not happen but has been associate with odd MAC address results: the MAC address ends up not matching the 6 digits from the serial number, for example. I've found references to an undocumented control in config.txt : force_mac_address=3D??:??:??:??:??:?? See, for example, https://forums.raspberrypi.com/viewtopic.php?t=3D327562 Apparently, force_mac_address controls what value shows up in the device tree for what the ethernet0 alias points to in the device tree. Note that having a odd .dtb file could lead to force_mac_address not working. (The RPi* firmware reads the file and then makes a device tree with some modifications applied.) =3D=3D=3D Mark Millard marklmi at yahoo.com