[Freifunk Franken] l2tp Tunneldigger in Fürth auf fff-gw-cd1 - Tester gesucht!

Di Mär 29 08:01:03 CEST 2016

Hi Robert (RoLa ahhhh ;))

Am 29.03.2016 um 00:43 schrieb Robert Langhammer:
> Hallo,
> 
> ich habe heute noch die Sache mit den festen MACs ins wiki geschrieben.
> Vergleiche mal die bridge_funktions.sh und die mtu_changed, ob du die
> neuste Version hast.
> Batman kommt sonst durcheinander.

Ich glaube ja, 0a:00:03:01:14:46 und so? Wobei die Endziffer nicht zur
MTU passt:

l2-br-fu1446 Link encap:Ethernet  HWaddr 0a:00:03:01:14:46
          inet6 addr: fe80::800:3ff:fe01:1446/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1438  Metric:1
          RX packets:1217071 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1349401 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:164988455 (157.3 MiB)  TX bytes:221033257 (210.7 MiB)

l2tp1011  Link encap:Ethernet  HWaddr ca:38:bf:b7:2f:9b
          inet6 addr: fe80::c838:bfff:feb7:2f9b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1438  Metric:1
          RX packets:1217071 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1349405 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:196632301 (187.5 MiB)  TX bytes:221033777 (210.7 MiB)
(ist im moment die einzige Verbindung)

wieso fehlen da 6 Bytes?

Achja ich hatte noch ein Problem mit dem Aufruf
. scripts/bridge_functions.sh
in xxx.up bzw. xxx.down und mtu_changed-xxx.sh

Ich hab somit das bridge_functions.sh Script direkt an die Stellen wo es
aufgerufen wird kopiert und dann hat es auch funktioniert. Keine Ahnung
warum sich das Script nicht im Script aufrufen hat lassen (chmod +x und
so hatte es).

> 
> Habt ihr in Fürth mehrere Gateways? Wenn du nur zu einem einen l2tunnel
> hast, solltest du mal schauen was die gw-selection macht!

meinen und nue1 wobei ich nue1 in der Gatewayselection immer deutlich
übertrumpfe (der ist eh zu lahm ;)) also wählt (die gefixte) Gateway
Selection eigentlich immer sicher mein Gateway aus.

> 
> Die Firmware habe ich nochmal neu gemacht. Habe das dual raus genommen,
> da das eigentlich keine gute Option ist und nur Traffic erzeugt.
> Ausserdem schaltet es jetzt vollständig um und bleibt bei Neustart.

Muss man dennoch anfangs manuell einschalten oder geht jetzt alles
automatisch? Werde dann wohl nochmal flashen. Ist das l2tp
Trafficzählfix eigentlich auch schon drinnen?

> 
> Ach ja, die Broker in Has und Hassüd laufen auch wieder, und bis jetzt
> auch stabil.
> 
> Du kannst also auch bestätigen, dass es sich ein so anfühlt, als wäre
> man auf der Überholspur?

theoretisch ja, Problem bei mir ich bin bei der Telekom. Selbst wenn ich
ohne Freifunk was über meinen 50Mbit VDSL Anschluss von meinen
Hetznerserver lade, lande ich bei max. 20-30Mbit [1]. Das ging auch
nahezu durch den fastd und geht jetzt auch l2tp wobei die CPU Last bei
l2tp natürlich gegen 0 geht und bei fastd schon nicht ganz ohne war.
Wäre super wenn es in Fürth mal Leute mit Kabeldeutschland testen, da
ist das peering Problem nicht so schlimm.
(gerne auch Download von [2] dann muss es nicht durch den Mullvad)

mfg

Christian

[1] http://wiki.hetzner.de/index.php/Double_Paid_Traffic
[2] http://10.50.32.4/100mb.test

> 
> Robert
> 
> On 28.03.2016 22:50, Christian Dresel wrote:
>> Hallo zusammen
>>
>> ich hab mich vorhin mal hingesetzt und das Tunneldigger Zeug mit Bridges
>> und gedöns auf meinen Server aufgebaut. Das ganze scheint jetzt zu laufen.
>>
>> Daher meine bitte das ganze unbedingt mal zu testen (nur in der Fürther
>> Hood!!). Rola war so nett eine fertige Firmware dafür zu bauen und den
>> Link ins Wiki zu schreiben. Ich hab die Firmware auf einen 841er v9
>> geflasht und gleich mal 30Mbit durch den Tunnel gejagd :) Die Firmware
>> gibt es hier:
>> http://10.50.60.3/firmware/ oder http://78.47.36.148/firmware/
>> Quelle: https://wiki.freifunk-franken.de/w/L2TP_und_Tunneldigger#Am_Router
>>
>> Nach dem flashen ganz normal im WebUI konfigurieren und dann per SSH
>> verbinden und folgendes ausführen (erst sobald er sicher in der Fürther
>> Hood ist! Lieber 5-10 Minuten warten nach dem Konfigurieren und ein
>> Sicherheitsreboot schadet auch nicht):
>>
>> l2tunnel conf
>> /etc/init.d/tunneldigger start
>> l2tunnel on
>>
>> und schon sollte er einen l2tp Tunnel zu fff-gw-cd1 aufbauen welcher
>> wesentlich perfomanter als das alte fastd VPN sein sollte.
>>
>> Ich hab aktuell hier 2 Router am Internetuplink hängen, einer macht zur
>> Sicherheit noch fastd (
>> https://monitoring.freifunk-franken.de/routers/5664399b44ce6e0307512960
>> ) und der zweite l2tp (
>> https://monitoring.freifunk-franken.de/routers/56f98b069369c317dfbc9630
>> ). Somit hab ich auch noch volle ausfallsicherheit, Batman kümmert sich
>> da schon um die beste Route. Also nicht denken "oh und wenn das
>> ausfällt...?" Einfach ein Backupsystem laufen lassen dann klappt das
>> schon :)
>>
>> Man kann gerne auch mit l2tunnel dual herumspielen, das hab ich bisher
>> noch nicht getestet.
>>
>> Ich würde also alle Fürther bitten das auf jeden Fall mal zu testen.
>> Fehler kann ich und alle anderen erst dann erkennen wenn es mal nicht
>> geht, wenns keiner testet erkennt man auch keine Fehler. Große bitte
>> auch an die Leute zu testen, die viel Traffic erzeugen, denn das würde
>> ich auch gern testen ob da mehr durch geht.
>>
>> Vielen Dank schon mal
>>
>> mfg
>>
>> Christian
>>
>>
>>
>> _______________________________________________
>> franken mailing list
>> franken at freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 
> 
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 

-------------- 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/mailman/private/franken-freifunk.net/attachments/20160329/64869299/attachment.sig>