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

Alex Gutfried alexgutfried at gmail.com
Mi Apr 6 11:27:19 CEST 2016


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/3c2d14ef/attachment-0002.html>


Mehr Informationen über die Mailingliste franken-dev