Fehler bei tracroute6 und ip tunnel

[genlog]

[edit olistudent]: Beiträge in eigenes Thema ausgelagert

Hallo Oliver,

Also ich habe einfach mit freetz losgelegt. Wie auch empfohlen. Minimalimage...
Dann habe ich IPv6 hinzugefügt und kam ziemlich schnell an die Stelle, dass radvd nicht läuft.
Gleiche Probleme wie in Track http://trac.freetz.org/ticket/348#
Kurzes Fazit:
Mit eigener Toolchain geht es dann.

Bis zu dem Zeitpunkt habe ich mit 6266 gearbeitet. Aber durch neue Ordner und neue Versuche erhöhte sich am Wochenende sich die Versionsnummer. (Das habe ich zuerst gar nicht bemerkt.) Dementsprechend bin ich eine böse Falle gelaufen.

Ab 6266M funktioniert anscheinend ipv6 gar nicht mehr richtig auf dem W900.
Es kann kein Tunnelinterface aufgebaut werden. module ipv6 wird aber geladen und via lsmod angezeigt. Fehlermeldungen:

traceroute6 www.heise.de
root@fritz:/var/mod/root#traceroute6: can't load library 'libresolv.so.0'

root@fritz:/var/mod/root# ip tunnel add he-ipv6 mode sit remote 216.66.80.30 loc
al 192.168.1.2 ttl 255
BusyBox v1.17.4 (2010-12-03 12:40:28 CET) multi-call binary.

Usage: ip [OPTIONS] {address | } {COMMAND}

ip [OPTIONS] OBJECT {COMMAND}
where OBJECT := {address | }
OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] }

 

[olistudent]

Ich lagere die Diskussion dann in einen neuen Thread aus...

Ist traceroute6 ein busybox Befehl oder aus dem iputils Paket? Hast du eine Ahnung warum die libresolv.so nicht da ist? Momentan wüsste ich nicht warum das mit dem SVN Stand < 6266 zusammenhängen soll.

Gruß
Oliver

 

[genlog]

Ja Perfekt, das sollte man trennen.

Traceroute stand dort noch unter unstable. Ist aber aktuell wie auch Ping6 unter iputils zu finden. Was mit der libresolv.so los ist, weiß ich nicht mehr. Ich werde die Tage nochmal ein aktuelles image erstellen.

Problematischer fand ich allerdings, dass ich beim Konfigurieren des Tunnels jedes mal die Fehlermeldungen bekam, als ich die IPv6 Adressen zuweisen wollte.

root@fritz:/var/mod/root# ip tunnel add he-ipv6 mode sit remote 216.66.80.30 loc
al 192.168.1.2 ttl 255
BusyBox v1.17.4 (2010-12-03 12:40:28 CET) multi-call binary.

Usage: ip [OPTIONS] {address | } {COMMAND}

ip [OPTIONS] OBJECT {COMMAND}
where OBJECT := {address | }
OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] }

Selbst manuelles "-f inet6" bringt die gleiche Meldung.

 

[olistudent]

Im iputils Paket ist ein Fehler. Da wird unnötigerweise gegen die libresolv gelinkt.

Warum der ip tunnel Befehl nicht funktioniert kann ich nicht sagen. Ist die Reihenfolge der Optionen relevant? Die Fundstellen bei google hatten das ttl 255 weiter vorne.

Was das ganze mit den aktuellen SVN Ständen zu tun haben soll ist mir immer noch schleierhaft.

Gruß
Oliver

 

[genlog]

Die Reihenfolge ist meines Wissens nicht relevant.
--> wird aber getestet.

Folgende Beispiele bietet HE an:
route2:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.80.30 local 192.168.1.2 ttl 255
ip link set he-ipv6 up
ip addr add 2001:430:1f4a:13a2::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

oder aber mittels net-tools:

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.80.30
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:430:1f0f:1232::2/64
route -A inet6 add ::/0 dev sit1

Bei beiden Versionen meckert die Box (>6266).

Der "normale" Ping funktioniert bei 6266 auch mit dem Schalter -6:

root@fritz:/var/mod/root# ping -6 heise.de
PING heise.de (2a02:2e0:3fe:100::8): 56 data bytes
64 bytes from 2a02:2e0:3fe:100::8: seq=0 ttl=60 time=27.418 ms
64 bytes from 2a02:2e0:3fe:100::8: seq=1 ttl=60 time=25.129 ms

