Hallo,
Benedikt Stockebrand <[EMAIL PROTECTED]> writes:
> Sebastian Niehaus <[EMAIL PROTECTED]> writes:
>
>>>> Offenbar stelle ich mich zu blöd an, IPv6 über PPP zu betreiben. Titan
>>>> Networks stellt mir einen IPv6-only Zugang bereit (deshalb ist die
>>>> pppd-Option "noip" gesetzt)
>
> Als erstes setze mal "noccp"
Okay, das habe ich mal gemacht.
> Weisst Du, was auf der Gegenseite für eine PPP-Implementierung
> läuft?
Aus einer Nebenbemerkung des Titan-Suportes schließe ich, daß es sich
um ein Cisco-Router handelt.
Ich kann ja nocheinmal nachfragen.
Ob die Tatsache, daß ich kein IPv4 habe die Konfiguration
irgendwie[TM] stört?
> Als zweites ist ein "ping -I ppp0 ff02::1" extrem hilfreich, um zu
> sehen, ob da überhaupt irgendwas über die Leitung geht.
,----
| [EMAIL PROTECTED]:/home/niehaus# ping6 -c 2 -I ppp0 ff02::1
| PING ff02::1(ff02::1) from fe80::11b5:f187:16d1:bccd ppp0: 56 data bytes
| 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.452 ms
| 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.293 ms
|
| --- ff02::1 ping statistics ---
| 2 packets transmitted, 2 received, 0% packet loss, time 1000ms
| rtt min/avg/max/mdev = 0.293/0.372/0.452/0.081 ms
| [EMAIL PROTECTED]:/home/niehaus#
`----
Tut also.
> Wenn das geht, versuch als nächstes ein Ping auf ff02::2, um zu sehen,
> ob die Gegenseite als Router ansprechbar ist.
,----
| [EMAIL PROTECTED]:/home/niehaus# ping6 -c 2 -I ppp0 ff02::2
| PING ff02::2(ff02::2) from fe80::11b5:f187:16d1:bccd ppp0: 56 data bytes
|
| --- ff02::2 ping statistics ---
| 2 packets transmitted, 0 received, 100% packet loss, time 1000ms
|
| [EMAIL PROTECTED]:/home/niehaus#
`----
Tut nicht.
>> | cat /etc/ppp/peers/dsl-titan
>> | ------------------ cut -----------------
>> | [...]
>> |
>> | persist
>
> Das hat in meiner Testumgebung (VMware mit "virtuellen Nullmodems")
> nicht funktioniert.
Das scheint hier kein Problem zu sein, die Verbindung ist nach dem
zwangsweisen Disconect wirder hochgekommen.
> Nach der ersten Verbindung wird ein Fehler von
> tcsetattr geloggt. Deshalb die Frage: Läuft der pppd noch?
Ja.
Bei dem Stöbern in den Logdateien habe ich noch etwas entdeckt, dessen
Bedeutung ich in meiner verfahrenen Situation nicht gescheit einordnen
kann:
,----
| Apr 1 04:11:21 radioactive -- MARK --
| Apr 1 04:31:21 radioactive -- MARK --
| Apr 1 04:43:01 radioactive kernel:
__ipv6_regen_rndid(idev=fffff80010ef0460): cannot get EUI64 identifier; use
random bytes.
Hm?
| Apr 1 04:54:01 radioactive pppd[8182]: No response to 3 echo-requests
| Apr 1 04:54:01 radioactive pppd[8182]: Serial link appears to be
disconnected.
| Apr 1 04:54:01 radioactive kernel: ioctl32(pppd:8182): Unknown cmd fd(6)
cmd(00008936){00} arg(efffefe8) on socket:[542615]
| Apr 1 04:54:02 radioactive kernel: device ppp0 left promiscuous mode
Das hängt wohl damit zusammen, daß "tcpdump" mitlief.
| Apr 1 04:54:08 radioactive pppd[8182]: Connection terminated.
| Apr 1 04:54:08 radioactive pppd[8182]: Connect time 1441.5 minutes.
| Apr 1 04:54:08 radioactive pppd[8182]: Sent 380851 bytes, received 44 bytes.
| Apr 1 04:54:08 radioactive pppd[8182]: tcflush failed: Input/output error
| Apr 1 04:54:08 radioactive pppd[8182]: Modem hangup
| Apr 1 04:54:12 radioactive pppd[8182]: Using interface ppp0
| Apr 1 04:54:12 radioactive pppd[8182]: Connect: ppp0 <--> /dev/pts/51
| Apr 1 04:54:14 radioactive pppd[8182]: CHAP authentication succeeded
| Apr 1 04:54:14 radioactive pppd[8182]: Unsupported protocol 'Internet
Protocol Control Protocol' (0x8021) received
Hm?
| Apr 1 04:54:14 radioactive pppd[8182]: local LL address
fe80::a9f4:2113:daa2:2870
| Apr 1 04:54:14 radioactive pppd[8182]: remote LL address
fe80::0203:e4ff:fe03:4000
| Apr 1 04:54:14 radioactive kernel:
__ipv6_regen_rndid(idev=fffff80010c17ba0): cannot get EUI64 identifier; use
random bytes.
Schon wieder? Was auch immer das bedeuten mag ...
| Apr 1 04:54:14 radioactive ppp-debug: ppp0
| Apr 1 04:54:14 radioactive ppp-debug: 38400
| Apr 1 04:54:14 radioactive ppp-debug: fe80::a9f4:2113:daa2:2870
| Apr 1 04:54:14 radioactive ppp-debug: fe80::0203:e4ff:fe03:4000
| Apr 1 05:11:22 radioactive -- MARK --
`----
[...]
> Die Sache ist im wesentlichen so: PPP baut nur die Verbindung und
> dazugehörige LL-Adressen auf. Wenn Du geroutete Adressen auf den
> Interfaces haben willst, musst Du die z.B. per /etc/ppp/ipv6-up selbst
> einrichten. Das ist aber eigentlich nicht nötig, wenn Du
> Interface-Routen benutzt, also z.B.
Okay.
[...]
> Dafür gibt es prinzipiell zwei Erklärungen: Entweder Du hast auf
> keinem Interface des Routers eine geroutete Adresse konfiguriert
> (sieht nicht so aus) oder Deine Kiste implementiert RFC 3484 (Source
> Address Selection) nicht richtig, was ich aber bei Linux noch nicht
> beobachtet habe. Ich hab's gerade mal nachgetestet, bei einem
> Standard-2.6.8er Kernel scheint es so ein Problem nicht zu geben.
>
> Noch etwas dabei: Vor zwei Wochen hatte ich in einer Schulung einen
> Gentoo-User sitzen, der mit dem 2.6.15er Kernel riesige Probleme
> hatte. Welche Kernelversion benutzt du?
,----
| [EMAIL PROTECTED]:/home/niehaus# uname -a
| Linux radioactive 2.6.8-2-sparc64 #1 Sat Aug 20 21:27:11 UTC 2005 sparc64
GNU/Linux
`----
>> [ifconfig/ip addr sieht gut aus]
>> Hat jemand noch Ideen?
> Was sagt "ip -6 route show"?
,----
| [EMAIL PROTECTED]:/home/niehaus# ip -6 route
| fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 64
| fe80::/64 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 64
| fe80::/64 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 64
| fe80::/10 dev ppp0 metric 1 mtu 1456 advmss 1396 hoplimit 64
| fe80::/10 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 64
| ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 1
| ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 1
| ff00::/8 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 1
| default dev ppp0 metric 1024 mtu 1456 advmss 1396 hoplimit 64
`----
Das ist, was die Route *jetzt* anzeigt.
Ich habe eben nocheinmal etwas "verbotenes" getan und den Rechner neu
gestartet, die PPP-Verbindung neu aufgebaut, danach folgendes
Ergebnis:
,----
| [EMAIL PROTECTED]:/home/niehaus# ip -6 route
| fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 64
| fe80::/64 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 64
| fe80::/64 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 64
| fe80::/10 dev ppp0 metric 1 mtu 1456 advmss 1396 hoplimit 64
| fe80::/10 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 64
| ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 1
| ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 1
| ff00::/8 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 1
| default dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 64
| default dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 64
| default dev ppp0 proto kernel metric 256 mtu 1456 advmss 1396 hoplimit 64
| default dev ppp0 metric 1024 mtu 1456 advmss 1396 hoplimit 64
| unreachable default dev lo proto none metric -1 error -51 hoplimit 255
`----
Ich habe gerade keine Idee, woher die anderen Default-Routen kommen,
ein radvd läuft hier nicht, nochmal gerade mit radvdump nachgeschaut ...
,----
| [EMAIL PROTECTED]:/home/niehaus# ping6 www.space.net
| PING www.space.net(www.Space.Net) 56 data bytes
|
| --- www.space.net ping statistics ---
| 2 packets transmitted, 0 received, 100% packet loss, time 1000ms
|
| [EMAIL PROTECTED]:/home/niehaus# ping6 -c 2 www.space.net
| PING www.space.net(www.Space.Net) 56 data bytes
| From ip6-localhost icmp_seq=1 Destination unreachable: Address unreachable
| From ip6-localhost icmp_seq=2 Destination unreachable: Address unreachable
|
| --- www.space.net ping statistics ---
| 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1000ms
| , pipe 2
| [EMAIL PROTECTED]:/home/niehaus#
`----
Das passiert dann bei einem ping6.
Wie gesagt, ich habe die Routen händisch wieder angepasst. Nun lauten
sie:
,----
| [EMAIL PROTECTED]:/home/niehaus# ip -6 route
| fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 64
| fe80::/64 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 64
| fe80::/64 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 64
| fe80::/10 dev ppp0 metric 1 mtu 1456 advmss 1396 hoplimit 64
| fe80::/10 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 64
| ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 hoplimit 1
| ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 hoplimit 1
| ff00::/8 dev ppp0 metric 256 mtu 1456 advmss 1396 hoplimit 1
| default dev ppp0 proto kernel metric 256 mtu 1456 advmss 1396 hoplimit 64
| default dev ppp0 metric 1024 mtu 1456 advmss 1396 hoplimit 64
| [EMAIL PROTECTED]:/home/niehaus# ping6 www.space.n
`----
Und nochmal die derzeitigen IPs:
,----
| [EMAIL PROTECTED]:/home/niehaus# ip -6 addr
| 1: lo: <LOOPBACK,UP> mtu 16436
| inet6 ::1/128 scope host
| valid_lft forever preferred_lft forever
| 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qlen 1000
| inet6 fe80::202:b3ff:fe24:7c0c/64 scope link
| valid_lft forever preferred_lft forever
| 4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qlen 1000
| inet6 fe80::a00:20ff:fea2:2ad3/64 scope link
| valid_lft forever preferred_lft forever
| 7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1456 qlen 3
| inet6 2001:4b88:1060::1/128 scope global
| valid_lft forever preferred_lft forever
| inet6 fe80::a827:5ce4:d14e:166/10 scope link
| valid_lft forever preferred_lft forever
| [EMAIL PROTECTED]:/home/niehaus#
`----
Nicht, daß das hier irgendwie lebenswichtig wäre für mich, aber ich
würde damit gerne spielen. Wenn jemand weitere Ideen hat, wie ich das
hier debuggen kann ....
Vielen Dank schonmal,
Sebastian
_______________________________________________
ipv6 mailing list
[email protected]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
