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?
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)
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.
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…
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.
Verbindungsprobleme kann ich hier recht zuverlässig reproduzieren .
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.
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.
Ist ja letztendlich egal wer was macht 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.
.
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.