Re: 13.1R problems on Pi3

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:
>> 
>> 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=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> 	options=680003<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=21<PERFORMNUD,AUTO_LINKLOCAL>
> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	options=80009<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=29<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=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> 	options=680003<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=21<PERFORMNUD,AUTO_LINKLOCAL>
> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	options=80009<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=29<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.....

My example is not the best fit because it is for DHCP
but in /etc/rc.conf I use (but showing "??"s):

ifconfig_dwc0="ether ??:??:??:??:??:?? DHCP"

to avoid its random assignment at power up.

So for you I would guess:

ifconfig_ue0="ether ??:??:??:??:??:?? inet 50.1.20.28 netmask 255.255.255.0"


===
Mark Millard
marklmi at yahoo.com