Sagen wir mal so, imho sieht’s jetzt deutlich besser aus:
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.