dnsmasq nur mit ipv4

[schmatke]

Mein ipv6 funktioniert noch nicht so richtig. Daher hab ich aber ein Problem mit dnsmasq.
Wenn dnsmasq als erstes eine ipv6 ausspuckt, kann ich den Server auch nicht erreichen.

/var/mod/root $ nslookup www.ipv6.org
Server:    192.168.180.1
Address 1: 192.168.180.1

Name:      www.ipv6.org
Address 1: 2001:6b0:1:ea:202:a5ff:fecd:13a6
Address 2: 130.237.234.40 igloo.stacken.kth.se
/var/mod/root $ ping  www.ipv6.org
PING www.ipv6.org (2001:6b0:1:ea:202:a5ff:fecd:13a6): 56 data bytes
ping: sendto: Network is unreachable
/var/mod/root $ ping  -4 -c1 www.ipv6.org
PING www.ipv6.org (130.237.234.40): 56 data bytes
64 bytes from 130.237.234.40: seq=0 ttl=52 time=82.6 ms

--- www.ipv6.org ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 82.6/82.6/82.6 ms
/var/mod/root $

Gibt es ne Möglichkeit, dnsmasq anzuweisen nur ipv4 abzufragen? :gruebel:

 

[RalfFriedl]

Gibt es ne Möglichkeit, dnsmasq anzuweisen nur ipv4 abzufragen?

IPV6 deaktivieren?

Die Frage ist falsch gestellt. Es ist normal, daß Programme, die IPV6 unterstützen, zuerst nach IPV6 Adressen suchen. Und wenn eine Antwort kommt, wird diese auch verwendet.
dnsmasq stellt nicht von sich aus Anfragen an andere Nameserver, er macht das nur, um Anfragen, die er selbst bekommen hat, zu beantworten.
Wenn man also will, daß dnsmasq nur ipv4 Adressen abfragt, darf man ihn auch nur nach ipv4 Adressen fragen.

Die richtige Frage lautet in diesem Fall also "Wie kann ich ping dazu bringen, nur ipv4 abzufragen?" Und für das Programm ping hast Du auch schon die Antwort in Form der Option -4 gefunden. Bei anderen Programmen kann das anders sein, aber es hat nicht mit dnsmasq zu tun.

 

[olistudent]

Funktioniert dnsmasq eigentlich mit ipv6? Ich hab gestern in den Patches gesehen, dass da defines auskommentiert werden.

MfG Oliver

 

[RalfFriedl]

Anscheinend bringt dnsmasq ja IPV6 Antworten, die Frage war ja, wie man ihm das abgewöhnt.

Der eingebaute multid bringt mir jedenfalls auch passende Antworten, auch ohne daß ich ipv6 geladen habe.

Vielleicht sollte man auch zwei Punkte unterscheiden:
1. Anfragen an IPV6 DNS-Server. Diese brauchen IPV6 Unterstützung. Wenn diese nicht vorhanden ist, kann man keine Antwort von denen bekommen.
2. Abfrage von IPV6 Adressen. Hier handelt es sich nur um einen konkreten Datentyp (AAAA), den man auch von einem System ohne IPV6 Unterstützung abfragen kann.

 

[masterSLZ]

*denk*

Ich verstehe das Problem gerade nicht - was geht denn bitte genau nicht?
Das ist doch nur Fritzbox-intern relevant. Also geht irgendeine Anwendung auf der Fritzbox nicht oder was?

IPv6 Address-Antworten krigst Du wie schon beschrieben ja immer zurueck wenn vorhanden beim abgefragten Namen, unabhaengig davon ob Du die Resolver mit IPv4 oder IPv6 ansprichst.
Das jeweilige OS entscheidet, ob er A oder AAAA benutzt, das hat mit dem DNS Server/Resolver ueberhauptreingarnichts zu tun. Der kann daran nichts aendern.

bye
-slz

 

[schmatke]

