Mehrminütiger Ausfall im 60 Minuten-Takt im Bereich Rietberg

[Wurstkanone (Marcel)]

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

Ausfall jede Stunde um XX:40

Guten Abend, im Bereich Rietberg scheint es einen Ausfall jede Stunde um XX:40 Uhr zu geben. Zu mindestens konnte ich ein Verlust der Verbindung zu Gateway des Knoten 33397-Buergerhaus-Druffel um 19:40 und 20:40 am 15.4 und 16.4 beobachten. Es dauert dann ca. 3-4 Minuten bis der Datenverkehr wieder läuft. Von zwei anderen Knoten habe ich das von Nutzern auch schon gehört. Konnte aber bisher es selber nie beobachten. Ich werde es bei anderen Knoten auch schon einmal versuchen zu erkennen. (In …

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 (Marcel)]

Bild-Freifunk-Grafana

[Wurstkanone (Marcel)]

Bild-Firewall

[Wurstkanone (Marcel)]

Bild-Messgerät

[wusel (Kai 'wusel' Siering)]

@Wurstkanone

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.

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 …

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.

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 (Kai 'wusel' Siering)]

@wusel

Bitte ab 17 Uhr mal gucken, ob das Phänomen noch auftritt …

@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 (Kai 'wusel' Siering)]

@wusel

@Wurstkanone und @Thomas, hat der GW-Wechsel was geändert?

Ping, @Wurstkanone, @Thomas?

[Wurstkanone (Marcel)]

@wusel

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.

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 (Marcel)]

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 (Marcel)]

@wusel

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?

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 (Kai 'wusel' Siering)]

@Wurstkanone

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.

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

@Wurstkanone

Vorher was das Gateway für die Endgeräte 10.234.160.4
Nun ist es 10.234.160.81

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.

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

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

@Wurstkanone

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.

That’s … odd.

[wusel (Kai 'wusel' Siering)]

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

[wusel (Kai 'wusel' Siering)]

@wusel

AFAICS ist das Problem in Mesh 02 nicht mehr existent

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

Edit: syslog des Knotens wird nun extern gesammelt …

[Wurstkanone (Marcel)]

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 (Thomas Hollenbeck)]

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 (Thomas Hollenbeck)]

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 (Marcel)]

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.