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

Robert rlanghammer at web.de
Di Apr 5 23:54:02 CEST 2016


Hallo Tim,


Am 05.04.2016 um 22:19 schrieb Tim Niemeyer:
> Hi
>
> Am Dienstag, den 05.04.2016, 14:31 +0200 schrieb Robert Langhammer:
>> +define Package/fff-tunneldigger-testing
>> +    SECTION:=base
>> +    CATEGORY:=Freifunk
>> +    TITLE:= Freifunk-Franken tunneldigger
>> +    URL:=http://www.freifunk-franken.de
>> +    DEPENDS:=+tunneldigger +fff-tunneldigger
> Hier stimmt was nicht.
>
> fff-tunneldigger-testing hängt von tunneldigger und fff-tunneldigger ab.
> Klingt logisch. Aber fff hängt von fff-tunneldigger ab, welches von
> tunneldigger abhängt.
> Letztlich wird aber fff-tunneldigger-testing nicht gewählt.
Genau, da habe ich vorhin schon viel gelernt.
>
>> +endef
>> +
>> +define Package/fff-tunneldigger-testing/description
>> +    This is a temporarily package and will be removed 
>> +    after testing stage.
> Wenn das nur temporär ist, wo soll die Funktionalität dann später mal
> hin? Weiter: Warum entfernst du fastd, wenn dieses nur testing ist?
>
> Ich würde vorschlagen, dass der Inhalt dieses Packages mit in das
> fff-tunneldigger kommt. Ich vermute mal, da soll es auch langfristig
> hin.
>
> Dann bauen wir fff-tunneldigger und fff-fastd so, dass sie beide
> parallel im Image sein können und beide nicht die Vorherschaft
> übernehmen.
> Ein neues Package "fff-vpn" hängt dann von fff-tunneldigger und
> fff-fastd ab. Als Config-Option kann man da drin die default VPN Technik
> wählen. fff-vpn aktiviert dann beim firstboot entweder tunneldigger oder
> fastd und kann idealerweise mit einem kleinen Befehl zwischen den VPNs
> umschalten oder vllt sogar beides gleichzeitig aktivieren?
>
> Tim
Ich denke auch, dass wir da hin kommen sollten. Mir gefällt die Idee,
das offen und modular zu machen, dann kann jeder der mag seine
VPN-Lösung einbauen.

Im Moment ist es so, dass nur wenige Gateways einen Broker haben und ich
versucht habe darauf dynamisch zu reagieren. Ich wollte nicht im
fff-fastd irgend was einbauen, was wir später nicht mehr brauchen und
diese Art hier den tunneldigger zu konfigurieren werden wir auch nicht
übernehmen. Das ist absolut keine gute Lösung. Darum dieses package, das
erst mal eine fall-back Lösung ist mit bevorzugtem l2tp.
 
Wir haben hier in der Hasberg Hood bis jetzt 5 l2tunnel. Da können wir
eigentlich noch keine Aussage treffen, ob l2tp überhaupt eine stabile
Alternative ist, und wir die Sache richtig einbauen sollten.
Die Idee ist, mit einer Firmware für Interessierte, die man einfach nur
flasht und wenn l2tp nicht geht fastd macht, noch ein paar Tunnel mehr
zu bekommen. 
Dann können wir sehen, was die Gateways machen.

Falls wir uns dafür entscheiden l2tp auf zu nehmen und wir einen Weg
haben die Broker an die Router zu verteilen (irgend ein keyxchange ) ist
das fff-tunneldigger schnell gebaut

Wie müssen die Einrückungen sein? Tabs oder nur einheitlich?

Sory wegen dem Wlanslovenia Patch. Mir ist es nicht gelungen den
einzuspielen, Fehlermeldungen. Da ich mich mit git noch nicht so gut
auskenne, habe ich einfach deine Anleitung nochmal abgetippt. Dann ging es.

Testen von Vars in "" ist klar. Das kommt von copy and paste ohne
Hirnaktivität. Danke!

Robert

>


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160405/51c952a9/attachment-0002.sig>


Mehr Informationen über die Mailingliste franken-dev