Mehrminütiger Ausfall im 60 Minuten-Takt

Wurstkanone · 30. April 2024 um 11:39

Hallo Zusammen,

wie es bereits von Thomas vor ein paar Tagen gemeldet wurde, habe auch ich mit zwei Knoten immer wiederkehrende Störungen, bzw. Komplettausfälle in kurzen Abständen.

Es ist mir leider nicht erlaubt mehre Screenshots hier anzuführen. Deswegen füge ich sie in einzelnen Antworten auf den Beitrag hier ein.

Thomas Beitrag

Meine betroffenen Knoten:

33397-Speckenstr-4-a285
Standort Mastholte (Rietberg)
AVM FRITZ!Box 4040
33449-Gruener-Weg-6-3e0b
Standort Bentler (Langenberg)
AVM FRITZ!Box 4040

Grundproblem

Alle 60 Minuten verlieren ich bei beiden Standorten die Verbindung zum Freifunk Netz.
Das stellt sich dann im konkreten Fall so dar, dass keine Endgeräte (Notebook, Handy, usw.) mehr eine IP-Adresse im Freifunk-Netz 10.234.160.0/20 bekommen.
Dort wird dann nur eine APIPA (169.254.0.0/16) vergeben.

Der Zeitpunkt, an dem sich das Problem zeigt, ist in beiden Standorten nicht der gleiche. Das unterscheidet sich.

33397-Speckenstr-4-a285

Immer kurz vor der vollen Stunde Stunde jeweils zu HH:57:XX. Also 11:57, 12:57, 13:57 usw.

33449-Gruener-Weg-6-3e0b

Alle 60 Minuten exakt zu HH:30:XX. Also 10:30, 11:30, 12:30 usw.

Das sorgt dafür, dass alle bestehenden Endgeräte die Verbindung verlieren und keine neuen Geräte eine Verbindung aufbauen können.

Die Dauer des Ausfalls unterscheidet sich immer. Mal dauert es 10 Minuten und Mal auch 45 Minuten. Da der Fehler exakt wiederkehrend ist, kann es somit auch mal sein, dass das Freifunk-Netz in einem Zeitfenster von 120 Minuten vielleicht 2 x für 20 Minuten funktioniert.

Genaues Fehlerbild

Freifunk-Oberfläche

So siehts in der Freifunk-Oberfläche aus, wenn der Ausfall stattfindet.

Freifunk-Grafana

An dieser Grafik sieht man gut, dass immer im Bereich, in denen eine grüne waagerechte Linie entsteht, genau zu dessen Beginn der Ausfall stattfindet.

Bild-Freifunk-Grafana

Log einer Firewall

Gleichzeitig sehe ich in der Firewall beider Standorte zum Moment des Ausfalls, dass der Freifunk-Router versucht den lokalen IP-Adressbereich des Freifunk-LANs über sein eigenes Gateway, also meine Firewall zu erreichen.
Das geht natürlich nicht. Muss aber auch nicht.

Ob das der Auslöser des Problems ist oder eine Folge dessen, kann ich nicht sagen.

Der Ausfall und diese Log-Ereignisse, passen auf jeden Fall immer hundert prozentig zusammen.
Bild-Firewall

Auswertung mit Messgerät im Standort »33397-Speckenstr-4-a285«

Achtung dieser Screenshot bezieht sich nun auf den anderen Standort. Also bitte nicht wundern, warum das jetzt nicht mehr um halb, sondern idr. zu den vollen Stunden passiert.
Ich habe das Messgerät nur in einem Standort und hatte die Screenshots oben dummerweise vom andern Standort gemacht.
Spielt aber keine Rolle, da es an beiden Standorten das Gleiche ist.

Mit dem Netzwerk-Messgerät, kann ich feststellen, dass genau zu den Momenten keine Verbindung mehr hergestellt werden kann, da man keine IP-Adresse mehr per DHCP bekommt.

Alle roten Balken auf dem Diagramm unter Status sind solche Momente.
Unter dem Balken sieht man auch nochmal in Schriftform, wann genau die Ausfälle stattgefunden haben.

Bild-Messgerät

