root@luggage:~# traceroute -T -4 heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 60 byte packets
1 10.255.0.2 (10.255.0.2) 62.402 ms 62.564 ms 70.780 ms
2 bgp-fra01.4830.org (193.26.120.81) 73.514 ms 73.517 ms 73.504 ms
3 bgp-ham02.4830.org (193.26.120.85) 84.281 ms 84.174 ms 84.235 ms
4 te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 93.491 ms 93.498 ms 97.707 ms
5 * * *
6 * * *
7 * * *
8 212.19.61.13 (212.19.61.13) 82.512 ms 82.688 ms 82.678 ms
9 redirector.heise.de (193.99.144.80) 82.645 ms 82.423 ms 82.637 ms
root@luggage:~# traceroute -T -6 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 30 hops max, 80 byte packets
1 2001:bf7:1316:666::1 (2001:bf7:1316:666::1) 71.047 ms 97.667 ms 97.677 ms
2 bgp-fra01.4830.org (2a06:e881:1707:1::1) 101.051 ms 101.055 ms 104.286 ms
3 2001:868:100:6b00::4 (2001:868:100:6b00::4) 108.586 ms 108.536 ms 108.571 ms
4 10ge15-8.core1.ham1.he.net (2001:7f8:3d::1b1b:0:1) 108.414 ms 108.437 ms 108.427 ms
5 * * *
6 ams-ix-v6.nl.plusline.net (2001:7f8:1::a501:2306:1) 119.757 ms 94.261 ms 387.496 ms
7 2a02:2e0:14:6::1 (2a02:2e0:14:6::1) 387.443 ms * *
8 2a02:2e0:12:31::2 (2a02:2e0:12:31::2) 387.341 ms 390.090 ms 389.489 ms
9 2a02:2e0:3fe:0:c::1 (2a02:2e0:3fe:0:c::1) 390.084 ms 390.069 ms 390.123 ms
10 redirector.heise.de (2a02:2e0:3fe:1001:302::) 390.020 ms 390.050 ms *
Das ist mit einem TL-WA860RE v1 mit 1.0.2~5 in “zzz” — als Test für den Puppet-Code für L2TP-GWs. Dabei fällt mir dann spontan ein, daß ich noch 'ne Lösung für die verschiedenen Karten brauche, hrmpft (Zugang erfolgt derzeit über Vodafone LTE, Durchsatzmessung also weniger zweckmäßig. Daher auch die hohe RTT.)
Ich sehe keine Notwendigkeit für IPv4-basierte Kommunikation zwischen Endgeräten in den Meshes — Freifunk-Dienste können über IPv6 angeboten werden und damit innerhalb und außerhalb des Freifunks genutzt:
root@luggage:~# traceroute -T -6 forum.freifunk.net
traceroute to forum.freifunk.net (2a03:2260:2000:1::2), 30 hops max, 80 byte packets
1 2001:bf7:1316:666::1 (2001:bf7:1316:666::1) 68.887 ms 69.322 ms 79.447 ms
2 bgp-fra01.4830.org (2a06:e881:1707:1::1) 79.609 ms 79.604 ms 81.250 ms
3 de5.as206946.net (2a06:e881:2603:42::1) 79.571 ms 81.115 ms 81.183 ms
4 de2.as206946.net (2a06:e881:2604:42::1) 104.859 ms 104.876 ms 104.868 ms
5 p0.irz42NET.transit.wusel.uu.org (2a00:14b0:4200:3500::136:137) 104.878 ms 104.838 ms 104.828 ms
6 2a03:2260::3 (2a03:2260::3) 91.796 ms 74.767 ms 103.290 ms
7 forum.freifunk.net (2a03:2260:2000:1::2) 103.259 ms 103.324 ms 103.334 ms
root@luggage:~# traceroute -T -6 2001:bf7:1310:11:fad1:11ff:febd:5e24
traceroute to 2001:bf7:1310:11:fad1:11ff:febd:5e24 (2001:bf7:1310:11:fad1:11ff:febd:5e24), 30 hops max, 80 byte packets
1 2001:bf7:1316:666::1 (2001:bf7:1316:666::1) 83.908 ms 83.881 ms 94.774 ms
2 bgp-fra01.4830.org (2a06:e881:1707:1::1) 94.755 ms 94.724 ms 94.692 ms
3 bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277) 94.667 ms 94.653 ms 94.655 ms
4 2a06:e881:1700:1:400:c0ff:fefb:e251 (2a06:e881:1700:1:400:c0ff:fefb:e251) 94.615 ms 94.598 ms 94.590 ms
5 2001:bf7:1310:11:fad1:11ff:febd:5e24 (2001:bf7:1310:11:fad1:11ff:febd:5e24) 128.209 ms 131.153 ms 131.205 ms
Wenn man v4 als reinen “Internet-Zugringerdienst” sieht – für mehr taugt es auch nicht mehr –, wird sowohl das Netzdesign als auch die Firmwareverwaltung deutlich weniger komplex. Comments?
Weil das vielleicht etwas zu technisch-abgekürzt war: es geht darum, ob ein Endgerät z. B. im “zzz”-Mesh ein Endgerät z. B. im “gut”-Mesh über das veraltete Internetprotokoll Version 4 (IPv4) erreichen können soll. In dem Falle brauchen wir für jedes Mesh disjunkte IPv4-Netzbereiche – also z. B. 10.255.0.0 bis 10.255.15.255 für “gut”, 10.255.16.0 bis 10.255.31.255 für “zzz”, … – und müßten diese sogenannten “privaten” Adressen in unserem Backbone routen, die anderen Netzbereiche jeweils in der Firmwares hinterlegen, …
Relevant würde das einzig, wenn ein Nutzer mit seinem Smartphone im “zzz”-Mesh z. B. einen Feinstaubsensor im “gut”-Mesh direkt ansprechen wollen würde — letztere können nämlich leider auch noch nicht mit dem heute aktuellen Adressformat, IPv6, umgehen. (Über IPv6 ist das alles kein Problem, da dort für wirklich jedes Endgerät auf diesem Planeten ein paar Adressen verfügbar sind.)
Hmm, evtl. könnte man auch Proxys einsetzen, die über v4 erreichbar sind und dann Traffic von v6 Adressen an v4 weiterleiten. Könnte nur mit der DNS Auflösung dann etwas harig werden. Würde aber das Augenmerks auch eher auch funktionierendes v6 Routing in beiden Richtungen setzen.
Du kannst auch heute keine Dienste auf v4 hosten, die außerhalb des Meshes erreichbar sind (Theorie, ICVPN funktioniert und es gibt dort ‘Dienste’, mal außen vor).
Was beim Netsplit bedeutet, je nach Entscheidung, daß nachher jemand z. B. aus Gütersloh nicht mehr auf z. B. Feinstaubsensoren in Halle direkt zugreifen kann — diskussionswert: war das vom ‘Feinstaubsammler’ überhaupt gewünscht?
(Aber Du kannst natürlich jetzt oder später z. B. auf 'nem RPi einen Proxy laufen lassen und damit Deinen Feinstaubsensor öffentlich, über IPv6, zugänglich machen.)
Vorteil, v4 auf das jeweilige Mesh zu begrenzen: ‘thisnode’, also die spezielle IP die auf jedem Knoten lokal bleibt (und aus technischen Gründen im IP-Nummernkreis des lokalen Meshs liegen muß), wäre überall im Kreis GT 10.255.0.1 (Müritz/Feldberg: 10.169.0.1).
Nachteil: über IPv4 kann man nur mit öffentlichen Adressen, kommunizieren (und im eigenen Mesh). Frage: Wie oft hat jemand einen anderen Client im Freifunk über IPv4 kontaktiert?
Nur wenn v6 aus welchen Gründen auch immer gerade nicht funktioniert hat. Und dann war es schon aus Wiedenbrück nach Langenberg oder Rietberg. Deshalb sage ich ja funktionierendes v6.
Wenn v4 von jemandem gebraucht wird muss er/sie halt über einen Proxy gehen. Hmm, wobei dann müssten zumindestens die vom DHCP vergebenen in verschiedenen Ranges liegen.
…
Das Problem besteht doch hauptsächlich bei der 10.255.0.1, oder? Kann der Knoten die nicht selber per iptables umbiegen auf sich? Egal in welchen Subnetz der Client ist
Ich meine nicht; der Trick an der IP ist, daß sie im LAN gesucht wird (da im IP-Bereich der Client-IPs), über ebtables die Weiterleitung in der br-client blockiert wird und somit der Knoten antworten kann. Ich bin mir nicht sicher, ob man das mit beispielsweise 6.6.6.6 auch hinbekäme.
Hmm, aber das Problem läßt sich ja auch anders angehen: statt v4 gleich zu halten, kann man das ja mit den “privaten” v6-Adressen (ULA) machen.
Die werden in verbundenen Meshes weder geroutet noch verwendet (dafür gibt’s den öffentlichen Prefix), in nicht verbundenen ist es auch egal, daß diese nicht eindeutig sind — das lokale Mesh ist ja isoliert. Damit könnte man z. B. http://[fd10:ca1::1] zur neuen generischen Knoten-URL machen (und das für v4 kompett entfallen lassen, da Knoten eigentlich eh’ kein v4 machen), bißchen doof einzugeben, aber machbar. »master«, »rawhide« und »tng« wurde heute vormittag entsprechend gebaut. mal gucken, ob das so klappt.
Dann würde IPv6 aber auch nicht weiter helfen.
Mit http://[fd10:ca1::1] hätte man doch das selbe Problem, mit den unterschiedlichen Subnetzen.
Oder sehe ich das jetzt verkehrt?
Gibt es noch einen andere Funktion dieser IP als das einloggen bei Debugen falls der Knoten Offline ist?
Jein: bei IPv4 wird je Mesh ein Netz 10.x.y.0/z verwendet, um die Clients zu den (NAT-) Gateways zu routen. 10.x.y.1/z (strenggenommen w.x.y.1/z) wird dabei auf dem jeweiligen Knoten terminiert (ein Knoten hat im Freifunk-Mesh keine eigene IPv4-Adresse), liegt also auf jedem Knoten (und ist von den Gateways aus nicht erreichbar, da der Datenverkehr zu der IPv4-Adresse in Gluon nur zwischen WLAN & Knoten erlaubt wird (ebtables)).
Anders als bei IPv4, haben (in unserem Setup) bei IPv6 alle Geräte im Netz, also Knoten als auch Endgeräte, (mindestens) eine eindeutige, öffentliche IPv6-Adresse.
Parallel dazu sind die Knoten auch noch im sog. ULA-Netz präsent und jeder Knoten teilt aktiv diesen Präfix mit. Da das Netz und alle relevanten Netzkomponenten – z. B. Clients – IPv6-fähig sind, kann man den Fakt, daß wir bei IPv6 mehrere Adressierungsbereiche haben – das öffentliche Internet sowie das lokale Mesh – auch nutzen. Die ULA-Netzbereiche müssen nicht miteinander verbunden werden, da diese per Definition »lokal« sind. Zwischen Meshes kann man über die öffentliche IPv6-Adressen sich verbinden.
Aber bei IPv4 haben wir nur den lokalen Adressebereich, hier muß man, um Datenverkehr zwischen dem Meshes ohne NAT zu ermöglichen, unterschiedliche private IPv4-Adressebereiche nutzen.
Die ULA-Adressen “vergibt” jeder Knoten (SLAAC “vergibt” keine konkreten IPv6-Adressen an Endgeräte, sondern teilt diesen vielmehr mit, aus welchem Adressbereich – Präfix – sie sich bedienen sollen), damit ist das Netz/Mesh auch noch funktional, wenn keine Internetverbindung mehr besteht. Die Info über den öffentlichen Präfix als auch die Zuweisung einer IPv4-Adresse je Client kommt aus dem Rechenzentrum — kurz: über ULA kann auch im lokalen Netz/Mesh Datenverkehr stattfinden. That said: ja, faktisch eine Bedeutung hat ULA heute nur für’s Debugging.
Mit der Adresse http://[fd10:ca1::1] klappt soweit auf allen APs, (außer wenn aus welchen gründen auch immer das IPv6 Autoconfig versagt. DHCPv4 scheint einfach noch stabiler zu laufen)
Aber gut die Seite 10.255.0.1 wird eigentlich ja sowiso nur für technisch versierte Personen gebraucht. Also, sollte das kein Problem darstellen.
Per Befehl war ein neustart nicht möglich. Der Reboot Befehl wurde nicht mehr ausgeführt. Habe den Stecker gezogen. Danach war wieder alles OK. Werde das mal beobachten.
(Trotz der Last hatte ich aber immer noch einen Durchsatz von 30 Mbit/s)