*denk*
Ich verstehe das Problem gerade nicht - was geht denn bitte genau nicht?
Das ist doch nur Fritzbox-intern relevant. Also geht irgendeine Anwendung auf der Fritzbox nicht oder was?
-slz

Genau! Und zwar der LCR. Da bekomm ich ebenfalls ne ipv6. Beim ping kann ich das (-4) unterbinden. Dann gehts aber mit wget weiter. Harald's Script is ellenlang. Das wird dann wohl nix.
Da werd ich wohl ipv6 wieder rausnehmen müssen. :-(

 

[masterSLZ]

Gut, eine Haelfte verstehe ich, welche Anwendung nicht geht, irgendein Least Coast Router Kram oder so.
Was ich immernoch nicht verstehe, warum sie nicht gehen sollte, da fehlen mir weiter die Informationen, weil ich die Software nicht kenne.

Auf welche DNS Eintraege will "LCR" denn zugreifen die auch IPv6 Adressen / AAAA RRs haben?
Wieso benutzt die Anwendung Hosts mit IPv6 Adressen / AAAA Records wenn sie selbst eventuell kein IPv6 versteht?
Wieso macht die Anwendung kein Fallback auf IPv4 wenn IPv6 nicht funktioniert wie alle anderen auch?
Warum ueberhaupt IPv6 anschalten wenn man eh keine Connectivity hat?

So ganz erschliesst sich das mir immer noch nicht.

Normalerweise macht jede Anwendung halt ein Fallback, einfachste Demonstaration von einem IPv6-enabled Linux ohne IPv6 Anbindung (nicht mit einer busybox demonstrierbar da dort telnet keine vernuenftige Ausgabe macht aus Platzgruenden):

ns1:/etc/named.d # telnet mail.foo.bar smtp
Trying 2001:1578:100::xxx:x...
telnet: connect to address 2001:1578:100::xxx:x: No route to host
Trying 195.137.211.xx...
Connected to mail.foo.bar.
Escape character is '^]'.
220 mail.foo.bar ESMTP Postfix

Genau so muesste sich "LCR" auch verhalten, oder wenn es nur ein Script ist, die dort aufgerufenen Anwendungen bzw. Libs.
Wenn "LCR" oder letzere nicht richtig programmiert sind, muss man bei den jeweiligen Programmieren halt einen Bugreport einkippen.
Normalerweise ist IPv6 programmierung kein Voodo Magic - das machen die Libraries eigentlich automatisch wenn man die richtigen Aufrufe verwendet.
Kann natuerlich auch ein Problem der uClibc sein.
Leider sagt mir "LCR von Harald" persoenlich nichts und ich probiers sicher nicht aus, muesst ihr schon selbst suchen / Infos geben ;-)

Bottom Line: Da irgendwas an DNS/dnsmasq zu Schrauben ist jedenfalls der falsche Ansatz.

bye
-slz

 

[RalfFriedl]

Ich denke auch, daß es ein Anwendungsfehler ist.
Wobei
- IPV6 ohne IPV6-Anbindung bringt nicht viel.
- ucLibc ist darauf ausgelegt, daß sie wenig Platz braucht. Ansonsten würde man die große glibc nehme.
- Für die Programme der Busybox gilt das gleiche.
- Auch beim LCR stellt sich die Frage, macht man das Programm für alle größer, damit wenige mit IPV6 davon einen Vorteil haben

 

[masterSLZ]

Das ist bis auf letzteres schon richtig zusammengefasst.

- Auch beim LCR stellt sich die Frage, macht man das Programm für alle größer, damit wenige mit IPV6 davon einen Vorteil haben

...ist allerdings etwas komisch - wegen IPv6-support wird eigentlich nichts (an den Programmen) groesser, das macht das Programm ja normal nicht selbst, also den Netzwerklayer. Schon gar nicht wenn es sich wirklich nur um ein Script handeln sollte.

