irgendwer irgendwo nen loop gebaut?
Hmm …
ffmuer@map:~$ ./find_mac.sh 62:b5:21:8f:eb:c3
62:b5:21:8f:eb:c3 at 201808062239 on 62:b5:21:8f:eb:c3 c4:e9:84:b0:a7:a8 "17192-Gemeindehaus-Kargow-a7a8" 53.506361 12.783583
ffmuer@map:~$ ./find_mac.sh 0a:84:25:2e:2d:4b
0a:84:25:2e:2d:4b at 201808062239 on 0a:84:25:2e:2d:4b 84:16:f9:d9:8f:9e "17194-Tressow-8f9e" 53.62695766 12.66972005
Das klingt nach Brückung (ich seh’ aber keine anderen GWs) oder zwei Clients per gelbem Port verbunden.
EDIT: Ich glaube, das Skript taucht nicht (oder ich raff’ die Ausgabe nicht):
ffmuer@map:~$ ./find_mac.sh 62:b5:21:8f:eb:c3
62:b5:21:8f:eb:c3 at 201808062251 on 62:b5:21:8f:eb:c3 18:d6:c7:51:9b:82 "17192-Martin-Router-King" 53.50892207 12.69160151 ("TP-Link TL-WR1043N/ND v4")
Ich hatte gestern meine CPEs nur 1:1 auf 1.0.0~73 gebracht bzw. bringen wollen. (siehe Firmware 1.0 ).
Diese sind nun wieder auf 0.7.9.0~133, weil ich dachte, die Firmware macht die derzeitigen Probleme. Später vermutete ich auch einen Loop, habe die “Stecker” gezogen und die CPEs nur per Mesh on IBSS und VPN erlaubt (zurzeit kein LAN/WAN). 
Die Situation hat sich danach aber auch nicht gebessert.
“17194-Tressow-8f9e” hängt in der Garage - nur Strom.
“17192-Gemeindehaus-Kargow-a7a8” ist auf dem Dach des Gemeindezentrums und sollte über ‘Mesh-on-WAN’ mit “17192-Gemeindehaus-Kargow” (GELB ‘Mesh-on-LAN’) verbunden sein.
Sonntag Abend ist dort i.d.R. keine Party, wo ‘Streiche’ gespielt werden könnten.
Bei den CPEs war das vor v2016.1 in der Tat ein Problem, da stimmte irgendwie das MAC-Munging nicht. Aber das sollte längst gefixt sein (und mit dem Rückschritt auf 0.7 der Spuk vorbei) …
Hmm, geht vielleicht die Einstellung Mesh-on-LAN/WAN beim Upgrade flöten? Wild guess, paßte aber zum Symptom? Kannst Du gucken, ob MoL wirklich noch aktiv ist?
Beim Upgrade von 0.7.9 nach 1.x und zurück übernehme ich i.d.R. keine Konfiguration … alles wieder zu Fuß 
und die Knoten in “17192-Gemeindehaus-Kargow” hatten keine Upgrades bekommen.
Meine Knoten sind erstmal OFFLINE. Strom sparen.
Morgen früh, wenn der Hahn kräht und die Motorsense vom Nachbarn knattert, schalte ich die Knoten wieder an … falls es doch an denen liegen sollte 
Ich hab den Knoten gefunden: 17194-Tressow-43dc
Nachdem dieser im Netz war, kamen wieder diese Fehler …
Mon Aug 14 04:50:41 2017 kern.warn kernel: [ 734.530000] br-client: received packet on bat0 with own address as source address
Mon Aug 14 04:50:46 2017 kern.warn kernel: [ 739.450000] br-client: received packet on eth0.2 with own address as source address
Den werde ich mir heute wohl 
genauer anschauen müssen.
Sorry. Matthias.
1 „Gefällt mir“
Hmm, 'ne CPE, mit CPE hing auch das Gluon-Issue zusammen …
Evtl. hängt das mit der „stabilen MAC“ zusammen, muß ich die Tage mal mir genauer ansehen.
Ich könnte den Knoten mit TP-Link-Firmware flashen und wieder zurück nach Freifunk.
… oder ist die “fehlerhafte” MAC jetzt fest in die Hardware “gebrannt”?
Du schriebst, glaube ich, Du hättest CPEs mit ohne Konfigübernahme auf 1.0 hochgebracht? In dem Fall sollte das eigentlich “durch” sein, da im 1.0er Image da derzeit nix geändert wird. Alles sehr sonderbar.
-kai
Ich habe 17194-Tressow-43dc nochmal neu aufgesetzt und habe mitbekommen, dass wieder das Netz blockiert wurde. Nun habe ich in der Hektik den falschen Stecker gezogen. Die nächsten 3 Stunden ist mir das nicht aufgefallen nur als ich in dem Konfig-Modus den Nachbar-CPE (17194-Tressow-dd3a) sah.
In den Logfiles der anderen Knoten habe ich keine Auffälligkeiten gesehen und habe 17194-Tressow-dd3a normal starten lassen.
Ergebnis: 
Rumms … Netz bei mir sofort unbenutzbar.
Die Geräte nochmal jeweils getrennt laufen lassen … alles OK.
Beide Zusammen … Nicht gut. Nicht gut. Nicht gut.
Bis zu der Stelle, wo beide Geräte zusammen die Firmware 1.0.0~7* hatten, lief alles wie es sollte. Danach ist aus derzeitiger Sicht egal mit welcher Firmware kein Zusammenspiel mehr möglich. 
Ursache gefunden: Vergessene LAN-LAN-Kopplung ohne Mesh-on-LAN bei den CPEs.
Sorry. Ich sollte mich vielleicht doch auf meinen Urlaub konzentrieren 
und mal 
zählen.
Danke für’s Update mit der Aufklärung!
Dann war die Diagnose LAN-LAN-Kopplung ja richtig, auch gut zu wissen 
Hallo Kai.
was sagt mir diese Statistik?
Dass seit einigen Tagen Alfred zu bestimmten Zeiten keine Daten verarbeiten kann?
Auswirkungen auf die Stabilität habe ich keine festgestellt. Irritiert bin ich nur durch diese „Regelmäßigkeit“. 
Das sieht schon schräg aus, da gebe ich Dir recht. Für ein sauberes Multi-Domain-Setup (gut, gt8, gto, rhw; wrz; fsl; zzz) braucht’s eh’ 'nen neuen Meshviewer. Ich würde dort dann von push auf pull (statt alle Knoten pusten periodisch für Alfred auf ein Datensammler fragt periodisch per Multicast alle Knoten, Daten zu schicken) umstellen und den guten Alfred in Rente schicken …
Aber komisch, seit Sonntag immer kurz vor und kurz nach 6 Uhr morgens?
Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.