bezogen auf die Mail "EOL Netmon"

Alex Gutfried alexgutfried at gmail.com
Di Mär 7 20:45:14 CET 2017


Gabs da jetzt eigentlich noch was oder schauen wir jetzt einfach was da
kommen möge und reagieren dann drauf?

Am 15.02.2017 18:33 schrieb "Christian Dresel" <fff at chrisi01.de>:

hi

On 15.02.2017 14:33, Mister Crumble wrote:
> Hallo
>
> bitte korrigiert mich wenn ich falsch liege.
>
> Die Router haben ja noch weiterhin einen Standort im Key-Exchange,
> wenn wir alle Router die noch im Netmon sind (ca. 800 Stück) in
> default werfen würde dann sicher einiges meshen.
>
> Daher mein Vorschlag.
>
> - Die Router die <= 0.5.2 sind im Key-Exchange auf readonly zu setzen.

und wenn es Meshrouter sind?
Warum eigentlich <=0.5.2 wenn der Netmon noch die Koordinaten an den
Keyxchange liefert und man den Teil noch Online lässt, könnte man 0.5.1
und 0.5.2 übernehmen, da diese ja schon Alfred machen. Nur 0.5.0 und
älter würde es betreffen, das sind 157 Router lt. Monitoring (nur 0.5.0
gezählt).

> - Die Nutzer informieren, das wenn sie den Router neu flashen das uns
> mitzuteilen haben damit das readonly-flag rauskommt.

Das interessiert die nicht, wie oft haben wir probiert die zum Update zu
überreden? Entweder können sie es nicht, wollen es nicht oder haben es
einfach nicht mitbekommen. Aber interesse ist einfach keins da.

> - Router die nur in Default sind auf eine Splash page umzuleiten (
> hatten wir schon mal)

ja hatten wir und ging ziemlich schief, da sich auf einmal Leute
gemeldet haben die auf die Router "angewiesen" waren und wir ihnen
einfach das Internet "geklaut" haben, irgendwie war das so unschön, das
die Sperre schnell wieder weg war.
BIn ich irgendwie dagegen.

> - Router die Meshen umgehend sperren ( Frist 2 Stunden) und dies auch
> klar kommunizieren.

wenn sie Hoods verbinden, machen wir das ja eh schon.

>
> MFG MisterCrumble
>
> Ich werde am Wochenende noch mal die Leute in der würzburger Hood
> anschreiben, damit diese Ihre Router updaten.
>
>
>
> Am 15. Februar 2017 um 13:58 schrieb Alexander Gutzeit <
alexgutfried at gmail.com>:
>> Was tun?
>>
>> -In die Default-Hood fallen lassen, wer mesht wird gesperrt?

Wenn der Netmon dem keyxchange keine Koordinaten mehr liefert und die
Router auch keine haben, könnte man (oder ist es schon so) die Router in
die default fallen lassen, ja. Nur hat man dann in der default ein
ziemliches Chaos. Lieber wäre mir da eine FailHood wo man die 0.5.0 rein
stopft.

>> -Von Hand in die Hoods festlegen. Nur wenn der Router dann doch mal
>> aktualisiert wird kann dieser nicht automatisch die Hood wechseln.

ja ist irgendwie unschön.

>> -In eine weitere "failure" Hood einordnen auf denen die Clients auf eine
>> Fehlerseite umleitet: "Ihr Router ist nicht/falsch konfiguriert oder
>> sollte geupdated werden."
>>
>>
>> Ich bin für die "Fehlerseite".

ne ich eigentlich nicht. Sperren/Fehlerseite hat einfach das Problem:

Fall 1: VPN-Uplink 0.5.0 -> Mesh 20170110
Fall 2: VPN-Uplink 20170110 -> Mesh 0.5.0

Welche sperrst/fehlerseitenumleitest du nun (denk dran, wir können nur
den VPN Uplink sperren, nicht einen Router direkt sperren oder so)? Im
worst case gehören die Router evtl. sogar verschiedenen Personen? Und
dann? Greif ich/wir zentral ein, das wir jemand sperren der einen
anderen Transit gibt? Hm? Es schädigt ja keiner das Netz, es
funktioniert technisch ja alles hm?

Meine Meinung:

0.5.1 und 0.5.2 lassen wir die Koordinaten gespeichert und sie bleiben
somit in ihrer Hood. Sobald sie geupdatet werden, fängt der keyxchange
sie sowieso ein und alles ist wieder gut (falls sie überhaupt VPN
machen). Hier bin ich mir gerade unsicher, wie die Koordinaten vom
Netmon an den keyxchange kommen und wie man das wo behalten sollte.
Evtl. kann man den keyxchange so hinbiegen, das er von diesen Routern
einfach nie mehr versucht neue Koordinaten zu holen und die Hood
"einfach behält die sie aktuell haben" ohne ein readonly flag setzen zu
müssen. Dann kann man für diese einfach alles vom Netmon abdrehen und
sie senden fleißig ihre Alfreddaten weiter. Wie das Monitoring drauf
reagiert da im Alfred kein lat/lon ist...? Puh keine Ahnung gute Frage.

0.5.0 brauchen wir den legacy Provider noch da es hier kein Alfred gibt.
Wir ziehen eine Liste aller 0.5.0 raus, lassen die den Legacy Provider
crawln und schieben diese somit auch ins Monitoring. Auch hier muss man
den keyxchange nicht anfassen und sobald sie geupdatet werden passiert
der Rest automatisch. Mit dem lat/lon aber das gleiche...
Hier muss man vermutlich nur die macs.txt festschreiben und nicht mehr
verändern:
https://github.com/asdil12/fff-monitoring/blob/master/contrib/alfred_legacy_
provider/get_macs.sh
Man kann dann mal ab und zu prüfen welche Router gar nicht mehr
existieren/schon geupdatet wurden und aus der Liste kicken.

Wo man nun was und wie noch aufheben muss (evtl. auch vereinfacht in
einer Liste und keine ganze Datenbank mehr), müsste man erstmal nochmal
prüfen, ich hab das jetzt grad so halbherzig bisschen zusammengesucht
und evtl. hier oder da noch murks erzählt also bitte nicht drauf
verlassen und nochmal gegen checken.

Also es ist zwar ein wenig arbeit aber ich denke man kann die alten
Kisten erstmal gut behalten. Wenn es sich dann noch um 10 0.5.0er dreht
kann man das ganze legacy Zeug auch einfach ganz abschalten und sie als
"Geisterrouter" weiterlaufen lassen... irgendwann wird die Hardware dann
hoffentlich auch mal verrecken ;)

mfg

Christian

>> Was sagen Ihr dazu?
>>
>> LG Alex
>>
>>
>>
>>
>>
>> --
>> franken-dev mailing list
>> franken-dev at freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20170307/7e9eccc0/attachment.html>


Mehr Informationen über die Mailingliste franken-dev