Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Jul 2022 12:17:15 -0400
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: 13.1R problems on Pi3
Message-ID:  <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
In-Reply-To: <20220704152834.GA1771@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>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.

--------------ms060007010102000403050003
Content-Type: multipart/alternative;
 boundary="------------pZn6rSC5SACFA7MTSHN0ugNj"

--------------pZn6rSC5SACFA7MTSHN0ugNj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


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]/
--------------pZn6rSC5SACFA7MTSHN0ugNj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 7/4/2022 11:28, bob prohaska wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20220704152834.GA1771@www.zefox.net">
      <pre class="moz-quote-pre" wrap="">On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
This is crossbuilt but...

$ uname -v
FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May?? 6 10:47:17
EDT 2022 <a class="moz-txt-link-abbreviated" href="mailto:karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC">karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC</a>

$ 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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap=""> 
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.  </pre>
    </blockquote>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>Check here:</p>
    <p>$ ifconfig ue0<br>
      ue0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt;
      metric 0 mtu 1500<br>
              options=80009&lt;RXCSUM,VLAN_MTU,LINKSTATE&gt;<br>
              <u><b>ether b8:27:eb:4e:88:64</b></u><br>
              inet 192.168.10.214 netmask 0xffffff00 broadcast
      192.168.10.255<br>
              inet6 fe80::ba27:ebff:fe4e:8864%ue0 prefixlen 64 scopeid
      0x2<br>
              inet6 2600:6c5d:5d01:8600:ba27:ebff:fe4e:8864 prefixlen 64
      autoconf<br>
              media: Ethernet autoselect (100baseTX &lt;full-duplex&gt;)<br>
              status: active<br>
              nd6
      options=23&lt;PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL&gt;<br>
    </p>
    <p>That MUST be unique on your LAN; the prefix (first three octets)
      is a vendor code <i><b>and the last three should never be
          duplicated by a vendor.  </b></i>If you are not setting it in
      /etc/rc.conf or elsewhere and there <i>are </i>duplicates then a
      very bad thing happened when those units were manufactured -- set
      one of them to something else.<br>
    </p>
    <div class="moz-signature">-- <br>
      Karl Denninger<br>
      <a href="mailto:karl@denninger.net" class="moz-txt-link-freetext">karl@denninger.net</a><br>
      <i>The Market Ticker</i><br>
      <font size="-2"><i>[S/MIME encrypted email preferred]</i></font></div>
  </body>
</html>

--------------pZn6rSC5SACFA7MTSHN0ugNj--

--------------ms060007010102000403050003
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk
YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB
MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz
NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX
MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW
ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B
3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI
XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi
WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb
NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM
qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5
CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l
y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY
2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE
MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV
HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD
bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV
HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5
c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz
dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs
QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj
7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn
3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6
Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g
3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG
7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp
mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi
Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y
W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c
5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit
oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx
GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl
MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO
XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMjA3MDQxNjE3MTVaME8GCSqGSIb3DQEJBDFCBECusMg3SxkUyj7sWZPX
L1VCEjCvRtlyZHLpvoLH0FefBA1qiljGjg4KPGDKtNbgfBryqfk2jEjBHZ7b/MRl6s8jMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ
MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw
IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d
Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y
aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg
Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgC7sJbHrU/l3twgeWeE1BWsd7cIdIQvTfVO2wq7
ZIkvgy7S/5Td0o3jB649M+1MjzHnDULhKq9TYZ+2YxauSUA/YfI87++g7M7HdJj0yZpGs3Hy
hc0681b9hzuj65qL83F6x46YiIuYTS8ppnbImGcIKZHa1UJe6JFcIzmwxykX8HXzoF7CNfqx
+9TsqnLU36UDKUSZz2FBErBTCub/YzzVcHwUWG5iWtbrBfppkRkvXC+jMQguQMxX5KdLMk4o
Vu9jQOEbTHS3VcaR0KS21qQGDTCBmNNZynTxKV622FMnHzK7PIjnBhYQSx/09yIZCv+g49m/
p51Xl3qh1HdW9/iKSmJIu2ZuYFFdKM+MhdXfCwyzBLQcZfvTPjNpflY4Mtw6ckCtC0CntF8L
gy1RBzoW7tYo2MZ5IJ9i805Gbq8ACy6QcGlfFvs8Mz5uN5JzyC5ZpnM+/Xgfcce4SnhD5jA2
ATQ0vxoW1Zs/3caqMSvoVjF42OdaYZTUj3c3scaztP6rpgt/SKUaKU6Md+rD3/nj6VrMgkYI
XSzZgrLM5MsQIUON/P50193TRI0gp0In6lqnhNrfts3tzgl4LFFq5aYHY524I05SH/AjnLcm
UFWXGbdkhCcysGWcL4MctWmTDZkQoYxv4fXUm+6x1y8Ga9aZXrZMxhTYHd3KU+BGSWiTRgAA
AAAAAA==
--------------ms060007010102000403050003--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7ce87eef-ded5-8b00-3f11-14407b8af78d>