Bei >6266 kam hier "Bad Address"


Edith sagt:
traceroute Fehler mit den iputils kann ich nachvollziehen und ist auch in der 6266 enthalten:

root@fritz:/var/mod/root# traceroute heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 38 byte packets

root@fritz:/var/mod/root# traceroute6 heise.de
traceroute6: can't load library 'libresolv.so.0'

Also hat das grundsätzlich nichts mit der IPv6 Funktionalität zu tun.

Im Moment habe ich noch das funktionierende Image drauf.
Ich werde morgen ein neues (aktuelle rev) Image erzeugen und anschließend aufspielen. Leider dauert das erstellen mit eigener Toolchain rund 2,5h auf meinem Notebook.

Wenn du noch wissenswerte Debugbefehle für mich weisst, dann her damit.
Ich werde mit beiden Versionen alles protokollieren.

Viele Grüße
Stephan

 

[olistudent]

http://trac.freetz.org/changeset/6305

Der traceroute6 Fehler sollte damit behoben sein.

Gruß
Oliver

 

[meiser79]

Hi,

lass mal das "local 192.168.1.2" beim "ip tunnel"-Befehl weg.

Hier klappt es folgendermaßen (mit busybox's ip):

ip tunnel add he-ipv6 mode sit remote 216.66.80.30 ttl 255
ip link set he-ipv6 up
ip -6 addr add 2001:xxxx:xxxx:xxxx::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

Beste Grüße,
Whoopie

 

[genlog]

Hallo Oliver und Whoopie,

mit der Revision 6307 funktioniert traceroute6 nun ohne Probleme.
Ebenso wird der Tunnel aufgebaut, ohne dass ich die Config geändert habe.


Edith sagt:
Alles klappt mit Revision 6307!
Fragt mich nicht, wie die Probleme mit 6266M - 6295 entstanden sind...


Gibt es eine Möglichkeit die schonmal erstellte Toolchain weiter zu nutzen?
Das dauert sonst jedes mal 2,5h?

Howto ist überarbeitet!
Thread kann ggf. als gelöst markiert werden.

Viele Grüße
Stephan

 

[ploieel]

Onlinechanged richtig eingestellt?

Hallo,
danke für das HowTo. Ein kleines Problem habe ich dazu:

In dieser Zeile kommen eckige Klammern vor:

wget -O - "http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=AUTO&pass=[PASSWORD]8&user_id=[USER]&tunnel_id=[TUNNNEL]" > /dev/null 2>&1

Müssen diese Klammern vor und hinter den Zahlenreihen für Passwort und User und Tunnel-ID stehen oder doch nicht?

Und bei [PASSWORD]8&user_id... was ist mit der "8"? Ein Tippfehler?

Ich habe schon einiges probiert, kriege aber keine IPv6-Verbindung hin. Deshalb wäre es schön, wenn meine Unsicherheiten bezüglich der oben genannten Probleme ausgeräumt werden könnten. Dann könnte ich an anderer Stelle nach meinen Fehlern suchen.

Danke und schöne Grüße.

 

[olistudent]

Kennst du google? -> lmgtfy

 

[ploieel]

Danke für den Such-String, habe einen Teil der meiner Fehler finden können.

Habe von http://... auf https://... geändert, die eckigen Klammern und die "8" weggelassen, und habe die Einträge doppelt geprüft (Tunnel-ID, Hashwert des Passwortes und die User-ID), alles korrekt. Ebenso die Einträge bei rc.custom doppelt gecheckt, keine Abweichungen.

Ich stelle fest, dass der Windows-Client bei ipv4 ganz erheblich langsamer geworden ist, so ist z. B. das Forum hier sehr schlecht erreichbar für mich.

radvd steht auf "running", ein ping -6 www.heise.de bringt auf dem Client "Zielnetz nicht erreichbar".

Woran kanns liegen? Teredo ist per netsh-Befehl gestoppt, go6 ist auf dem Client deinstalliert; kurz, ich weiß im Moment nicht mehr weiter.

/var/log/mod.log zeigt, dass es /proc/sys/net/ipv6/conf/all/forwarding anlegen will, schreibt dann aber: nonexistent directory.
Und weiter:
radvd: can´t create socket (AF_INET6): Address family not supported by protocol
open_icmpv6_socket: Bad file descriptor