Auch hier passen die Zeitpunkte wieder 1zu1 zusammen.

Dieses Messgerät kann per angeschlossenem Netzwerkkabel oder per WLAN testen.
Die Probleme traten in beiden Fällen exakt zum gleichen Zeitpunkt auf.

Auftreten der Probleme

Ich kann nicht genau sagen, wann die Probleme begonnen haben, doch sie müssen schon seit locker 2-3 Monaten so bestehen. Ich bin leider jetzt erst dazu gekommen mir das mal richtig konkret anzusehen.

Ich würde mich über reichliches Feedback freuen.

Wurstkanone · 30. April 2024 um 11:40

Bild-Freifunk-Grafana

Wurstkanone · 30. April 2024 um 11:41

Bild-Firewall

Wurstkanone · 30. April 2024 um 11:42

Bild-Messgerät

wusel · 30. April 2024 um 13:34

Wichtig wäre zu wissen, zu welchen Gateways sich die Knoten jeweils a) verbunden hatten und b) danach neu verbunden haben. Stündlich klingt ja eher nach GW-Reboot (ist aber an sich nichts dergleichen konfiguriert) denn nach Routingproblem.

wusel@victor:~$ for i in $(seq 1 6); do host g$(printf %02d $i)m02.4830.org. ; done
g01m02.4830.org is an alias for l2tp-ber01.4830.org.
l2tp-ber01.4830.org has address 193.26.120.99
l2tp-ber01.4830.org has IPv6 address 2a06:e881:1706:1:0:c1ff:fe1a:7863
g02m02.4830.org is an alias for l2tp-fra01.4830.org.
l2tp-fra01.4830.org has address 193.26.120.227
l2tp-fra01.4830.org has IPv6 address 2a06:e881:1707:1:400:c1ff:fe1a:78e3
g03m02.4830.org is an alias for l2tp-ham01.4830.org.
l2tp-ham01.4830.org has address 193.26.120.125
l2tp-ham01.4830.org has IPv6 address 2a06:e881:1702:1:400:c1ff:fe1a:787d
g04m02.4830.org is an alias for l2tp-ham02.4830.org.
l2tp-ham02.4830.org has address 193.26.120.245
l2tp-ham02.4830.org has IPv6 address 2a06:e881:2604:42:400:c1ff:fe1a:78f5
Host g05m02.4830.org. not found: 3(NXDOMAIN)
Host g06m02.4830.org. not found: 3(NXDOMAIN)

wusel@victor:~$ for i in $(seq 1 4); do echo -n "g$(printf %02d $i)m02.4830.org ..." ; ssh -A -o ConnectTimeout=10s root@g$(printf %02d $i)m02.4830.org. uptime ; done
g01m02.4830.org ... 14:15:27 up 42 days, 17:29,  0 users,  load average: 1.59, 1.02, 0.94
g02m02.4830.org ... 14:14:59 up 17 days,  8:46,  0 users,  load average: 1.04, 0.69, 0.56
g03m02.4830.org ...ssh: connect to host g03m02.4830.org. port 22: No route to host
g04m02.4830.org ... 12:15:18 up 72 days, 12:40,  0 user,  load average: 0,00, 0,00, 0,00

Oops, g03m02 aka l2tp-ham01 und g04m02 aka l2tp-ham032 wurde schon abgebaut, an sich nicht tragisch, aber auch nicht schön.
Ich habe Mesh 2 nun auf die neuen Gateways umgestellt, DNS-Änderung sollte ca. gegen 16 Uhr wirksam werden. Bitte ab 17 Uhr mal gucken, ob das Phänomen noch auftritt …

Hmm, das sollte eigentlich nicht passieren — die Freifunk-Knoten sprechen an sich kein IPv4, außer über’s WAN zu den Gateways, und beide Netze sind auf dem Gerät getrennt.

Also strenggenommen kann das nicht passieren — das Freifunk-Netz existiert IPv4-mäßig nur in 'ner Bridge auf dem Knoten, in dem auch die LAN-Ports stecken. Der Knoten ist nur mit IPv6 Teil des Netzes; hast Du evtl. das FF-Netz mit Deinem Netz verbunden?

