[Berlin-wireless] am-dach-rt1 endless Story
Rainer
rainer.strassburger at r-str.org
Mi Mär 28 00:43:06 CEST 2018
am-dach-rt1 endless Story
hatte wirklich kein gutes Betreff gewaehlt
Mir war allerdings auch noch nicht klar dass hinter dem Problem
eindeutig der Rechner am-dach-rt1 steckt.
Mit dickem Hals argumentiert es sich halt wirklich schlecht.
Versuche mich zu bessern
Hatte bbb-vpn als Problem ausgemacht.
bbb-vpn ist wohl nicht die Ursache des Problemes sondern der Rechner
am-dach-rt1 auf dem bbb-vpn laeuft
Warum:
Bis gestern / vorgestern
bbb-vpn geht / geht nicht
OLSR-floating.
Quelle jeweils ueber bbb-vpn von am-dach-rt1
Neue Erkenntnisse von am-dach-rt1
anscheinend werden die Monitordaten von chris-core nicht weitergeleitet
Das war nicht der Fall solange chris-core ein anderes Smartgateway als
77.97.46.50 , also "am-dach-rt1" zugeordnet bekam-
probleme an mid1.am-dach-rt1.olsr (10.31.48.6)
traceroute to 77.87.48.12 (77.87.48.12), 30 hops max, 38 byte packets
1 10.31.48.6 3.016 ms
2 *
uber anderen Weg, z.Bsp: von bbb-vpn router "primavera"
$ traceroute 77.87.48.12
traceroute to 77.87.48.12 (77.87.48.12), 30 hops max, 60 byte packets
1 frei.funk (10.36.177.1) 10.357 ms 10.321 ms 10.305 ms
2 192.168.205.1 (192.168.205.1) 10.288 ms 10.274 ms 10.259 ms
3 192.168.204.1 (192.168.204.1) 10.186 ms 10.172 ms 10.785 ms
4 192.168.1.1 (192.168.1.1) 11.539 ms 12.254 ms 14.012 ms
5 183.red-80-58-67.staticip.rima-tde.net (80.58.67.183) 24.828 ms
24.829 ms 24.818 ms
6 * * *
7 117.red-80-58-96.staticip.rima-tde.net (80.58.96.117) 40.901 ms
42.846 ms 40.879 ms
8 ae0-400-grtmadno2.net.telefonicaglobalsolutions.com (213.140.51.56)
44.120 ms 44.049 ms 44.036 ms
9 5.53.7.225 (5.53.7.225) 53.441 ms 41.556 ms 45.527 ms
10 5.53.7.204 (5.53.7.204) 43.462 ms 213.140.33.253 (213.140.33.253)
107.366 ms 213.140.36.146 (213.140.36.146) 45.393 ms
11 84.16.14.8 (84.16.14.8) 45.377 ms 94.142.97.138 (94.142.97.138)
45.342 ms 41.182 ms
12 80.157.129.105 (80.157.129.105) 45.555 ms 45.495 ms 45.465 ms
13 217.239.60.26 (217.239.60.26) 81.778 ms 80.157.129.105
(80.157.129.105) 45.428 ms 217.239.60.26 (217.239.60.26) 81.755 ms
14 217.239.60.26 (217.239.60.26) 83.611 ms
freifunk-vmhost03.in-berlin.de (217.197.91.144) 85.150 ms *
15 * * *
16 * * *
17 monitor.berlin.freifunk.net (77.87.48.12) 90.437 ms 92.321 ms
92.257 ms
am-dach-rt1
---------------------------------------------------------------
Hier meine Gesamterfahrung die seit zwei Jahren leider immer wieder
auftauchen - und derweil eindeutig auf am-dach-rt1 hindeuten.
Habe leider als Neuling seit 2016 sehr sehr lange gebraucht das
Problemkind zu identifizieren.
Vorwort:
meine im Entwicklungsdienst in Nicaragua erworbene umfangreiche
Frustrationstoleranz ist eindeutig ueberschritten
Daher bitte ich um aktive Mithilfe
Rainer
Einleitung:
Qualitaetsmanagment FF Berlin
Habe den Eindruck dass bei ff berlin vor lauter ehrenwerten Ideen wie
-OLSR Experimentalnetz-, -freien Zugang zu Internet fuer alle- das
Qualitaetsmanagment vernachlaessigt ist.
Oder ist es schlicht nicht vorhanden?
Was nutzt der Betrieb eines Experimentalnetzes ohne die Basis
sicherzustellen?
meine persoenliche Behauptungen:
- Dann sind alle Ergebnisse der Experimente und erst recht die
Schlussfolgerungen daraus absolut wertlos.
Modewort: obsolet
Was macht der Normalnutzer nachdem er 5 bis 10 mal nen Zugang angetestet
hat wenn es 8 von 10 mal nicht funktioniert mit dem Internetzugang?
- Er wendet sich von ff ab.
Gerne moechte ich mit eurer Hilfe dazu beitragen dass dies sich
langfristig aendert.
Ich selber bin kein Qualitätsmanager, nur Praktiker mit ein wenig Erfahrung.
Anlass fuer diese ausfuehrliche Einleitung:
Immer wenn es um olsr / smartgateway / bbbvpn geht konnte ich bisher in
Gespraechen und Mails keinen wirklichen Plan erkennen.
Versuch einen Zusammenhang auf Erfahrungswerten aufzustellen
Fragen:
1: ist es richtig erkannt dass folgender Smartgateway sich physikalisch
im gleichen "Blech" befinden?
am-dach-rt1.olsr (77.87.48.50)
2: Ist es richtig erkannt dass alle bbbvpn Routings ueber "das Blech"
10.230.18.1 geroutet werden, sich also die entsprechende Routingtabelle
im Ram des "Blech" dort befinden?
Wenn das der Fall ist gibt es im "Blech" dort anscheinend ein Probleme.
Zu 1:
war ausgefallen am 20.04.2018
konnte durch Neustart auf chris-core durch am-dach-ns5-sw.olsr
(10.31.48.5) ersetzt werden
mela-empore-swo2 war von Thorsten auch neu gestartet worden.
Vermutung meinerseits:
smartgateway neu zugeordnet.
Bitte Smartgateways auch in Mela beobachten.
Ursache fuer das "mela-gezappel" ????
Zu 2:
kann leider zur Zeit chris-core nicht ueber bbb-vpn erreichen.
bbb-vpn ist leider seit Beginn der Nutzung von mir seit 2016 kein
zuverlaessiger Zugangsweg zu Backbonestandort Siemensstadt
Kirchengemeinde christopherus
Habe die Vermutung dass das "Blech" die Problemstelle seit Jahren ist.
chris-core sendet brav daten hopglass.berlin.freifunk.net.
Ist also lebendig.
Tests weiter unten, bitte von Euch aus nachvollziehen
Vorgeschichte:
Anfang des Jahres hatte ich auf Grund bitterer Erfahrung darauf
hingewiesen dass ich defektes RAM als Ursache des Ausfalls im "Blech"
vermute.
Leider wurde das RAM bis heute nicht getestet oder ausgetauscht.
Jedenfalls habe ich keine entsprechende Rueckmeldung bekommen.
Ausser dass der Verein über neue Hardware nachdenkt.
Denke es ist an der Zeit "das Blech" entweder in Ordnung zu bringen.
Dafür braucht Daniel jede Unterstuetzung die er bekommen kann.
Auch wird mit Ausfallzeiten von mehereren Tagen zu rechnen sein.
Oder:
zu mindest dem bbb-vpn und dem olsr-Routing eine neu Heimat zu schaffaen.
-Fuer die anderen Funktionen dort fehlt mir wirklich der Ueberblick.
Meine letzten tests von der Insel, bitte von anderen bbb-vpn Standorten
verifizieren:
Ne Rueckmeldung waere hilfreich:
traceroute to chris-core.olsr (10.230.18.185), 30 hops max, 38 byte packets
1 10.230.22.1 87.859 ms
2 *
3 *
4 *
5 *
6 *
7 *
traceroute to beuth0.olsr (10.230.23.143), 30 hops max, 38 byte packets
1 10.230.22.1 166.777 ms
2 *
3 *
4 *
traceroute to tub-core.olsr (10.31.31.73), 30 hops max, 38 byte packets
1 10.230.22.1 81.756 ms
2 *
3 *
4 *
5 *
traceroute to 10.230.22.1 (10.230.22.1), 30 hops max, 38 byte packets
1 10.230.22.1 83.890 ms
traceroute to am-dach-ns5-sw.olsr (10.31.48.5), 30 hops max, 38 byte packets
1 10.230.22.1 166.992 ms
2 10.31.48.5 83.466 ms
traceroute to torte-mela.olsr (10.31.27.245), 30 hops max, 38 byte packets
1 10.230.22.1 84.685 ms
2 10.31.27.245 155.850 ms
traceroute to zwingli-core.olsr (10.31.10.1), 30 hops max, 38 byte packets
1 10.230.22.1 84.312 ms
2 10.230.22.62 160.711 ms
3 10.31.10.1 145.892 ms
traceroute to segen-core.olsr (10.31.6.5), 30 hops max, 38 byte packets
1 10.230.22.1 84.042 ms
2 10.230.22.62 164.237 ms
3 10.31.10.29 142.191 ms
4 10.31.2.37 135.683 ms
5 10.31.6.5 160.024 ms
Nachsatz:
Zuerst dachte ich natuerlich nen problem auf meiner Seite.
Dann:
bbb-vpn- Standort zu bbb-vpn-Standort ok.
Nur bbb-vpn zu echten Backbone Standorten gestoert.
Ist aber nicht der Fall.
Daher der Rueckschluss auf ne defekte Routingtabelle im "Blech"-01
Lasst uns das Problem gemeinsam einkreisen und dann auch endgueltig loesen.
Damit es wieder Spass macht.
Rainer
----
Mehr Informationen über die Mailingliste Berlin