[Berlin-wireless] Berlin Nachrichtensammlung, Band 3207, Eintrag 4
Perry
isprotejesvalkata at gmail.com
Mo Mär 26 12:00:47 CEST 2018
Hey Rainer,
Ich verstehe ganz nicht warum die routen immer wieder wegfallen. Wir
(Holger, Sven2.0, ich) überlegen wie wir eine lösung finden können.
vielleicht bauen wir eine neue bbb-vpn server auf.
Und ich hab selber nicht mit das Blech zu tun. Ich habe halt nur ein
konto so das ich zum bedarf der bbb-vpn neustarten kann.
Gruß,
Perry
On 26.03.2018 00:20, rainer at strassburger.name wrote:
> Und wieder Frusterlebniss mit bbb-vpn-Zugang:
> ca 8:00
> mitten waehrend der Arbeit an chris:
> Verbindung verloren.
> Keine Route mehr zu chris.
> keine Route mehr zu Zwingli
>
> Stelle hiermit den offiziellen Antrag zur endgütigen Verschrottung vom
> Blech am Dach.
>
> Anscheinend fuehlt sich niemand verantwortlich sich um das "Blech" zu
> kuemmern oder Ersatz zu schaffen.
>
> Finde ich sehr enttaeuschend.
>
> Rainer
>
>
>
>
> Am 25.03.2018 um 15:56 schrieb Rainer:
>> Neu Erkenntnisse:
>> In den fruehen Morgenstunden vom 25.03.2018 hat sich das Problem
>> erledigt.
>>
>> Ursache noch nicht wirklich bekannt.
>> Alle Zeitangaben in UTC:
>>
>> Scan mit nmap:
>> Vor 2:04 abgeschlossen
>>
>> Nmap scan report for 10.230.17.28
>> Host is up (0.33s latency).
>> Nmap scan report for 10.230.19.97
>> Host is up (0.13s latency).
>>
>> Also 10.230.18.1 chis-core.olsr nicht erreichbar
>>
>> Ueber Nacht haben wohl Heinzelmaennchen zugeschlagen:
>>
>> Am 25.03.2018 ca 9:00
>> kann chris-core wieder erreichen, sogar direkt ueber den PC
>>
>> $ traceroute chris-core.olsr
>> traceroute to chris-core.olsr (10.230.18.185), 30 hops max, 60 byte
>> packets
>> 1 frei.funk (10.36.177.1) 9.643 ms 9.617 ms 9.542 ms
>> 2 10.230.22.1 (10.230.22.1) 100.114 ms 105.881 ms 106.477 ms
>> 3 mid1.Mod77uplink.olsr (10.230.22.62) 116.858 ms 118.836 ms
>> 118.840 ms
>> 4 mid3.Zwingli-Core.olsr (10.31.10.29) 143.672 ms 143.671 ms
>> 147.985 ms
>> 5 mid6.f2a-core-rt.olsr (10.31.2.37) 147.990 ms 148.821 ms
>> 166.499 ms
>> 6 mid5.segen-core.olsr (10.31.6.37) 168.298 ms 157.529 ms
>> 157.509 ms
>> 7 beuth0.olsr (10.230.23.143) 157.446 ms mid5.scherer8.olsr
>> (10.230.226.202) 147.238 ms 136.045 ms
>> 8 mid6.tub-core.olsr (10.31.31.77) 139.989 ms 139.676 ms 153.554 ms
>> 9 chris-core.olsr (10.230.18.185) 907.531 ms 907.506 ms *
>>
>>
>>
>>
>> auf chris-core festgestellt dass sich der bevorzugte smartgateway
>> geaendert hatte:
>> >> chris-core hat jetzt nen anderen smartgateway gewaehlt:
>> >> 10.31.11.1 emma-core.
>> >>
>> wenn ich mich richtig entsinne.
>> >> Bei 10.230.228.5 -letzter genutzer smartgateway- ist jetzt der
>> uplink-wert von 10000 auf 1000 gesetzt.
>>
>> Schlussfolgerung:
>> 10.230.18.1, also bbb-vpn.berlin.freifunk.net leitet weiter an
>> mid1.Mod77uplink.olsr also Zwingli ????
>>
>> von dort brav weiter ueber segen + beuth zu chris.
>>
>> Frage:
>> Ist es richtig:
>> Das bbb-vpn-Routing auf "dem Blech" scheint zu funktionieren.
>> Das olsr-Routing dort macht das Problem. Die entsprechende
>> Routingtabelle ist halt auch dort im RAM.
>>
>> Waere ueber "Aufklaerung" dankbar.
>>
>> Hierzu fehlt mir die Erfahrung:
>> Auszug aus system-Log von chris-core:
>> Der letzte von mehr als 1000 entsprechenden Eintragen bei
>> Suche nach "Cannot create tunnel tnl"
>>
>> Sun Mar 25 04:00:25 2018 daemon.err olsrd[11234]: Cannot create tunnel
>> tnl_0a1f3005nach scheint wohl der neue Smartgateway vergeben worden zu
>> sein.
>>
>> Danach schien es zu funktionieren
>>
>> Auch hierzu waere ich fuer jeden kompetenten Komenetar sehr dankbar.
>>
>>
>> Rainer
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Message: 4
>>> Date: Sat, 24 Mar 2018 14:44:46 +0000
>>> From: rainer at strassburger.name
>>> To: wirelesslan in Berlin <berlin at berlin.freifunk.net>, Rainer
>>> <rainer at strassburger.name>
>>> Subject: [Berlin-wireless] Fwd: [ff-spandau] Bitte um Gegencheck:
>>> Qualitaetsmanagment-01 FF Berlin
>>> Message-ID: <de799ba1-51f2-22b0-f656-98967d40b42c at r-str.org>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> 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