Date: Tue, 5 Jul 2022 07:02:18 -0700 From: Mark Millard <marklmi@yahoo.com> To: Ronald Klop <ronald-lists@klop.ws> Cc: Karl Denninger <karl@denninger.net>, bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: duplicate MAC - Re: 13.1R problems on Pi3 Message-ID: <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@yahoo.com> In-Reply-To: <1645012198.135.1657014956867@localhost> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 <ronald-lists@klop.ws> wrote: > Van: Mark Millard <marklmi@yahoo.com> > Datum: maandag, 4 juli 2022 20:47 > Aan: bob prohaska <fbsd@www.zefox.net> > CC: Karl Denninger <karl@denninger.net>, freebsd-arm@freebsd.org > Onderwerp: Re: 13.1R problems on Pi3 >=20 > On 2022-Jul-4, at 11:25, bob prohaska <fbsd@www.zefox.net> 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<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:~ % > > 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<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:~ % > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6B24FF55-7010-40ED-B32B-AA46F0E7ED80>