Hallo Gibt es hier in der Runde jemand der etwas mehr Ahnung von ipv6 hat als ich? Sollte eigentlich nicht so schwer sein. :-) Falls ja würde ich mich über Hilfe auf einem Freifunktreffen sehr freuen. Zur Zeit kämpfe ich mich durch radvd durch. Ein radvdump -d4 auf einem Client zeigt mir auch an, dass die Konfiguration übertragen wird. Die IP und das Gateway werden auch in das Interface das Clients eingetragen. (ip -6 route show und ip -6 add show) Allerdings enthält die Defaultroute fe80:: also Scope:Link des Routers. Das kann doch so nicht richtig sein. Es müsste doch Scope:Global des Routers sein. Der Adressbereich fe80:: sollte ja nur local ansprechbar sein. Ich verdrehe mir schon seit einiger Zeit den Kopf und verstehe nicht was ich falsch gemacht haben soll. Daher hoffe ich ein geschultes Auge wirft kurz einen Blick darauf und findet schnell den Fehler. Gruß und Danke Andreas PS. Über die Liste ging mal eine Info bezüglich Freiland und Freifunk. Gibt es da Neuigkeiten? Falls es in Angriff genommen wird, würde ich Euch gerne dabei helfen.
On 09/07/11 11:38, Andreas Frey wrote:
Allerdings enthält die Defaultroute fe80:: also Scope:Link des Routers. Das kann doch so nicht richtig sein. Es müsste doch Scope:Global des Routers sein. Der Adressbereich fe80:: sollte ja nur local ansprechbar sein.
Es ist normal dass die Router fe80::-Adressen announcen, in einigen Fällen (z.Bsp. mit mehreren globale Präfixen on-link) ist das von Vorteil. Wichtig ist ja nur dass alle Hosts im Subnet den Router erreichen und dass der dann weiß wohin mit den Daten (meist nur zum nächsten default-Router am anderen Interface). Oder führt es bei dir dazu das irgendwas nicht funktioniert? In dem Fall ist die Routing-Tabelle des Routers die wahrscheinlichere Fehlerquelle (z.Bsp. wenn sich Tunnel nicht automatisch oder nicht richtig eingetragen werden). -- Martin
Am Mittwoch, 7. September 2011, 12:20:52 schrieb Martin Schütte:
Oder führt es bei dir dazu das irgendwas nicht funktioniert? In dem Fall ist die Routing-Tabelle des Routers die wahrscheinlichere Fehlerquelle (z.Bsp. wenn sich Tunnel nicht automatisch oder nicht richtig eingetragen werden).
Die Route am Client # ip -6 route show 2001:4dd0:XXXX::/64 dev wlan0 proto kernel metric 256 expires 86344sec mtu 1500 advmss 1440 hoplimit 0 fe80::/64 dev wlan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 default via fe80::e2cb:4eff:feed:1960 dev wlan0 proto kernel metric 1024 mtu 1500 advmss 1440 hoplimit 64 Ein Ping auf das Gateway # ping6 fe80::e2cb:4eff:feed:1960 connect: Invalid argument Ein Ping auf die IP des Routers # ping6 -c 2 2001:4dd0:XXXX::1 PING 2001:4dd0:XXXX::1(2001:4dd0:fed5::1) 56 data bytes 64 bytes from 2001:4dd0:XXXX::1: icmp_seq=1 ttl=64 time=2.21 ms 64 bytes from 2001:4dd0:XXXX::1: icmp_seq=2 ttl=64 time=4.32 ms Jetzt dachte ich der Client müsste eine Route mit default 2001:4dd0:XXXX::1 bekommen. Welche aber leider nicht automatisch über radvd eingetragen wird. Hier noch der passende radvdump # radvdump -d 4 [Sep 07 13:53:52] radvdump: recvmsg len=80 [Sep 07 13:53:52] radvdump: receiver if_index: 3 # # radvd configuration generated by radvdump 1.3 # based on Router Advertisement from fe80::e2cb:4eff:feed:1960 # received by interface wlan0 # interface wlan0 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag off; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 180; AdvHomeAgentFlag on; AdvDefaultPreference medium; AdvSourceLLAddress on; prefix 2001:4dd0:XXXX::/64 { AdvValidLifetime 86400; AdvPreferredLifetime 14400; AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; # End of prefix definition }; # End of interface definition So jetzt noch die Routen auf dem Router root@OpenWrt:~# ip -6 route show 2001:4dd0:XXXX::/64 dev br-lan metric 256 mtu 1500 advmss 1440 2001:4dd0:ff00:YYYY::/64 dev sixxs metric 256 mtu 1280 advmss 1220 fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440 fe80::/64 dev eth0.0 metric 256 mtu 1500 advmss 1440 fe80::/64 dev eth0.1 metric 256 mtu 1500 advmss 1440 fe80::/64 dev br-lan metric 256 mtu 1500 advmss 1440 fe80::/64 dev wl0 metric 256 mtu 1500 advmss 1440 fe80::/64 dev sixxs metric 256 mtu 1280 advmss 1220 ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 ff00::/8 dev eth0.0 metric 256 mtu 1500 advmss 1440 ff00::/8 dev eth0.1 metric 256 mtu 1500 advmss 1440 ff00::/8 dev br-lan metric 256 mtu 1500 advmss 1440 ff00::/8 dev wl0 metric 256 mtu 1500 advmss 1440 ff00::/8 dev sixxs metric 256 mtu 1280 advmss 1220 default via 2001:4dd0:ff00:YYYY::1 dev sixxs metric 1024 mtu 1280 advmss 1220 Also ich finde das eigentlich alles so okay.
On 09/07/11 14:02, Andreas Frey wrote:
Ein Ping auf das Gateway
# ping6 fe80::e2cb:4eff:feed:1960 connect: Invalid argument
Probier's mal mit # ping6 fe80::e2cb:4eff:feed:1960%wlan0 Die fe80:: ist nur link-local eindeutig, d.h. in einem Subnetz. Wenn nun an eth0 und wlan0 IPv6-Subnetze hängen, dann könnte über jedes der Interfaces könnte eine verschiedener Rechner mit IP fe80::e2cb:4eff:feed:1960 erreichbar sein. Das gleiche Prinzip greift z.Bsp. bei den link-local Multicast-Gruppen. Die Gruppe ff01::1 (alle Hosts) gibt es auch nicht abstrakt, sondern nur konkret per Subnet bzw. vom Host aus gesehen per Interface: ff02::1%eth0 und ff01::1%wlan0 Aber auch da ist das Router pingen ja nicht letztes Ziel... Funktioniert z.Bsp. ein "ping6 uplug.de"? Falls ja, dann wird richtig geroutet. -- Martin
Am Mittwoch, 7. September 2011, 14:21:55 schrieb Martin Schütte:
Probier's mal mit # ping6 fe80::e2cb:4eff:feed:1960%wlan0
Es klappt. IPv6 ist echt ein komische Protokoll. Da gibt es nun so viele IPs, und trotzdem wird eine lokale IP benutzt. Das ist doch echt komisch.
Die fe80:: ist nur link-local eindeutig, d.h. in einem Subnetz. Wenn nun an eth0 und wlan0 IPv6-Subnetze hängen, dann könnte über jedes der Interfaces könnte eine verschiedener Rechner mit IP fe80::e2cb:4eff:feed:1960 erreichbar sein. Das gleiche Prinzip greift z.Bsp. bei den link-local Multicast-Gruppen. Die Gruppe ff01::1 (alle Hosts) gibt es auch nicht abstrakt, sondern nur konkret per Subnet bzw. vom Host aus gesehen per Interface: ff02::1%eth0 und ff01::1%wlan0
Vielen Dank für die Erklärung.
Aber auch da ist das Router pingen ja nicht letztes Ziel... Funktioniert z.Bsp. ein "ping6 uplug.de"? Falls ja, dann wird richtig geroutet.
Das klappt auch. Also kann ich mich jetzt an den nächsten Schritt machen und ip6tables einrichten. Zur Zeit stoppe ich die Firewall, dann geht IPv6 aber nicht IPv4 (wegen NAT) oder umgekehrt. :-) Das ist echt störend beim surfen. Da merke mal wie viele Seiten schon IPv6-DNS-Einträge haben.
Am Mittwoch, 7. September 2011, 15:36:03 schrieb Andreas Frey:
Also kann ich mich jetzt an den nächsten Schritt machen und ip6tables einrichten.
Ein Frage hätte ich allerdings jetzt schon dazu. Ich nutze hier einen Asus WL-500g Premium mit Backfire 10.03. Allerdings musste ich die brcm-2.4-Version nehmen, da sonst die WLAN-Karte nicht unterstützt wird. Also läuft nun ein 2.4 Kernel, welcher wohl nicht iptables mit Verbindungs- Tracking besitzt. Alles Kommentare die ich zu diesem Thema bisher gefunden habe, raten aus diesem Grunde von IPv6 ab. Die Firewall ist wohl nicht vernünftig abzusichern. Wie schätzt Ihr das ein? Gibt es doch eine Möglichkeit oder sollte ich mich nach einer Alternative umschauen? Gruß Andreas
participants (2)
-
Andreas Frey -
Martin Schütte