root@33332-Schalueckstr-107-11d9:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-client		7fff.24a43cb111d9	no		bat0
							client1
							owe1
							client0
							owe0
							local-port
br-wan		7fff.66f8112ec108	no		eth0.1
root@33332-Schalueckstr-107-11d9:~# ip addr show br-client
90: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 24:a4:3c:b1:11:d9 brd ff:ff:ff:ff:ff:ff
    inet6 2001:bf7:1310:128:26a4:3cff:feb1:11d9/64 scope global dynamic noprefixroute 
       valid_lft 86387sec preferred_lft 14387sec
    inet6 fd10:ca1:1:0:26a4:3cff:feb1:11d9/64 scope global dynamic noprefixroute 
       valid_lft 86031sec preferred_lft 14031sec
    inet6 fe80::26a4:3cff:feb1:11d9/64 scope link 
       valid_lft forever preferred_lft forever

wusel · 1. Mai 2024 um 00:01

@Wurstkanone und @Thomas, hat der GW-Wechsel was geändert? (Die Sichtbarkeit der Knoten auf den neuen GWs auf map03.4830.org ist aktuell in der Mache.)

wusel · 2. Mai 2024 um 00:57

Ping, @Wurstkanone, @Thomas?

Wurstkanone · 2. Mai 2024 um 09:25

Also die getesteten WLAN-Endgeräte verbinden sich nun mit dem Gateway »10.234.160.81«.
Doch ich denke das war nicht die Antwort die du haben wolltest.

In der Firewall kann ich sehen, dass die Freifunk-Knoten auf WAN-Seite die folgenden Verbindungen aufbauen.

Log comp	Log subtype	Src IP	Dst IP	Src port	Dst port	protocol	Message

Firewall Rule	Allowed	10.35.150.5	1.1.1.1	36517	53	UDP
Firewall Rule	Allowed	10.35.150.5	1.1.1.1			ICMP
Firewall Rule	Allowed	10.35.150.5	9.9.9.9	56108	53	UDP
Firewall Rule	Allowed	10.35.150.5	9.9.9.9			ICMP
Firewall Rule	Allowed	10.35.150.5	87.253.188.148	56746	80	TCP
Firewall Rule	Allowed	10.35.150.5	194.113.54.82	45417	10002	UDP
Firewall Rule	Allowed	10.35.150.5	194.113.54.86	41234	10002	UDP
Firewall Rule	Allowed	10.35.150.5	194.113.55.73	56996	10002	UDP
Firewall Rule	Allowed	10.35.150.5	194.113.55.74	54932	10002	UDP
Invalid Traffic	Denied	10.35.150.5	10.234.160.75			ICMP	Invalid packet, no ICMP record found.
Invalid Traffic	Denied	10.35.150.5	10.234.160.81			ICMP	Invalid packet, no ICMP record found.
Invalid Traffic	Denied	10.35.150.5	10.234.160.82			ICMP	Invalid packet, no ICMP record found.

Das sind alle Verbindungen der letzten 6 Stunden.
DNS ist klar, dann kommen die Verbindungen, die den Zugang zum Freifunk-Netz erlauben und zum Schluss die Verbindungen, die ich im ersten Post schon aufgeführt hatte, die etwas komisch sind.

Wie kann ich alternativ das Gateway auslesen, mit dem die verbunden sind?

Wurstkanone · 2. Mai 2024 um 09:29

Also es scheint so, als wenn sich das Gateway der WLAN-Endgeräte geändert hätte.
Vorher was das Gateway für die Endgeräte 10.234.160.4
Nun ist es 10.234.160.81

Zum Problem mit den andauernden Ausfällen, kann ich gerade noch keine Entwarnung geben. Sieht erstmal so aus, als wenn es nix gebracht hätte, aber ich versuche den Fehler die nächsten 2 Tage etwas genauer einzugrenzen.

Gestern am 1. Mai wurde das Freifunk-Netz nicht oder kaum genutzt.

Wurstkanone · 2. Mai 2024 um 09:36

Also der LAN-Port der FF-Fritzbox wird aktuell so genutzt, dass dieser auf ein eigenes VLAN auf einem Switch geht um somit ein paar weitere PCs außerhalb der Reichweite der Fritzbox mit Freifunk zu versorgen.
In diesem VLAN werden sonst keine anderen Subnetze betrieben. Es ist nur für das Freifunk-LAN da.

wusel · 2. Mai 2024 um 11:04

Richtig vermutet Mich interessiert, ob das initiale Problem – »Mehrminütiger Ausfall im 60 Minuten-Takt im Bereich Rietberg« – nun weg ist.

Das Default-Gateway ist immer abhängig vom gewählten GW. Das letzte Oktet ist die interne VM-Nummer, …

root@aux03:~/deploy_ffgt_20240203/ffgt-ansible/host_vars# ./list_server_ids.sh  | grep 81
 81 (0x51) ngw-fra03

… also hängt Dein Knoten nun an ngw-fra01.4830.org.

Auf dem Knoten per SSH einloggen und batctl gwl ausführen.

That’s … odd.

wusel · 2. Mai 2024 um 17:33

AFAICS ist das Problem in Mesh 02 nicht mehr existent (Linux-VM hinter Gluon-VM, DTAG VDSL, konfiguriert ins Mesh 02):

wusel · 2. Mai 2024 um 20:19

Sprach’ er und schon isses da Was zum Fick …?

Edit: syslog des Knotens wird nun extern gesammelt …

Wurstkanone · 3. Mai 2024 um 06:02

Hallo Wusel,

also ich habe jetzt gerade keine Probleme mit den beiden Freifunk-Knoten, bin aber eigentlich auch noch in der Fehlerfindungsphase.
Ich werde das dieses WE beobachten und melde mich, falls ich noch etwas konkretes entdecke.

Thomas · 4. Mai 2024 um 13:50

Ich habe gestern wo ich das Netz selber genuttz habe keine Stündlichen Ausälle bemerkt. Aber die Zeit muss man auch genau treffen. Wo ich die Zeiten beim letzten mal gefunden habe war es auch eher Zufall.
Aber IPv6 funktioniert jetzt ja auch wieder, so dass ich an meine Raspberry in Rietberg immer dran komme. Ich beobachte es.

Thomas · 6. Mai 2024 um 18:19

Sie wurden von hinten erschossen

Ich glaube ich habe den Fehler!

root@33378-a42bb0f43a87:~# /usr/sbin/autoupdater-wifi-fallback
autoupdater-wifi-fallback: connectivity check failed
autoupdater-wifi-fallback: going to fallback mode
autoupdater-wifi-fallback: connecting to radio0 KreisGT.freifunk.net 7E:8A:20:28:73:CB
autoupdater-wifi-fallback: executing the autoupdater…
Retrieving manifest from http://firmware.ipv6.4830.org/experimental/sysupgrade/experimental.manifest …
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found
autoupdater-wifi-fallback: connecting to radio1 test-KreisGT.freifunk.net 1E:00:53:42:06:48
autoupdater-wifi-fallback: executing the autoupdater…
Retrieving manifest from http://firmware.ipv6.4830.org/experimental/sysupgrade/experimental.manifest …
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found
autoupdater-wifi-fallback: connecting to radio1 owe.KreisGT.freifunk.net 1E:00:53:42:06:4A
autoupdater-wifi-fallback: executing the autoupdater…
Retrieving manifest from http://firmware.ipv6.4830.org/experimental/sysupgrade/experimental.manifest …
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found
autoupdater-wifi-fallback: going back to standard mode
root@33378-a42bb0f43a87:~#

Nachdem ich den Fehler hier in Wiedenbrück auch immer wieder um ca. Minute 40 hatte und ich heute einen Tag frei hatte bin ich der sache etwas auf die Schliche gekommen.

Die Firmware Seite ist per IPv6 aktuell nicht erreichbar. Das habe ich schon länger gesehen. Aber bisher nicht als problematisch angesehen.

