[Berlin-wireless] OLSR/BBB/SmartGateway Probleme (war: Berlin Nachrichtensammlung, Band 3207, Eintrag 4)

[Thorsten Maerz]

Hi Rainer,

es wäre wirklich hilfreich, wenn Du die Betreffzeile passend zum Problem
anpasst, irgendwas mit "Nachrichtensammlung" interessiert hier die
Wenigsten, und Du willst doch, das man das/Dich liest?

On Thu, 5 Apr 2018 15:42:46 +0100
rainer at strassburger.name wrote:

> Am 26. März 2018 um 12:00 schrieb Perry <isprotejesvalkata at gmail.com>:
>  > 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.
> 
> Hallo Perry, hallo Holger, hallo Sven2.0, Harald
> Versuche weiterhin die ganze Problematik / das Routing-System von FF 
> Berlin zu verstehen.
> [...]
> Ist wohl eher ein OLSR-Problem, auf dem ja die bbb-vpn Verbindung aufbaut:

Ja. Wir sitzen z.Zt. noch auf OLSR-0.9.0.3 fest. Wenn man sich mit
dessen Problemen an die OLSR Entwickler wendet, rollen die bei dieser
Uraltversion nur mit den Augen und sagen "nehmt was Neueres".
Verständlich.

Hinter den Kulissen wird ja gerade geplant, worauf und ggf. wie man auf
andere Versionen oder ganz andere Software (bmx, babel, ...) umsteigen
kann, ohne sich wieder einen ganzen Sack neuer oder alter Probleme
einzufangen.

Und es braucht auch einen Plan für den Übergang, man will ja z.B. auch
noch an die Nodes, die noch nicht aktualisiert sind, rankommen. Aber
das darf sich auch nicht mit den neuen Verfahren beissen (OLSR 0.9.0
und 0.9.6 zu mischen führt m.W. zu Ärger). Ein Weg könnte z.B. sein,
das Neue nur für IPv6 und das Alte nur für IPv4 laufen zu lassen.

Ist halt alles nicht mal schnell aus dem Hut gezaubert, aber es wird
dran gearbeitet.

> Wenn anderes Smartgateway gewahlt wird wie jetzt emma-core ist die 
> Funktion von bbb-vpn gegeben.

Kommt halt drauf an, wie und wo OLSR grad den Geist aufgibt.

> Hier der Auszug aus Smartgateway von chris-core:
> Gateway 	Status 	ETX 	Hops 	Uplink 	Downlink 	IPv4 	IPv6 	Prefix
> 10.31.14.12	u	-0.001	0	1000	5000	yes	no	0.0.0.0/0.0.0.0
> 10.31.11.1	s	5.349	3	250000	250000	yes	no	0.0.0.0/0.0.0.0
> 10.31.33.5	u	5.402	3	10000	80000	yes	no	0.0.0.0/0.0.0.0
> 10.230.228.5	u	7.442	5	1000	10000	yes	no	0.0.0.0/0.0.0.0
> 10.230.240.82	u	8.437	5	10000	50000	yes	no	0.0.0.0/0.0.0.0
> 10.31.36.60	u	24.867	8	8000	200000	yes	no	0.0.0.0/0.0.0.0
> 
> ich verstehe das so:
>   aktiver Smartgateway ist zur Zeit:
> 10.31.11.1 emma-core
> 
> Also erkennt olsr  nicht sauber funktionierendes Smartgateway nicht, 
> oder zumindest nicht zuverlaessig.

Genau. SmartGW kümmert sich (vereinfacht) nur um die behauptete
Uplink/Downlink Geschwindigkeit und sucht sich daher emma-core aus.
Eine Untersuchung, ob der Link das wirklich bringt, findet nicht statt.
Wie auch? Wenn die Nodes alle testen, ob über die verschiedenen Links
wirklich so viel läuft, dann ist das Netz allein durch die ganzen
Messvorgänge platt. Und eine "zentrale Messstation" ist auch doof, weil
wir einen dezentralen Aufbau wollen, wo es nicht stört, wenn
irgendwelche Knoten ausfallen - BBB-VPN, Monitor und die Tunnelserver
sind schon genug "zentralistischer Kackscheiß", da wollen wir nicht
noch mehr von haben.

Speziell für das Problem Richtung emma-core könnte es evtl. helfen, mit
dem OLSR LQ-Multiplikator rumzuspielen, damit sollte man einzelne
Verbindungen "besser" oder "schlechter" aussehen lassen können, wenn
ich das richtig aufgeschnappt habe. Würde mir sowas wie "10.31.11.1
0.01" vorstellen, weiss aber nicht, ob wir uns damit evtl. aussperren.
Dürfen sich die Kenner zu äussern, oder wir probieren das, wenn wir
dank Wetter, Schlüssel, etc. mal wieder Chris auf's Dach steigen können.

-- 
LG Thorsten