[RFC 4/4] add package fff-tunneldigger-testing

Alex Gutfried alexgutfried at gmail.com
Mi Apr 6 12:31:02 CEST 2016


Alles klar :)
Dann lassd es uns angehen :)
Haßberge ist gerüstet! :-D
Am 06.04.2016 12:10 nachm. schrieb "Christian Dresel" <fff at chrisi01.de>:

> Hi
>
> das ist wohl das klassische "Henne-Ei" Problem. Die Gatewaybetreiber
> stellen
> erst um wenn es nötig ist, die Firmwarebauer erst wenn alle Gateways
> umgestellt
> sind. Irgendwer muss ausbrechen und mit dem Umbau der Firmware ist das
> einfacher
> und in meinen Augen "logischer" ;)
>
> - Es werden eh nicht auf einen schlag alle Router in einer Hood geupdatet,
> das
> kommt erst nach und nach
> - Wenn sich dann ein Gateway irgendwann langweilt weil niemand mehr fastd
> verwendet gibt es 2 Möglichkeiten:
> 1) Der Gatewaybetreiber stellt dann doch irgendwann um
> 2) Der Gatewaybetreiber hat wohl kein Interesse mehr das Gateway zu
> betreiben ;)
>
> Das ganze an die Gatewayselection koppeln gefällt mir nicht wirklich auch
> wenn
> es u.U. denkbar wäre (man kann am Router auslesen welches GW in der
> Selection
> gewählt wurde und prüfen ob das l2tp kann und dann nur verbinden wenn es
> kann...).
>
> Da alle l2tp Gateways auch noch im fastd VPN hängen, sollte auch nicht die
> Situation entstehen das ein Router l2tp macht aber in der Gatewayselection
> ein
> unereichbares Gateway hat, der Weg sollte in diesem Fall sein:
>
> GW1: nur fastd
> GW2: fastd und l2tp
>
> Router hat nur eine l2tp zu GW2 aber in der Gatewayselection GW1 stehen, er
> erreicht dieses GW zwar nicht direkt aber über l2tp das GW2 und dort durch
> den
> fastd VPN müsste er dann GW1 erreichen, gut man hat doppelten Traffic und
> einen
> Hop mehr, die Situation sollte man schon vermeiden da gilt dann aber
> wieder:
>
> Die Gatewaybetreiber einer Hood sollten sich absprechen (sollten sie eh
> immer,
> nicht nur in diesem Fall), wenn sie das nicht machen entsteht halt so was
> unschönes, ich sehe das aber nicht als unser ("Firmwareentwickler")
> Problem an.
>
> mfg
>
> Christian
>
> > Alex Gutfried <alexgutfried at gmail.com> hat am 6. April 2016 um 11:31
> > geschrieben:
> >
> > Oder aber es wird zuerst die gw selection angeschaut und dann für den
> > ausgewählten server individuell entschieden ob l2tp oder fastd.
> >  Ist das möglich?
> > Am 06.04.2016 11:27 vorm. schrieb "Alex Gutfried" <
> alexgutfried at gmail.com>:
> > > Bevor wir diese Firmware veröffentlichen muss aber sicher gestellt
> werden
> > > das annähernd alle GWs den l2tp broker eingerichtet haben.
> > >  Okay wenn keiner da ist, nutzen alle fastd doch wenn ein Gateway den
> Broker
> > > hat verbinden sich alle Router (mit aktueller Firmware) mit diesen
> einen
> > > Server. Hm da macht sie gw selection auch nicht mehr viel. ;)
> > >
> > > Am 06.04.2016 11:12 vorm. schrieb "Christian Dresel" <fff at chrisi01.de
> >:
> > > > Hi
> > > >
> > > > dann seh ich das richtig das wir praktisch alle 3 der gleichen
> Meinung
> > > > sind:
> > > >
> > > > "Der Router soll anhand des Gateways auswählen was er nutzt, der
> User soll
> > > > keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss
> darauf
> > > > haben"
> > > >
> > > > Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt
> aus den
> > > > ganzen Meinungen zusammen gesammelt habe:
> > > >
> > > > Es gibt ein fff-vpn Packages, dieses prüft was der Gateway
> unterstützt und
> > > > aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt
> bzw.
> > > > /usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.
> > > > /usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart
> mit
> > > > keyxchange und bimmbalabim nur das es eben l2tp startet und fastd
> > > > "blockiert" (wie auch immer das am Ende aussieht oder nutzt man doch
> > > > beides pararell wenn beides von den GWs untersützt wird?). Bevorzugt
> nutzt
> > > > es l2tp weil es besser ist.
> > > >
> > > > Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns
> Daten
> > > > ziehen und abgleichen" ins fff-vpn aus und startet dann nur noch das
> > > > entsprechende fff-fastdstart oder fff-tunneldigger aus dem fff-vpn?
> > > > Gefällt mir fast noch besser ist mir gerade gekommen die Idee muss
> man
> > > > nochmal drüber nachdenken ob das $"so einfach"$ ist.
> > > >
> > > > Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht
> nutzten
> > > > weil wegen scheiße" stellen wir es an den Gateways ab und die Router
> > > > springen alle automatisch auf fastd um.
> > > >
> > > > Gibt es noch weitere Meinungen zu diesen vorgehen?
> > > >
> > > > mfg
> > > >
> > > > Christian
> > > >
> > > > > Moexe <moexe at freifunk-franken-hassfurt.de> hat am 6. April 2016
> um 10:39
> > > > > geschrieben:
> > > > >
> > > > > Hi
> > > > >
> > > > > > Am 06.04.2016 um 10:09 schrieb Robert Langhammer <
> rlanghammer at web.de>:
> > > > > >
> > > > > > Hallo,
> > > > > >
> > > > > >> On 06.04.2016 06:20, Christian Dresel wrote:
> > > > > >> Guten Morgen
> > > > > >>
> > > > > >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn
> einbauen?
> > > > > >>
> > > > > >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
> > > > > >> wenn nein schalte auf fastd um
> > > > > >> mehr muss dieses fff-vpn ja schon fast nicht tun.
> > > > > >>
> > > > > >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen
> > > > > >> Tunneldigger
> > > > > >> verwenden will (warum auch immer) und man ist flexibel und deckt
> > > > > >> alles ab was
> > > > > >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann
> man auch
> > > > > >> noch
> > > > > >> anzeigen machen zu welchen GW man verbunden ist usw...
> > > > > >>
> > > > > >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es
> gibt
> > > > > >> ja bereits
> > > > > >> eine "Firmware für interessierte" du siehst ja wie extrem stark
> die
> > > > > >> genutzt
> > > > > >> wird... *Ironie* ;)
> > > > > > Ja, und es steckt viel Wahrheit drin, die man gern vergisst,
> wenn man
> > > > > > am
> > > > > > Router rum bastelt.
> > > > > > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er
> > > > > > lieber
> > > > > > fastd oder l2tp verwenden möchte, es muss gehen.
> > > > > > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil
> auf
> > > > > > den
> > > > > > Gateways fastd sehr viel CPU braucht und man sich von l2tp
> > > > > > Verbesserung
> > > > > > erhofft.
> > > > > > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre
> gut,
> > > > > > wenn ich am Gateway sagen kann, ich biete diesen oder jenen
> Tunnel an
> > > > > > und die Router bekommen das mitgeteilt und machen.
> > > > > Sehe ich genauso.
> > > > > >
> > > > > > Hier ist immer wieder vom dezentralen keyXchange die Rede, der
> diese
> > > > > > Informationen verteilen würde. Gibt es dazu schon etwas zum
> schlau
> > > > > > machen?
> > > > > >
> > > > > Hier gibt's schon was:
> > > > >
> > > > >
> https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
> > > > >
> > > > > Grüße
> > > > >
> > > > > Moexe
> > > > > > Robert
> > > > > >> mfg
> > > > > >>
> > > > > >> Christian
> > > > > >>
> > > > > >>> --
> > > > > >>> franken-dev mailing list
> > > > > >>> franken-dev at freifunk.net
> > > > > >>>
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > > >
> > > > > > --
> > > > > > franken-dev mailing list
> > > > > > franken-dev at freifunk.net
> > > > > >
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > > --
> > > > > franken-dev mailing list
> > > > > franken-dev at freifunk.net
> > > > >
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > --
> > > >  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/20160406/f8a2ebe7/attachment-0002.html>


Mehr Informationen über die Mailingliste franken-dev