Die Fallback Option ist besonders brsinat im Offloader Einsatz mit VLAN, da zumindestens auf meinem Archer C7 die br-client Bridge zerlegt wird und nachher nicht wieder richtig zusammen gebaut wird. Auf allen anderen Systemen scheint das der Fall zu sein. (Was ich aber noch nicht getestet habe).

Warum passiert jetzt der Fehler überall zu ein anderen Zeit, … Ich habe mir gerade vier Knoten angeschaut. Dort steht überall eine andere Minute drin.

@wusel bitte die Firmware Seite wieder sauber zuänglich aus dem Netz machen. Ich gehe dann davon aus das alles wieder läuft.

Wurstkanone · 16. Mai 2024 um 12:32

Hallo Zusammen,

die letzten zwei Wochen habe ich diverse Tests durchgeführt, um die Probleme etwas genauer einzugrenzen.

Disclaimer
Ich bin in dem Thema Freifunk erst neu dabei. Es mag also vorkommen, dass ich aufgrund fehlender Erfahrung falsche Annahmen treffe.
Macht mich dann einfach darauf aufmerksam.

Ergebnisse meiner Test:

Es ist für mich nachgewiesen, dass diese langfristigen Ausfällen von zwischen 10-45 Minuten des Routers zum Freifunk-Netz nicht auftreten, wenn ich die dahinter geschaltete Umgebung (PCs im VLAN & WLAN-Umgebung) abschalte.
Ich also das Patchkabel aus den LAN-Anschlüssen der Fritzbox entferne.

Nutze ich Freifunk als nur an der Fritzbox, dann scheint es keine Langfristigen Ausfälle zu geben.
Es mag aber sein, dass es kurzfristigere Ausfälle (2-3 Minuten) gibt, die sich meinem Fokus und meinen Prüfmitteln entziehen.

Somit ging ich erst davon aus, dass ich für die Probleme selbst verantwortlich bin.
Ich habe jetzt aber ein paar Stunden in die Prüfung des Ganzen gesetzt und finde keine konkreten Fehler in meiner Umgebung hinter der Fritzbox.

Ich konnte zusätzlich nachvollziehen, dass die Fehler auch nicht auftreten, wenn ich mein geplantes Konzept (WLAN-APS und Clients hinter Fritzbox) ausführe, aber das Freifunk-WLAN mit einem Kennwort versehe.
Damit wollte ich nachvollziehen, ob die Fehler auch auftreten, wenn nur wenige Geräte über den Kabel-Anschluss der Fritzbox kommen.
Ich kann das verneinen und auch bestätigen.
Manchmal kam der Fehler nicht mehr vor (8 angeschlossene Endgeräte per externem AP also per VLAN hinter Fritzbox) und dann aber manchmal doch (Nur vier verbundene Clients am externen AP).

Fazit meiner Tests

Die Ergebnisse ermöglichen mir nicht den Fehler genau zu orten.
Somit habe ich mich auch nochmal mit @Thomas Aussage beschäftigt, was mir auch recht schlüssig vorkommt.

Referenz auf @Thomas Aussage

Ich kann seine Vermutung total unterstützen.
Das deckt sich ziemlich gut mit meiner Umgebung.

Einmal vorweg
Ich habe bislang keinen SSH-Zugang zu den Freifunk-Fritzboxen gehabt, weshalb ich noch keine Tests direkt auf diesen durchführen konnte. Müsste ich mich nochmal dransetzen.

Er sagt ja, dass die URL für das automatische Prüfen der Firmware nicht erreichbar ist und ihm das die »BR-Client Bridge« zerlegt.

Könnte das dann nicht auch erklären, warum die Fritzbox bei mir dann versucht das Freifunk-LAN Gateway »10.234.160.74« dann über seinen eigenen WAN-Anschluss zu erreichen, was natürlich nicht geht.

Zitat von @Thomas
Die Fallback Option ist besonders brsinat im Offloader Einsatz mit VLAN, da zumindestens auf meinem Archer C7 die br-client Bridge zerlegt wird und nachher nicht wieder richtig zusammen gebaut wird.

Ich kann mit meinen Tests z.B. bestätigen, dass der Fehler auch nur bei der Nutzung der Frizbox als Offloader stattfindet.
Das passt also auch ins Bild.

