Re: 13.1R problems on Pi3

On 7/4/2022 11:28, bob prohaska wrote:
> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
>> This is crossbuilt but...
>>
>> $ uname -v
>> FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May?? 6 10:47:17
>> EDT 2022karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC
>>
>> $ uptime
>> 10:27PM?? up 49 days,?? 7:10, 1 user, load averages: 0.14, 0.15, 0.13
>>
>> Ping both for Ipv4 and v6 (along with everything else) works fine.
>   
> That makes it unlikely the omission of DHCP services on my
> machines accounts of lack of ping and ssh response.
>
> 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.

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.

Check here:

$ ifconfig ue0
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
_*ether b8:27:eb:4e:88:64*_
         inet 192.168.10.214 netmask 0xffffff00 broadcast 192.168.10.255
         inet6 fe80::ba27:ebff:fe4e:8864%ue0 prefixlen 64 scopeid 0x2
         inet6 2600:6c5d:5d01:8600:ba27:ebff:fe4e:8864 prefixlen 64 autoconf
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active
         nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

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.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/