Allerdings muss das Programm/das Script hier ja SCHEINBAR einen Hostnamen aufzuloesen versuchen, der auch einen AAAA Record hat, sonst wuerde das Problem ja nicht auftreten (welches das genau ist, was nicht geht, weiss ich ja nicht).
Insofern kann man <glaskugel> irgendwie vermuten, das sich der Programmierer irgendwann mit IPv6 eventuell schon auseinandergesetzt haben muss, es ist heutzutage ja relativ unwahrscheinlich das man IPv6 auf einem Server/Host hat, ohne das expliuzit zu wollen ;-) </glaskugel>

Wenn es wirklich nur ein Script ist, ohne binaries, wird halt aller Wahrscheinlichkeit ein busybox Befehl aufgerufen (<glaskugel> ping?! </glaskugel>), der denn fehlschlaegt weil er IPv6 versucht.

[Exkurs:
"ping" waere eine Ausnahme, wo by design kein Fallback auf IPv4 gemacht werden wuerde weil man das nicht wuenscht.
Dann stellt sich die Frage, WIESO hier "ping" aufgerufen wird, in einen Script. Als Erreichbarkeits Test taugt ICMP echo nicht in der heutigen Realitaet mit Firewalls die ICMP meist als "ganz boese" filtern]

In dem Fall ist das ein (doppeltes) Design Problem des Programmierers, der aber einfach durch richtige Programmierung behoben werden kann.
-> "Harald"

Falls irgendein (anderes) Programm (der busybox) sich nicht richtig verhaelt, macht man aber eben einen Bugreport auf, damit es gefixt wird.
-> http://bugs.busybox.net/my_view_page.php - Da sind auch schon einige IPv6-related issues offen z.b.

bye
-slz

 

[schmatke]

Ich hänge mal den Teil der debug.cfg mit an, der für das Nachladen des LCR verantwortlich ist.
Wie gesagt, hängen bleibt die Sache beim ping. "Network is unreachable"

Einen Bugreport verneine ich definitiv! ;-) Schließlich bin das Hauptproblem ich, wenn ich mein ipv6 nicht vernünftig hinbekomme.
Dachte halt, dass könnte ich mit dnsmasq temporär lösen.
Falscher Denkansatz - habe ich begriffen!

Sowohl ipv6, als auch der LCR liegen bei mir in der Priorität eher bei niedrig.
ipv6 braucht man (noch) nicht und der LCR ist ohnehin nur ein Spielzeug (monatliche Telefonkosten: ca. 5 ¤). Werde halt (vorerst) auf eins von den beiden verzichten müssen. Wird wohl der LCR sein. ;-)

Danke für die vielen Antworten. Brauche halt manchmal nen Denkanstoss.
Davon gab's ja genug!

 

[RalfFriedl]

Das ping wird ja nur verwendet, um zu testen, ob die Internetverbindung schon da ist.
Wenn Du schon weißt, daß es am ping liegt, und auch weißt, daß "ping -4" funktioniert, dann kannst Du das ja mal ändern, vielleicht funktioniert es dann schon.

Das auszuprobieren geht ja schneller, als hier eine Frage zu formulieren.

 

[schmatke]

Wenn das geklappt hätte, hätte ich nicht gefragt!

 

[RalfFriedl]

Wie gesagt, hängen bleibt die Sache beim ping. "Network is unreachable"

Nachdem Du das geändert hast, bleibt es immer noch beim ping hängen, oder jetzt anderswo?

 

[schmatke]

Sorry, dachte das wäre klar.

Beim ping kann ich das (-4) unterbinden. Dann gehts aber mit wget weiter.

Ich denke, bei wget gehts dann gleich weiter. ps gibt leider nur den tsbinstaller aus. Von daher bin ich mir nich ganz sicher. Sieht aber so aus.

/var/mod/root $ ping -4 -c 1 lcr.telefonsparbuch.de PING lcr.telefonsparbuch.de (88.198.37.146): 56 data bytes
64 bytes from 88.198.37.146: seq=0 ttl=57 time=59.1 ms