Meine Theorie (Achtung gefährliches Halbwissen)

Ich glaube, dass diese Regelmäßigkeit (Ausfall alle 60 Minuten) daher kommt, dass die Frizbox allen 60 Minuten (nach Systemstart??) prüft ob eine neue Firmware verfügbar ist.
Das schlägt dann aber fehl, da die Firmware-Webseite nicht aufrufbar ist.

Das sollte dann ja eigentlich kein Problem sein, doch irgendwie bricht dann dabei die »BR-Client Bridge« weg und somit besteht keine Verbindung mehr von der FF-Fritzbox zum Freifunk-Netz.

Irgendwann fängt sich der Freifunk-Router dann wieder und zu den nächsten vollendeten 60 Minuten passierts dann wieder.

Ich habe das Gefühl, dass die Intensität des Ausfalls auch irgendwas mit der Anzahl hinterm Offloader angeschlossener Endgeräte zu tun hat.
Als ich eben nur 5 WLAN-Endgeräte hinter meiner Umgebung, also per Kabel an der Fritzbox verwendet habe, konnte ich einen 1-3 Minütigen (Mini-Ausfall) zum üblichen Zeitpunkt feststellen.
Dieser war aber nicht massiv genug, dass der Router in der Freifunk-Oberfläche als Offline angezeigt wurde.
Offensichtlich hat der Router sich dann schnell genug gefangen.

Dass dieses Problem nicht bei allen Teilnehmern des Freifunk-GT-Netzes auffällt, könnte ja an genau diese Kombination liegen.
Nutzung des Routers als Offloader && Notwendigkeit von mehren Geräten hinter diesem.

Erreichbarkeit von firmware.ipv6.4830.org && firmware.4830.org

Wichtige Rückfrage
Habt Ihr heute Vormittag daran gearbeitet?

Eben konnte ich keine Verbindung auf Diensten (443, 80 und PING) per IPV4 wie auch IPV6 auf die beiden URLs hinbekommen.
Mittlerweile ist die Adresse »firmware.4830.org« wieder ganz normal per IPv4 erreichbar.

Test von heute morgen

Fazit

Ich könnte mir jedenfalls auch vorstellen, dass es etwas mit der Erreichbarkeit des Update-Services zu tun hat.
Ich denke, dass es auf jeden Fall einen Versuch wert wäre, dies wieder in Betreib zu nehmen.

m.bitterlich · 19. Mai 2024 um 15:11

Moin.

Heute habe ich den Fehler bzw. er mich „life“ erwischt.
Der Router hängt direkt hinter einer FritzBox(DSL)
Nach dem Fehler braucht er eine Ewigkeit, bis er wieder erreichbar und Freifunk für die Clients nutzbar ist.
Hilf da den Autoupdate zu deaktivieren?

17209-Sietow-Hafen
17209-Sietow-Hafen - StatusPage
Das Gateway war gerade … 02:ca:ff:ee:05:81

Die letzten Zeilen im Logfile waren …

