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

Mi Apr 6 12:10:32 CEST 2016

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