bezogen auf die Mail "EOL Netmon"

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


Aaahhh Techniktreff in Erlangen / Nbg.
Alles klar.

Am 07.03.2017 20:49 schrieb "Mister Crumble" <MisterCrumble at web.de>:

> Hallo, ich glaube das wird gerade diskutiert. Wenn Router aus dem
> Netmon gelöscht werden, dann landen sie in der default hood
>
> mfg mistercrumble
>
> Am 7. März 2017 um 20:45 schrieb Alex Gutfried <alexgutfried at gmail.com>:
> > 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/ade61d1c/attachment.html>


Mehr Informationen über die Mailingliste franken-dev