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

[Christian Dresel]

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
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160406/f6001148/attachment-0002.html>