Keine IPv4 in Domäne 48 mehr

Wo?

Wann?

  • Wann trat die Störung zuerst auf? gerade eben festgestellt
  • Hält sie weiterhin an? hält an

Was?

  • Wie äußert sich die Netzstörung? s. Titel - keine IPv4
--- c1024.servers.freifunk-muensterland.de ping statistics ---
35 packets transmitted, 29 received, 17% packet loss, time 34066ms
rtt min/avg/max/mdev = 37.833/48.926/84.941/8.354 ms

Das ist zur öffentlichen IP des Hosters (eth0). Ich starte mal das Gateway neu.

1 „Gefällt mir“

…und ich wundere mich schon, warum ich plötzlich aus der ssh session fliege.

1 „Gefällt mir“

Geht anscheinend wieder! Danke!

Jo, dein Knoten hat sich jetzt auch mit einem anderen Gateway verbunden. :wink: Mal schauen, ob das „Problem-Gateway“ auch wieder funktioniert.

1 „Gefällt mir“

@descilla hätte ich mir auch denken können :wink:

1 „Gefällt mir“

Ich wollte es nur für Mitlesende, die ggf. auch Probleme haben/hatten, erwähnen. :wink:

@MPW @descilla
scheint jetzt großflächiger aufzutreten. Habe gerade unter anderem bei folgenden Knoten keine IPv4 bekommen:

https://karte.freifunk-muensterland.de/map48/#!v:m;n:60e32722ccac
https://karte.freifunk-muensterland.de/map48/#!v:m;n:14cc2097f84a
https://karte.freifunk-muensterland.de/map48/#!v:m;n:6872512e99e1
https://karte.freifunk-muensterland.de/map48/#!v:m;n:14cc2097d3a6

Oder soll ich besser ein neues Thema aufmachen?

Kann es sein, dass es Geräte-abhängig ist? Mit meinem Laptop bekomme ich wie gewünscht eine IPv4. WieistmeineIP.de gibt mit außerdem folgende WAN-IP aus: 185.66.193.48

Mein Smartphone (Oneplus One, Cyanogen OS 13.1.2) allerdings ist nur über IPv6 unterwegs. Hatte ich vor kurzem schonmal. Nach einem Neustart ging wieder alles wie gewohnt (auch diesmal der Fall). Das Verhalten habe ich allerdings nur bei Freifunk und nicht bei anderen WLAN-Netzen. Also ein Freifunk-Problem? Oder ein Geräteproblem?

Ich habe nun mal auf allen Gateways das loglevel von kea-dhcp von WARN auf INFO gesetzt. Nun sehe ich, was dort passiert. Bislang ist mir aber nichts aufgefallen. Sehr hilfreich wäre es, wenn du mir mal (mittels einem Kanal deiner Wahl) deine MAC-Adresse zukommen lassen könntest. Und den ungefähren Zeitpunkten der Probleme.

Hinweis: Die erweiterte Logging-Ausgabe ist jedoch erst ab jetzt aktiv. Bei den Problemen von vor 6 Stunden helfen sie mir leider nicht weiter.

PS: Hast du mal versucht, ob das Netz funktioniert, wenn du dir eine manuelle IP zuweist? Das wäre sehr Hilfreich um die Problemquelle eher dem DHCP Server oder doch eher anderen Netzkomponenten zuordnen zu können.


Falls du SSH Zugriff auf einen der problembehafteten Knoten hast, wäre die Ausgabe des Kommandos logread sehr interessant. Auch dieses kannst du mir gerne über einen nichtöffentlichen Kanal zukommen lassen.


Wir haben in etwa zwei Hand voll Knoten, deren L2TP Verbindung immer mal wieder stirbt und neu aufgebaut wird…

@descilla Wahrscheinlich habt ihr auch wichtigeres zu tun, als den Fehler zu suchen, oder? (Dieser könnte ja auch einfach bei meinem Gerät liegen, was da es ansonsten ja keine Beschwerden gibt, gut möglich ist)

Von daher würde ich vorschlagen, dass erstmal nicht weiter zu verfolgen. Ich kenne ja einen Workaround.

Doch eigentlich wollen wir den Fehler schon finden. Wir haben schon den Anspruch an uns selbst, dass das Netz läuft.

Hast du vielleicht die Möglichkeit den Knoten ins Gastnetz der Fritzbox zu stecken und uns mal für eine begrenzte Zeit Zugriff per SSH zu geben?

Grüße
Matthias

1 „Gefällt mir“

Mir wurde von @scroom berichtet, dass der Fehler weiter besteht.

In Domäne 48 gibt es derzeit nur ein Gateway, weil C1024 noch offline ist. Aber Nightbounce funktioniert.

Ich kann den Fehler nicht reproduzieren. Es muss ein Problem im Setup vor Ort geben. Es wäre cool, wenn jemand aus dem Adminteam Zugriff auf einen Knoten und einen daran hängenden Pi kriegen könnte. Dann kann man das diagnostizieren.

Grüße
Matthias

@MPW Habe leider keinen Pi hier rumliegen. Wenn mir jemand einen leihen würde, könnte ich euch SSH-Zugriff auf meinen Knoten geben.

Alternativ könntest du mir auch mal die Mac eines der Geräte geben, die keine IP bekommen. Dann guck ich mal, ob der korrekt anfragt.