Client bekommt keine IPv6, IPv4 liefert keine funktionsfähigen Routen

Welches Problem liegt vor, wenn ein Client zwar eine IPv4 Zuweisung bekommt aber keine IPv6?

Meine bisherige Annahme war, dass die IPv6 lokal vergeben bzw. einfach genommen wird.

Es funktioniert in diesem Beispiel-Netz übrigens nichts. Die ipv4 Routen versagen sofort und mangels Existenz von IPv6 kann man auch nicht die einzelnen nodes im mesh erreichen.

  1. Ist ein fastd Tunnel aufgebaut? Es wurde ja eine IPv4 vergeben.
  2. Wie kann es sein, dass IPv6 nicht vergeben wird?
  3. Wie kann ein node in diesen Status kommen? Der Uplink ist per direktem LAN-Kabel realisiert. Ein anderer Uplink im gleichen LAN funktioniert einwandfrei.

// Domäne Ruhrgebiet, gluon 0.6, mesh vpn aktiv, mesh on wan inaktiv

//2:

Man kann sich aus dem Freifunknetz zu dem „defekten-uplink-node“ per IPv6 verbinden.
Es funktioniert also quasi nur die Wlan-Einheit nicht. Tunnel zum gateway steht.

Nach Einloggen und Ausführen von „batctl gw“ den zuständigen gateway rausgesucht und angepingt:

batctl p 02:bf:ef:ca:fe:6b
PING 02:bf:ef:ca:fe:6b (02:bf:ef:ca:fe:6b) 20(48) bytes of data
Reply from host 02:bf:ef:ca:fe:6b timed out
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=2 ttl=50 time=33.90 ms

20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=3 ttl=50 time=30.58 ms
Reply from host 02:bf:ef:ca:fe:6b timed out
Reply from host 02:bf:ef:ca:fe:6b timed out
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=6 ttl=50 time=51.92 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=7 ttl=50 time=39.19 ms
Reply from host 02:bf:ef:ca:fe:6b timed out
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=9 ttl=50 time=99.24 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=10 ttl=50 time=73.69 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=11 ttl=50 time=44.72 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=12 ttl=50 time=32.48 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=13 ttl=50 time=145.65 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=14 ttl=50 time=62.49 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=15 ttl=50 time=69.73 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=16 ttl=50 time=50.07 ms
Reply from host 02:bf:ef:ca:fe:6b timed out
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=18 ttl=50 time=38.48 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=19 ttl=50 time=34.98 ms
20 bytes from 02:bf:ef:ca:fe:6b icmp_seq=20 ttl=50 time=38.70 ms
^C— 02:bf:ef:ca:fe:6b ping statistics —
20 packets transmitted, 15 received, 25% packet loss
rtt min/avg/max/mdev = 30.576/56.388/145.650/30.162 ms

Ca. 25%packet loss bei mehreren Versuchen. Wie kommt dieser immense packet loss zustande, wenn zwischen node und gateway nur Kabelverbindungen existieren?
Für mich bleibt nur der Rückschluss, dass ein Kabel defekt sein muss. Andere Vorschläge? Das ersetzen der Kabel ist etwas umständlich und wird mich eine Weile kosten…

Wie ist denn die Netzlast auf dem Segment? Kann es sein, dass es da irgendeine Form von Packetstorm gibt, z.B. zwischen zwei Gateways, weil interfaces nicht nur per Batman, sondern auch noch (zusätzlich) per normaler bridge kurzgeschlossen wurden?

Gibt es denn in dem Netzsegment überhaupt einen funktionsfähigen dhcp-server und einen radv-Dienst?

Nein. Der hintere Teil der IPv6 wird zwar aus der Mac generiert, aber der fordere (in manchen Communities globale) Teil muss vom Gateway festgelegt sein.

1 Like

Und wenn gerade kein uplink vorhanden ist wird eine „temporäre ipv6“ vergeben?

Ganz ohne uplink gibt es nämlich im mesh keine Probleme alle nodes zu erreichen und das geschieht ja auch über ipv6.

Ipv6 hat glaub auch immer so einen lokalen Link, das ist richtig. Es können aber auch die noch gültigen Leases sein, als noch Internet da war.

Funktioniert das lokale Mesh auch, wenn schon beim einschalten kein Uplink da war?

Ja genau.
Dann ist also eine Ip dieser Art vom gateway vergeben:
2a03:2260:50:1:16cc:20ff:fe6e:1d82

Und diese hier vom Knoten selbst gewählt:
fe80:0:0:0:16cc:20ff:fe6e:1d82

Laut IPv6 – Wikipedia gilt die letztere also im gesamten Freifunk-Ruhrgebiet, da bis dort unser Layer2 reicht? Danach wird ja geroutet…

Wieder was gelernt :slight_smile: