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

mayosemmel mayosemmel at googlemail.com
Mi Apr 6 18:14:33 CEST 2016


Hi,

wir sollten nur vermeiden, das zu einem GW 2 Tunnel aufgebaut werden.
Das wäre der Performance vermutlich nicht dienlich.

Grüße Jan

Am Mittwoch, den 06.04.2016, 12:10 +0200 schrieb Christian Dresel:
> 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 Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160406/cb174ff6/attachment-0002.sig>


Mehr Informationen über die Mailingliste franken-dev