Date: Mon, 4 Jul 2022 11:47:23 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Karl Denninger <karl@denninger.net>, freebsd-arm@freebsd.org Subject: Re: 13.1R problems on Pi3 Message-ID: <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com> In-Reply-To: <20220704182526.GB1771@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-4, at 11:25, bob prohaska <fbsd@www.zefox.net> 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<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 > options=3D680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL> > ue0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu = 1500 > options=3D80009<RXCSUM,VLAN_MTU,LINKSTATE> >>>>>>>> ether b8:27:eb:71:46:4e > inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > 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<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 > options=3D680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL> > ue0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu = 1500 > options=3D80009<RXCSUM,VLAN_MTU,LINKSTATE> >>>>>>> ether b8:27:eb:71:46:4e > inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?212C86C0-17DB-45F5-A59D-8BDC1932378E>