Sun May 19 16:52:00 2024 user.notice ssid-changer: autoupdater is running, aborting.
Sun May 19 16:52:05 2024 user.info : autoupdater-wifi-fallback: connectivity check failed
Sun May 19 16:52:05 2024 user.info : autoupdater-wifi-fallback: going to fallback mode
Sun May 19 16:52:05 2024 kern.info kernel: [24382.503847] IPv6: ADDRCONF(NETDEV_UP): tmp.mesh0: link is not ready
Sun May 19 16:52:12 2024 kern.info kernel: [24389.247681] IPv6: ADDRCONF(NETDEV_UP): tmp.mesh1: link is not ready
Sun May 19 16:52:14 2024 user.info : autoupdater-wifi-fallback: connecting to radio0 mueritz.freifunk.net_EXT A8:42:A1:36:99:55
Sun May 19 16:52:14 2024 daemon.notice netifd: Interface 'mesh_radio0' is disabled
Sun May 19 16:52:14 2024 daemon.notice netifd: Interface 'mesh_radio0' has link connectivity loss
Sun May 19 16:52:14 2024 kern.info kernel: [24391.222973] device client0 left promiscuous mode
Sun May 19 16:52:14 2024 kern.info kernel: [24391.228012] br-client: port 3(client0) entered disabled state
Sun May 19 16:52:14 2024 kern.info kernel: [24391.267371] device owe0 left promiscuous mode
Sun May 19 16:52:14 2024 kern.info kernel: [24391.272266] br-client: port 4(owe0) entered disabled state
Sun May 19 16:52:14 2024 daemon.notice netifd: Interface 'mesh_radio1' is disabled
Sun May 19 16:52:14 2024 daemon.notice netifd: Interface 'mesh_radio1' has link connectivity loss
Sun May 19 16:52:14 2024 kern.info kernel: [24391.361390] device client1 left promiscuous mode
Sun May 19 16:52:14 2024 kern.info kernel: [24391.367620] br-client: port 5(client1) entered disabled state
Sun May 19 16:52:14 2024 kern.info kernel: [24391.444211] device owe1 left promiscuous mode
Sun May 19 16:52:14 2024 kern.info kernel: [24391.450221] br-client: port 6(owe1) entered disabled state
Sun May 19 16:52:14 2024 kern.info kernel: [24391.719535] batman_adv: bat0: Interface deactivated: mesh0
Sun May 19 16:52:14 2024 kern.info kernel: [24391.725897] batman_adv: bat0: Removing interface: mesh0
Sun May 19 16:52:15 2024 daemon.notice netifd: Interface 'mesh_radio0' is now down
Sun May 19 16:52:15 2024 kern.info kernel: [24391.914904] batman_adv: bat0: Interface deactivated: mesh1
Sun May 19 16:52:15 2024 kern.info kernel: [24391.920616] batman_adv: bat0: Removing interface: mesh1
Sun May 19 16:52:15 2024 daemon.notice netifd: Interface 'mesh_radio1' is now down
Sun May 19 16:52:15 2024 daemon.notice hostapd: client0: interface state ENABLED->DISABLED
Sun May 19 16:52:15 2024 daemon.notice hostapd: owe0: AP-DISABLED
Sun May 19 16:52:15 2024 daemon.notice hostapd: owe0: CTRL-EVENT-TERMINATING
Sun May 19 16:52:15 2024 daemon.notice hostapd: nl80211: Failed to remove interface owe0 from bridge br-client: No such device
Sun May 19 16:52:15 2024 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 9a:4b:78:40:da:72
Sun May 19 16:52:15 2024 daemon.notice hostapd: client0: AP-STA-DISCONNECTED aa:69:d6:51:19:b2
Sun May 19 16:52:15 2024 daemon.notice hostapd: client0: AP-STA-DISCONNECTED ae:42:a1:36:99:55
Sun May 19 16:52:15 2024 daemon.notice hostapd: client0: AP-DISABLED
Sun May 19 16:52:15 2024 daemon.notice hostapd: client0: CTRL-EVENT-TERMINATING
Sun May 19 16:52:15 2024 daemon.notice hostapd: nl80211: deinit ifname=client0 disabled_11b_rates=0
Sun May 19 16:52:15 2024 daemon.notice hostapd: nl80211: Failed to remove interface client0 from bridge br-client: Invalid argument
Sun May 19 16:52:15 2024 daemon.notice hostapd: client1: interface state ENABLED->DISABLED
Sun May 19 16:52:15 2024 daemon.notice hostapd: owe1: AP-DISABLED
Sun May 19 16:52:15 2024 daemon.notice hostapd: owe1: CTRL-EVENT-TERMINATING
Sun May 19 16:52:15 2024 daemon.notice hostapd: nl80211: Failed to remove interface owe1 from bridge br-client: No such device
Sun May 19 16:52:15 2024 daemon.notice hostapd: client1: AP-STA-DISCONNECTED 12:64:22:25:0d:08
Sun May 19 16:52:15 2024 daemon.notice hostapd: client1: AP-STA-DISCONNECTED aa:69:d6:51:19:b2
Sun May 19 16:52:15 2024 daemon.notice hostapd: client1: AP-STA-DISCONNECTED f2:14:0b:37:a9:99
Sun May 19 16:52:15 2024 daemon.notice hostapd: client1: AP-STA-DISCONNECTED aa:42:a1:06:99:54
Sun May 19 16:52:15 2024 daemon.notice hostapd: client1: AP-DISABLED
Sun May 19 16:52:15 2024 daemon.notice hostapd: client1: CTRL-EVENT-TERMINATING
Sun May 19 16:52:15 2024 daemon.notice hostapd: nl80211: deinit ifname=client1 disabled_11b_rates=0
Sun May 19 16:52:15 2024 daemon.notice hostapd: nl80211: Failed to remove interface client1 from bridge br-client: Invalid argument
Sun May 19 16:52:19 2024 kern.warn kernel: [24396.576048] ath10k_pci 0000:01:00.0: pdev param 0 not supported by firmware
Sun May 19 16:52:19 2024 kern.info kernel: [24396.603816] IPv6: ADDRCONF(NETDEV_UP): fallback: link is not ready
Sun May 19 16:52:19 2024 kern.info kernel: [24396.743924] fallback: authenticate with a8:42:a1:36:99:55
Sun May 19 16:52:19 2024 kern.info kernel: [24396.758474] fallback: send auth to a8:42:a1:36:99:55 (try 1/3)
Sun May 19 16:52:19 2024 kern.info kernel: [24396.765737] fallback: authenticated
Sun May 19 16:52:20 2024 kern.info kernel: [24396.776517] fallback: associate with a8:42:a1:36:99:55 (try 1/3)
Sun May 19 16:52:20 2024 kern.info kernel: [24396.784641] fallback: RX AssocResp from a8:42:a1:36:99:55 (capab=0x1901 status=0 aid=1)
Sun May 19 16:52:20 2024 kern.info kernel: [24396.796628] fallback: associated
Sun May 19 16:52:20 2024 kern.info kernel: [24396.800197] IPv6: ADDRCONF(NETDEV_CHANGE): fallback: link becomes ready
Sun May 19 16:52:20 2024 daemon.notice netifd: radio0 (8643): fallback (phy #0): unknown event 46
Sun May 19 16:52:20 2024 daemon.notice netifd: radio0 (8643): cat: can't open '/var/run/wpa_supplicant-fallback.pid': No such file or directory
Sun May 19 16:52:20 2024 daemon.notice netifd: radio0 (8643): WARNING (wireless_add_process): executable path /usr/sbin/wpa_supplicant does not match process  path (/proc/exe)
Sun May 19 16:52:20 2024 kern.debug kernel: [24396.893249] fallback: Limiting TX power to 35 (35 - 0) dBm as advertised by a8:42:a1:36:99:55
Sun May 19 16:52:20 2024 daemon.notice netifd: radio0 (8643): Command failed: Invalid argument
Sun May 19 16:52:20 2024 daemon.notice netifd: Network device 'fallback' link is up
Sun May 19 16:52:20 2024 daemon.notice netifd: Interface 'fallback' is enabled
Sun May 19 16:52:20 2024 daemon.notice netifd: Interface 'fallback' has link connectivity
Sun May 19 16:52:20 2024 daemon.notice netifd: Interface 'fallback' is setting up now
Sun May 19 16:52:20 2024 daemon.notice netifd: fallback (8955): udhcpc: started, v1.30.1
Sun May 19 16:52:20 2024 daemon.notice netifd: fallback (8955): udhcpc: sending discover
Sun May 19 16:52:21 2024 daemon.notice netifd: fallback (8955): udhcpc: sending select for 10.234.194.101
Sun May 19 16:52:21 2024 daemon.notice netifd: fallback (8955): udhcpc: lease of 10.234.194.101 obtained, lease time 300

wusel · 19. Mai 2024 um 16:29

Danke für die Logzeilen; ich fasse die Threads mal zusammen, da vermutlich gleiches Problem …

Thomas · 19. Mai 2024 um 16:39

Autoupdater deaktivieren hilft. Ich habe den cron Job auf alle 24h gesetzt.