[Berlin-wireless] Fwd: [ff-spandau] Bitte um Gegencheck: Qualitaetsmanagment-01 FF Berlin

Sa Mär 24 15:44:46 CET 2018

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

_______________________________________________
ff-spandau mailing list
ff-spandau at lists.geroedel.de
http://www.geroedel.de/mailman/listinfo/ff-spandau