--- lcr.telefonsparbuch.de ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 59.1/59.1/59.1 ms
/var/mod/root $ wget -qO "var/tmp/htmltsb.tar" "http://lcr.telefonsparbuch.de/binarypackage_1_48_07.tar" 2>&1
wget: cannot connect to remote host: Network is unreachable
/var/mod/root $

 

[RalfFriedl]

Ich hatte nicht soweit zurück geschaut.

Dann geht IPV6 wohl nur dann, wenn man auch tatsächlich IPV6 Verbindung nach draußen hat, oder mit größeren Änderungen an den Programmen.

 

[olistudent]

Ich konnte im Source von wget nichts bezüglich ipv6 finden. Ist das jetzt ein Problem der busybox, uclibc oder wer ist Schuld?

MfG Oliver

 

[RalfFriedl]

Die Ursache ist, daß wget (über libbb/xconnect.c:xconnect_stream() ) versucht, zur ersten gefundenen Adresse eine Verbindung aufzubauen. Wenn diese Adresse nicht ansprechbar ist, wird nicht versucht, eine andere zu nehmen.

Wenn die erste gefundene Adresse eine IPV6 Adresse ist, wird eine Verbindung zu dieser Adresse versucht. Wenn das nicht geht, dann geht es nicht.

Das Problem ließe sich lösen, indem wget und evtl. andere Programme der busybox geändert werden, so daß sie alle Adressen durchprobieren.

Im Prinzip ist so ein Verhalten sinnvoll und wird vermutlich von den Großen Programmen auch so gemacht.

Die Frage ist, ob diese Erweiterung für die Programme in der Busybox sinnvoll ist, wo der Platz ja doch etwas eng ist.

 

[danisahne]

Siehe Mischbetrieb: http://linuxwiki.de/IPv6

Ich würde auf keinen Fall an den Programmen patchen, da die Liste der Probleme endlos wird. Wer keine IPv6 Anbindung hat sollte IPv6 auch nicht aktivieren. Ich sehe auch keinen Vorteil darin.

Mfg
danisahne

 

[schmatke]

Wer keine IPv6 Anbindung hat sollte IPv6 auch nicht aktivieren.

Okay, ist klar. Möchte aber doch ipv6 kennenlernen.

Im LAN funktionierts jetzt auch.
Was mir momentan nicht ganz klar ist, ist die DNS-Abfrage.

Von einem beliebigen PC:

lindose1:~ # nslookup www.ipv6.org
Server:         192.168.178.1
Address:        192.168.178.1#53

Non-authoritative answer:
www.ipv6.org    canonical name = shake.stacken.kth.se.
Name:   shake.stacken.kth.se
Address: 130.237.234.40

lindose1:~ #

Von der Fritzbox:

/var/mod/home/samba/sda1 $ nslookup www.ipv6.org
Server:    192.168.180.1
Address 1: 192.168.180.1

Name:      www.ipv6.org
Address 1: 2001:6b0:1:ea:202:a5ff:fecd:13a6
Address 2: 130.237.234.40 igloo.stacken.kth.se
/var/mod/home/samba/sda1 $

Wieso 192.168.180.1? Hätte lieber 192.168.178.1#53

Edit:

/var/mod/home/samba/sda1 $ nslookup www.ipv6.org 192.168.178.1
Server:    192.168.178.1
Address 1: 192.168.178.1 fritz.box

Name:      www.ipv6.org
Address 1: 2001:6b0:1:ea:202:a5ff:fecd:13a6
Address 2: 130.237.234.40 igloo.stacken.kth.se
/var/mod/home/samba/sda1

 

[RalfFriedl]

Der PC sagt Dir, daß www.ipv6.org ein Alias (cname, canonical name) für shake.stacken.kth.se ist.
Wenn Du mehr wissen willst, mußt Du mit nslookup shake.stacken.kth.se nachsehen.
Das nslookup der Box folgt dem Verweis und bringt automatisch die Antwort für shake.stacken.kth.se.