<p dir="ltr">Alles klar :)<br>
Dann lassd es uns angehen :)<br>
Haßberge ist gerüstet! :-D</p>
<div class="gmail_quote">Am 06.04.2016 12:10 nachm. schrieb "Christian Dresel" <<a href="mailto:fff@chrisi01.de">fff@chrisi01.de</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
das ist wohl das klassische "Henne-Ei" Problem. Die Gatewaybetreiber stellen<br>
erst um wenn es nötig ist, die Firmwarebauer erst wenn alle Gateways umgestellt<br>
sind. Irgendwer muss ausbrechen und mit dem Umbau der Firmware ist das einfacher<br>
und in meinen Augen "logischer" ;)<br>
<br>
- Es werden eh nicht auf einen schlag alle Router in einer Hood geupdatet, das<br>
kommt erst nach und nach<br>
- Wenn sich dann ein Gateway irgendwann langweilt weil niemand mehr fastd<br>
verwendet gibt es 2 Möglichkeiten:<br>
1) Der Gatewaybetreiber stellt dann doch irgendwann um<br>
2) Der Gatewaybetreiber hat wohl kein Interesse mehr das Gateway zu betreiben ;)<br>
<br>
Das ganze an die Gatewayselection koppeln gefällt mir nicht wirklich auch wenn<br>
es u.U. denkbar wäre (man kann am Router auslesen welches GW in der Selection<br>
gewählt wurde und prüfen ob das l2tp kann und dann nur verbinden wenn es<br>
kann...).<br>
<br>
Da alle l2tp Gateways auch noch im fastd VPN hängen, sollte auch nicht die<br>
Situation entstehen das ein Router l2tp macht aber in der Gatewayselection ein<br>
unereichbares Gateway hat, der Weg sollte in diesem Fall sein:<br>
<br>
GW1: nur fastd<br>
GW2: fastd und l2tp<br>
<br>
Router hat nur eine l2tp zu GW2 aber in der Gatewayselection GW1 stehen, er<br>
erreicht dieses GW zwar nicht direkt aber über l2tp das GW2 und dort durch den<br>
fastd VPN müsste er dann GW1 erreichen, gut man hat doppelten Traffic und einen<br>
Hop mehr, die Situation sollte man schon vermeiden da gilt dann aber wieder:<br>
<br>
Die Gatewaybetreiber einer Hood sollten sich absprechen (sollten sie eh immer,<br>
nicht nur in diesem Fall), wenn sie das nicht machen entsteht halt so was<br>
unschönes, ich sehe das aber nicht als unser ("Firmwareentwickler") Problem an.<br>
<br>
mfg<br>
<br>
Christian<br>
<br>
> Alex Gutfried <<a href="mailto:alexgutfried@gmail.com">alexgutfried@gmail.com</a>> hat am 6. April 2016 um 11:31<br>
> geschrieben:<br>
><br>
> Oder aber es wird zuerst die gw selection angeschaut und dann für den<br>
> ausgewählten server individuell entschieden ob l2tp oder fastd.<br>
> Ist das möglich?<br>
> Am <a href="tel:06.04.2016%2011" value="+49604201611">06.04.2016 11</a>:27 vorm. schrieb "Alex Gutfried" <<a href="mailto:alexgutfried@gmail.com">alexgutfried@gmail.com</a>>:<br>
> > Bevor wir diese Firmware veröffentlichen muss aber sicher gestellt werden<br>
> > das annähernd alle GWs den l2tp broker eingerichtet haben.<br>
> > Okay wenn keiner da ist, nutzen alle fastd doch wenn ein Gateway den Broker<br>
> > hat verbinden sich alle Router (mit aktueller Firmware) mit diesen einen<br>
> > Server. Hm da macht sie gw selection auch nicht mehr viel. ;)<br>
> ><br>
> > Am <a href="tel:06.04.2016%2011" value="+49604201611">06.04.2016 11</a>:12 vorm. schrieb "Christian Dresel" <<a href="mailto:fff@chrisi01.de">fff@chrisi01.de</a>>:<br>
> > > Hi<br>
> > ><br>
> > > dann seh ich das richtig das wir praktisch alle 3 der gleichen Meinung<br>
> > > sind:<br>
> > ><br>
> > > "Der Router soll anhand des Gateways auswählen was er nutzt, der User soll<br>
> > > keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss darauf<br>
> > > haben"<br>
> > ><br>
> > > Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt aus den<br>
> > > ganzen Meinungen zusammen gesammelt habe:<br>
> > ><br>
> > > Es gibt ein fff-vpn Packages, dieses prüft was der Gateway unterstützt und<br>
> > > aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt bzw.<br>
> > > /usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.<br>
> > > /usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart mit<br>
> > > keyxchange und bimmbalabim nur das es eben l2tp startet und fastd<br>
> > > "blockiert" (wie auch immer das am Ende aussieht oder nutzt man doch<br>
> > > beides pararell wenn beides von den GWs untersützt wird?). Bevorzugt nutzt<br>
> > > es l2tp weil es besser ist.<br>
> > ><br>
> > > Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns Daten<br>
> > > ziehen und abgleichen" ins fff-vpn aus und startet dann nur noch das<br>
> > > entsprechende fff-fastdstart oder fff-tunneldigger aus dem fff-vpn?<br>
> > > Gefällt mir fast noch besser ist mir gerade gekommen die Idee muss man<br>
> > > nochmal drüber nachdenken ob das $"so einfach"$ ist.<br>
> > ><br>
> > > Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht nutzten<br>
> > > weil wegen scheiße" stellen wir es an den Gateways ab und die Router<br>
> > > springen alle automatisch auf fastd um.<br>
> > ><br>
> > > Gibt es noch weitere Meinungen zu diesen vorgehen?<br>
> > ><br>
> > > mfg<br>
> > ><br>
> > > Christian<br>
> > ><br>
> > > > Moexe <<a href="mailto:moexe@freifunk-franken-hassfurt.de">moexe@freifunk-franken-hassfurt.de</a>> hat am 6. April 2016 um 10:39<br>
> > > > geschrieben:<br>
> > > ><br>
> > > > Hi<br>
> > > ><br>
> > > > > Am <a href="tel:06.04.2016" value="+496042016">06.04.2016</a> um 10:09 schrieb Robert Langhammer <<a href="mailto:rlanghammer@web.de">rlanghammer@web.de</a>>:<br>
> > > > ><br>
> > > > > Hallo,<br>
> > > > ><br>
> > > > >> On <a href="tel:06.04.2016%2006" value="+49604201606">06.04.2016 06</a>:20, Christian Dresel wrote:<br>
> > > > >> Guten Morgen<br>
> > > > >><br>
> > > > >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?<br>
> > > > >><br>
> > > > >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es<br>
> > > > >> wenn nein schalte auf fastd um<br>
> > > > >> mehr muss dieses fff-vpn ja schon fast nicht tun.<br>
> > > > >><br>
> > > > >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen<br>
> > > > >> Tunneldigger<br>
> > > > >> verwenden will (warum auch immer) und man ist flexibel und deckt<br>
> > > > >> alles ab was<br>
> > > > >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch<br>
> > > > >> noch<br>
> > > > >> anzeigen machen zu welchen GW man verbunden ist usw...<br>
> > > > >><br>
> > > > >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt<br>
> > > > >> ja bereits<br>
> > > > >> eine "Firmware für interessierte" du siehst ja wie extrem stark die<br>
> > > > >> genutzt<br>
> > > > >> wird... *Ironie* ;)<br>
> > > > > Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man<br>
> > > > > am<br>
> > > > > Router rum bastelt.<br>
> > > > > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er<br>
> > > > > lieber<br>
> > > > > fastd oder l2tp verwenden möchte, es muss gehen.<br>
> > > > > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf<br>
> > > > > den<br>
> > > > > Gateways fastd sehr viel CPU braucht und man sich von l2tp<br>
> > > > > Verbesserung<br>
> > > > > erhofft.<br>
> > > > > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,<br>
> > > > > wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an<br>
> > > > > und die Router bekommen das mitgeteilt und machen.<br>
> > > > Sehe ich genauso.<br>
> > > > ><br>
> > > > > Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese<br>
> > > > > Informationen verteilen würde. Gibt es dazu schon etwas zum schlau<br>
> > > > > machen?<br>
> > > > ><br>
> > > > Hier gibt's schon was:<br>
> > > ><br>
> > > > <a href="https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement" rel="noreferrer" target="_blank">https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement</a><br>
> > > ><br>
> > > > Grüße<br>
> > > ><br>
> > > > Moexe<br>
> > > > > Robert<br>
> > > > >> mfg<br>
> > > > >><br>
> > > > >> Christian<br>
> > > > >><br>
> > > > >>> --<br>
> > > > >>> franken-dev mailing list<br>
> > > > >>> <a href="mailto:franken-dev@freifunk.net">franken-dev@freifunk.net</a><br>
> > > > >>> <a href="http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net" rel="noreferrer" target="_blank">http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net</a><br>
> > > > ><br>
> > > > > --<br>
> > > > > franken-dev mailing list<br>
> > > > > <a href="mailto:franken-dev@freifunk.net">franken-dev@freifunk.net</a><br>
> > > > > <a href="http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net" rel="noreferrer" target="_blank">http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net</a><br>
> > > > --<br>
> > > > franken-dev mailing list<br>
> > > > <a href="mailto:franken-dev@freifunk.net">franken-dev@freifunk.net</a><br>
> > > > <a href="http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net" rel="noreferrer" target="_blank">http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net</a><br>
> > > --<br>
> > > franken-dev mailing list<br>
> > > <a href="mailto:franken-dev@freifunk.net">franken-dev@freifunk.net</a><br>
> > > <a href="http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net" rel="noreferrer" target="_blank">http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net</a><br>
</blockquote></div>