Hallo,
...da will man sich (nach Jahren) mal wieder mit IPv6 beschäftigen und Debian benimmt sich schizophren! Hat irgendwer eine Idee, was ich machen muss?
Module ipv6 und die ip6tables-Module sind geladen.
Kernel ist 2.6.8-12-amd64-k8-smp - man sollte meinen, dass 2.6 kein Problem mit IPv6 hat.
ping6 kommt aus iputils-ping 3:20020927-3.1; telnet ist Version 0.17-29.
lo hat ::1/128 ; eth1 hat fe80::2e0:81ff:fe2e:b6d1/64 und fe80::5/128 (fe80::5 habe ich per Hand hinzugefügt, um mal zu schauen woran es liegt)
Firewall(*) ist komplett offen (alle Queues auf ACCEPT).
(*)Keine Angst, der Rechner steht hinter einem Gateway, der noch eine FW hat. Und sie ist auch nur für die Dauer der Tests offen.
Jetzt zum seltsamen Teil:
telnet ::1 80 -> geht (liefert Seiten vom Apachen aus) telnet :: 80 -> geht auch (laut netstat lande ich auf ::1) telnet fe80::5 80 -> geht nicht! (laut strace steigt connect(2) aus) telnet fe80::2e0:81ff:fe2e:b6d1 80 -> dito. telnet ::127.0.0.1 80 -> Network unreachable (eigentlich sollte der Kernel ja auf IPv4 umschalten)
bash$ ping6 ::1 can't receive hop limit: Protocol not available
laut strace ist es diese Zeile: setsockopt(3, SOL_IPV6, 0x33 /* IPV6_??? */, [8589934593], 4) = -1 ENOPROTOOPT (Protocol not available)
bash$ ping6 fe80::2e0:81ff:fe2e:b6d1 connect: Invalid argument
laut strace wieder connect(2)
Konrad
Hallo Konrad
Am Montag, den 25.12.2006, 18:41 +0100 schrieb Konrad Rosenbaum:
...da will man sich (nach Jahren) mal wieder mit IPv6 beschäftigen und Debian benimmt sich schizophren! Hat irgendwer eine Idee, was ich machen muss?
Sieh doch mal ob das Interface sit0 auch wirklich aktiv ist. Ansonsten fahr es mal testweise mit ifconfig hoch. Dann sollte es an sich funktionieren.
mfg Carsten Luedtke
On Monday 25 December 2006 20:16, Carsten Luedtke wrote:
Sieh doch mal ob das Interface sit0 auch wirklich aktiv ist. Ansonsten fahr es mal testweise mit ifconfig hoch. Dann sollte es an sich funktionieren.
Ok, das ist also der IPv4-Emulator. Telnet auf Port 80 geht darüber, aber ping geht noch nicht:
bash$ ping6 ::1 can't receive hop limit: Protocol not available bash$ ping6 ::127.0.0.1 can't receive hop limit: Protocol not available
Ist irgendwas bekannt, dass das Ping-Paket kaputt wäre?
Konrad
On Tuesday 26 December 2006 17:54, Konrad Rosenbaum wrote:
Ist irgendwas bekannt, dass das Ping-Paket kaputt wäre?
Um mir mal selbst zu antworten: ja, das Ping-Paket war kaputt. Spezifisch:
iputils-ping Version 3:20020927-3.1 (testing/unstable) ist kaputt, Version 3:20020927-2 (stable) ist in Ordnung. Jetzt bekommt er zumindest Pings auf einigen Adressen hin.
Im Moment ergibt das ein interessantes Bild:
*Pings und TCP via sit0 gehen *Pings und TCP auf ::1 gehen *Pings und TCP auf global scope Adressen gehen (z.B. alles in fc00::/7) *Pings und TCP auf link scope Adressen gehen NICHT (fe80::/64)
...und noch ein Interessantes Phänomen: Router Advertisements werden von meinem Laptop angenommen, aber nicht vom Desktoprechner - obwohl sie beide auf dem selben Ethernet-Link mit offenen Firewalls sind. Beide mit Kernel 2.6.8 (der Desktop 2.6.8-12 für AMD64; der Laptop 2.6.8-2 für x86).
Wie kann ich einen Rechner zwingen nach seinem Router zu fragen? Probiert habe ich: dhclient, /etc/init.d/ifupdown restart, .../network restart, tonnenweise ifdown/ifup
Konrad
Hi,
Probleme sind gelöst. Für die Neugierigen: s.u.
On Tuesday 26 December 2006 19:35, Konrad Rosenbaum wrote:
On Tuesday 26 December 2006 17:54, Konrad Rosenbaum wrote: *Pings und TCP auf link scope Adressen gehen NICHT (fe80::/64)
Mein Fehler: wenn man eine Link-Local-Adresse (man beachte den Namen!!) nutzt, dann muss man dem Kernel auch sagen, welcher Link (also welches Netzwerkdevice) gemeint ist. Bei ping geht das mit -I, bei ssh und telnet habe ich keine passenden Optionen gefunden (-b will eine IP und von einer global scope auf eine Link-Local Adresse verbinden wird nix).
Man muss also damit leben, dass Link-Local nur für Low-Level-Protokolle geht.
...und noch ein Interessantes Phänomen: Router Advertisements werden von meinem Laptop angenommen, aber nicht vom Desktoprechner - obwohl sie beide auf dem selben Ethernet-Link mit offenen Firewalls sind. Beide mit Kernel 2.6.8 (der Desktop 2.6.8-12 für AMD64; der Laptop 2.6.8-2 für x86).
Der Fehler war subtil aber vernichtend: wenn auf einem Interface IP-Forwarding (/proc/sys/net/ipv6/conf/*/forwarding) eingeschaltet ist, dann nimmt Linux natürlich an, dass es ein Router ist und läßt sich von einem anderen Router nicht "dumm anquatschen". Sobald man diese Option auf "0" setzt, sendet Linux brav ein "Router Solicitation" Paket und läßt sich erzählen in welchem Netz es ist...
...vorrausgesetzt diverse andere Optionen sind nicht inzwischen ausgeschaltet...
Kurz: alle Probleme gelöst und ich muss nur noch 3,5 MB RFCs lesen, damit ich IPv6 endgültig verstehe...
Konrad
Am Dienstag, 26. Dezember 2006 21:01 schrieb Konrad Rosenbaum:
Kurz: alle Probleme gelöst und ich muss nur noch 3,5 MB RFCs lesen, damit ich IPv6 endgültig verstehe...
Dazu kommen dann noch diverse ausgerissene Haare, wenn man sich an die Implementierung setzt und außer der libc keine Werkzeuge hat. Zwei oft gesehene Stolperstellen: - die Verwendung von "struct sockaddr" (Millionen von manpages können nicht irren...) - Namensauflösung, siehe auch http://www.kuarepoti-dju.net/index.php?p=83
Josef, der über die Feiertage auch immer die tollsten Fehler findet
lug-dd@mailman.schlittermann.de
-
Carsten Luedtke -
Josef Spillner -
Konrad Rosenbaum