Störung IPv4 02-09.12.2014

Ich habe im Moment keine oder gestörte Konnektivität via IPv4, IPv6 macht was es soll.

tracepath www.rwth-aachen.de
1?: [LOCALHOST] pmtu 1280
1: 10.40.228.1 36.158ms
1: 10.40.228.1 33.648ms
2: 100.64.0.16 50.972ms
3: irb-1050.bb-a.fra3.fra.de.oneandone.net 41.665ms asymm 4
4: no reply
5: no reply

Letzten Mittwoch gab es ein ähnliches, da waren definitv auch einige v4 Ziele erreichbar, die RWTH aber nicht. Manchmal hilf ein Router Neustart, vielleicht einer der VPN Server?

Wir haben vorhin auf den Routern die verbesserten Hash-Algorithmen für fastd (Tunnel-Dienst) konfiguriert. Dabei ging vermutlich die Assoziation Deines Nodes mit dem Batman-Gateway verloren, der sich selbst Deinen Clients als Default Router genannt hat.

Wir sind soweit fertig und es sollte daher erst einmal nicht mehr wackeln.

Wann behebt sich denn dieser Fehlerzustand, wenn er denn auftritt?
Nach Zeit?
Bei Reboot sofort?
Kann man auf der Kommandozeile des Routers mit irgendeinem batctl-Kommando nachhelfen in so einem Fall?

Das Problem besteht weiterhin.

Der Betroffene Router (ffac-halifax-beta-mobil-0) ist verbunden zu:

rheinufer0.freifunk-rheinland.net
rheinufer2.freifunk-rheinland.net

Ich kann z.B. keine Software aus dem google play store herunter laden. Das Problem gab es beim Freifunktreffen gestern Abend auch (ffac-pizzaplane & ffac-pizza-point-kuehlwetter14)

dmesg gibt bei meinem Router folgendes in Massen aus:

hat das ggfs. mit solchen Problemen zu tun?

ffac-halifax-beta-mobil-0
http://[2a02:f98:0:28:218:e7ff:fede:aa2f]/cgi-bin/status
Ist aber zumindest aus dem Internet anpingbar. Also kein IP6-Problem.

Idee:
eine zweite Status-Seite „check-ipv4“ gibt das Testergebnis bzgl. der IPv4-Connectivity aus.
Diese Seite kann man mit Uptimerobot abfragen.

Baue doch mal was zusammen.

ich würde z.B. schauen

batctl o|grep -c [.*]

batctl gwl
batctl p sowohl auf br-wan wie auch auf mesh-vpn (wenn vorhanden)
nslookup freifunk.net (plus returncode echo $?)

(weitere Vorschläge willkommen)

Das deutet auf einen abgeschmierten WLAN Treiber hin. Wir booten Geräte mit diesen Meldungen automatisiert neu.

Das Kernel log (dmesg) ist bei mir sauber.

Ich bekomme derzeit noch nicht mal zuverlässig eine IPv4 IP.

Ich fange mal damit an alle router bis auf einen abzuschalten um zu debuggen.

1 Like

hmm!?
ich habe grad meine Router gebootet, weil ich definitiv nicht damit ins Internet kam.
Direkt nach dem Booten mit 2 Clients verbunden, sehe ich mit dmesg erneut diese Meldung.
Ein automatisches Booten würde dann ja zu einer Endlosschleife führen!?

Nicht zwingen, wir hatten hier des öfteren Geräte die mal direkt zweimal hintereinander neu gestartet haben, mehr kam aber an sich nicht vor.

Ich spreche hier aber von einer ziemlich homogenen Umgebung mit ausschließlich D-Link DIR 825 rev. B1 und TP-Link TL-WDR4900 v1. Davon aber recht viele.

Für andere Umgebungen und Geräte muss man erst eine Weile das Logfile beobachten.

Apropos: Gibt’s da ein Gluon für? wenn ja welches? Denn das ist so für mich der andere Kandidat neben 1043v2, wenn es um fastd-Leistung geht.

Aber es bahnt sich gerade der nächste Kandidat an, dem ich hoffentlich gleich mal auf den Zahn fühlen kann. Ein Router, der nur aus Teilen des Netztes erreichbar (pingbar) ist…

Das Problem ist wieder vorhanden, mir sind noch weitere IPs die nicht erreichbar sind aufgefallen. Beispielsweise Sipgate:

tracepath sipgate.de
1?: [LOCALHOST] pmtu 1280
1: 10.40.228.1 59.114ms
1: 10.40.228.1 56.734ms
2: 100.64.0.16 240.355ms
3: irb-1050.bb-a.fra3.fra.de.oneandone.net 144.436ms asymm 4
4: c13-1.netzquadrat.net 67.762ms asymm 5
5: no reply

Erneut die RWTH
tracepath www.rwth-aachen.de
1?: [LOCALHOST] pmtu 1280
1: 10.40.228.1 38.898ms
1: 10.40.228.1 40.491ms
2: 100.64.0.16 48.948ms
3: irb-1050.bb-a.fra3.fra.de.oneandone.net 48.202ms asymm 4
4: no reply

tracepath a23-65-181-73.deploy.static.akamaitechnologies.com 1?: [LOCALHOST] pmtu 1280
1: 10.40.228.1 39.109ms
1: 10.40.228.1 38.769ms
2: 100.64.0.16 48.476ms
3: irb-1050.bb-a.fra3.fra.de.oneandone.net 47.817ms asymm 4
4: te-2-1.bb-d.ba.slo.gb.oneandone.net 63.216ms asymm 5
5: 212.119.29.77 63.337ms asymm 6
6: ae-6.r02.amstnl02.nl.bb.gin.ntt.net 73.815ms asymm 9
7: ae-5.r03.amstnl02.nl.bb.gin.ntt.net 71.901ms asymm 8
8: no reply

