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

Di Mär 29 21:33:33 CEST 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo Jan,

ja die Sache mit der mtu und der mac hat uns die größten Probleme
bereitet. Batman mag es nicht, wenn sich das bei einem eingehängten
Device laufend ändert. Die mtu ändert sich ständig, da die Slovenen den
Tunneldigger so schlau gemacht haben, dass er mit dem Broker laufend die
beste mtu austestet und dann setzt. Darum landen alle Tunnel mit der
gleichen mac in einer Bridge. Ändert sich die mac, stöpseln wir in die
passende Bridge um.
Bridges ändern normalerweise die mac hin zur niedrigsten angesteckten.
Jetzt kommen und gehen die Tunnel und ändern die mac der Bridge. Das
kann man verhindern, indem man der Bridge eine feste Adresse zuweist,
die wir aus der mtu generiert haben. Vorne eine 0a, weil das eine LAA
(Locally Administered Address Range) ist, dann ein paar stellen für
Gateway und Hood, und zum Schluss  2 Stellen mtu->mac.

Das waren die Gründe und Gedanken, warum ich das erst mal so gemacht habe.
Hoffe hilft.

Robert

Am 29.03.2016 um 18:59 schrieb mayosemmel:
> Hallo zusammen,
>
> ich hab mir das im Wiki auch mal kurz angeschaut.
> Grundsätzlich finde ich das alles ziemlich gut und hatte auch schon
> überlegt was in dieser Richtung zu machen. Werde eure Lösung vermutlich
> die nächsten Tage auch mal auf meinem GW implementieren. Zzt. habe die
> ganzen l2tp Interfaces direkt am batman hängen.
>
> Eine Sache verstehe ich aber noch nicht ganz. Wieso generiert ihr die
> Mac Adresse aus der MTU? Die MTU ist ein statischer wert und somit nicht
> geeignet irgendwas zu generieren?! Weiterhin ist bei "pro GW erhöhen"
> die Gefahr von Mac-Konflikten relativ hoch und das führt zu sehr blöden
> Problemen, die sich auch schlecht finden lassen.
>
> Ich würde folgendes vorschlagen:
> Die ersten 3 Blöcke komplett auf 0 setzten. Der Bereich gehört
> eigentlich Xerox. Die bauen hauptsächlich Drucker und sowas. Sollte
> relativ unproblematisch sein. Wir wären aber sicher, das wir immer die
> "niedrigste" Mac haben und die Bridge sich somit nicht verändert.
> Die restlichen 3 Blöcke würde ich mit den entsprechenden Blöcken aus
> "eth0" füllen.
>
> Das würde am Beispiel von meinem GW so aussehen:
> ~# ifconfig|grep eth0
> eth0      Link encap:Ethernet  HWaddr 7a:88:63:96:16:41
>
> Bridge wäre also 00:00:00:96:16:41
>
> Dieser Prozess ließe sich sogar komplett automatisieren.
>
> Würde mich interessieren, was ihr dazu meint. Eventuell hab ich auch
> irgendwas komplett übersehen und es gibt doch einen guten Grund für euer
> Vorgehen. Dann würde ich mich über eine Begründung freuen ;-)
>
> Viele Grüße
> Jan
>
> Am Dienstag, den 29.03.2016, 14:33 +0200 schrieb Robert Langhammer:
>> Hi,
>>
>> Am 29.03.2016 um 08:01 schrieb Christian Dresel:
>>> 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).
>> Also hier Vorsicht. das bridge_funktions.sh wird mehrfach gesourced.
>> Auch vom mtu_changed. Da fehlt im Original dei Variable $MTU, die ich
>> noch hinzugefügt habe MTU=$NEW_MTU, damit bei einem mtu-Wechsel die
>> richtigen MACs erzeugt werden.
>> Da scheint was nicht zu passen.
>>
>>>
>>>> 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?
>> Ja, sollte drin sein. Ist ja auch schon im master.
>>>> 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
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJW+tiNAAoJECe5EPUaw0cA1pAP/ita6GWwX21zlkyvlqofaAjN
/sBt56mO9zvV4kNMaprPNVO/kbliuNKOaPTVZwgPY16GDh2uZjPSLAeIvttnmoEq
O6zFc2e6VJKgYaTf+S7U5D8QRfQtyrmeVTcdA8AOHBwCRJB13yoj8k+XAwVgnVNh
HXJh4iUdtyrkrL2LF6hKNLDmG9gbsgWGP5AgRBrmRtUWEgHHFaFkmNOYjkWqBDcj
n9DntYthL082YYBlDBTKrwwuMAvniSffdNKDwExN9Bar1nJsMegvWK7xZWW/hrLn
E20fDyFajkW8CDVJf1LAK+yQ8GxoOkHqQWKzHQ6ks+nG8j4pAMk406O8yXh8PUxi
kDS/qSAdKjqgstoMWU7ZEVr4SIt+v4kcE932x9XHji14lAro03SoOzgn3W3ytaKc
SvWH1AWPPZ3DFD71U9Qr1BZQUVJjFJSnq4ca8Py+ud/JQGW0KLbxa1BGNjF+Pq9w
t9K+3wPl166uCEvz3gq0bjUa/DzQ1hn20RSL0eyQsPLeCbkMmN88270Mq6VvlIil
sJ1s3sGXfbyGmEi0aCt3ntC0BrGwcniSDHh40qaF5y3Me4l9/1QSNDEqjPSLt4aM
rE3aPpr3eykvJxvVNx6e4mgl4g/uT405a/+kVu5gZbm7qpI0x7WV02yljWHzVScQ
ocjCFvhXcde8dhhTpXBl
=2qJe
-----END PGP SIGNATURE-----