Ich wollte sowohl am Donnerstag, als auch am Sonntag neue iOS-Geräte installieren. Über Freifunk ist das nicht gelungen. Die Geräte behaupteten, sie hätten keinen Zugang zum Internet (natürlich wurde nur irgendein Apple-Server nicht erreicht).
Dann habe ich mein privates WLAN ausgewählt, mich mit dem langen WLAN-Key abgequält, aber dann klappte die Installation.

Am Wochenende wollten meine Kids die Maus-App (‎DieMaus on the App Store) benutzen, die aber nicht lud, weil sie scheinbar irgendeinen WDR-Server nicht erreichte.

Das sind alles Phänomene, die wiederholt auftreten, aber schwer zu debuggen sind, wenn man den angefragten Server nicht kennt.
Insgesamt ist es derzeit sehr unbefriedigend.

1 Like

Mich verwirrt an dem Problem vor allem, dass bei meinen drei Beispielen die Probleme jeweils an unterschiedlichen Punkten zu liegen scheinen.

Ich habe den Verdacht, dass sich unsere Routing Tabellen nicht schnell genug an neue Informationen anpassen.

Verbindungsprobleme kann ich hier recht zuverlässig reproduzieren :smile: .
So ist z.B http://www.dropbox.com aus dem lokalen Freifunk-Netzwerk heraus nicht erreichbar.

Ein ähnliches Problem hatten wir vor einiger Zeit schon einmal:

Google (geht):

traceroute to www.google.de (64.233.167.94), 64 hops max, 52 byte packets
 1  10.40.228.1  19.705 ms  221.032 ms  319.546 ms
 2  100.64.0.16  178.717 ms  48.331 ms  31.645 ms
 3  195.20.242.193  28.540 ms  28.994 ms  30.095 ms
 4  * * *
 5  209.85.248.12  45.585 ms  35.086 ms  38.557 ms
 6  209.85.251.178  31.400 ms
    209.85.251.248  59.206 ms
    72.14.234.231  40.343 ms
 7  209.85.240.142  43.125 ms  93.494 ms
    209.85.241.226  45.210 ms
 8  209.85.244.102  43.207 ms
    209.85.244.100  83.046 ms
    209.85.240.221  67.504 ms
 9  209.85.242.165  90.202 ms
    209.85.242.15  49.565 ms  45.844 ms
10  * * *
11  64.233.167.94  58.102 ms  45.068 ms  52.422 ms

Dropbox (geht nicht):

traceroute to www.v.dropbox.com (108.160.166.142), 64 hops max, 52 byte packets
 1  10.40.228.1  20.875 ms  28.334 ms  17.746 ms
 2  100.64.0.16  37.603 ms  146.542 ms  96.597 ms
 3  195.20.242.193  115.540 ms  74.240 ms  118.951 ms
 4  213.200.65.201  86.578 ms  253.292 ms  348.374 ms
 5  141.136.106.58  47.561 ms
    141.136.106.194  44.205 ms
    141.136.106.58  147.506 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
...

Wenn ich von diesen plötzlich nicht erreichbaren Hosts höre muss ich zwangsläufig an Juli 2014 denken.
Zur Erinnerung: Wir waren damals noch kein RIPE Mitglied und auf niederländische Provider angewiesen, die wiederum aufgrund von einigen Abusemails Probleme machten. Um zumindest eine Grundfunktionalität herzustellen, haben Menschen aus dem Adminteam ein paar IP-Ranges gesperrt um unseren damaligen Provider zu beruhigen. In der Zwischenzeit liefen die Arbeiten am „Projekt Provider werden“ und der Aufbau eigener Infrastruktur.

Siehe:
https://mailman.freifunk-rheinland.net/pipermail/ffrl/2014-July/003355.html
https://mailman.freifunk-rheinland.net/pipermail/ffrl/2014-July/003356.html
https://mailman.freifunk-rheinland.net/pipermail/ffrl/2014-July/003360.html

Unter den versehentlich gesperrten IPs warenn auch Apple und Akamai Ranges, die hier scheinbar auch betroffen sind. Daher einfach mal meine Frage ins Blaue hinein: da hat sich nicht zufällig irgendwie eine alte Filterregel eingeschlichen?

Kann denn @nomaster @CyrusFox oder sonst jemand mit zugriff auf die backbone Infrastruktur etwas dazu sagen?

Ich finde die Situation abstrus, dass es möglich ist von der rwth aus einen knoten anzuschließen der sich per mesh vpn mit den ffrl Backbone verbindet, eine Verbund zurück, die ja über die gleichen routen gehen könnte, gelingt nicht.

Ich dachte, @nomaster und @thomasDOTwtf haben Zugriff auf den Backbone!?

Wo ist eigentlich die Übersicht, wer hier was macht?

1 Like

Ist ja letztendlich egal wer was macht :wink: Probleme sollten immer generell gemeldet werden und nicht mittels kurzem Dienstweg, das belastet einzelne zu sehr und es ist nicht transparent wer was geändert hat.

Momentan gibt es im Mesh sehr viel Packetloss was wohl auch zu dem Problem beiträgt, ich denke das sich dies erst verbessern wird wenn wir die Supernodes auf neue VMs umgezogen haben.