Erstellt vor 7 Jahren

Geschlossen vor 4 Jahren

#1560 closed defect (fixed)

Domainname wird bei Namensauflösung nicht angehängt

Erstellt von: cuma Verantwortlicher:
Priorität: normal Meilenstein: freetz-next
Komponente: build-system Version: devel
Stichworte: Beobachter: er13
Product Id: 7320 Firmware Version:

Beschreibung

Bei der 7320 wird der lokale Domainname bei der Namensauflösung nicht automatisch angehängt. Auf mehreren gleich konfigurierten älteren Boxen Funktioniert dies problemlos und es wird ein 2. Versuch mit angehängter Domain gestartet. Überall ist dnsmasq im Image. Den Fehler kann man nachvollziehen wenn man die neue Option aus r7800 aktiviert. Google meinte dazu dass das vermutlich die "resolver library" das verursacht!?
Dabei ist mir noch aufgefallen dass dnsmasq immer zuerst AAAA versucht und dann erst A. Um die Namensauflösung zu beschleunigen dürfte es besser sein IPv4 bevorzugt zu behandeln. Evtl in Verbindung mit FREETZ_BUSYBOX_FEATURE_PREFER_IPV4_ADDRESS, die ich gesetzt habe!
Ich setze auf "kernel" da ich vermute dass dies den Unterschied ausmacht.

Anhänge (1)

uclibc_resolver_non_fqdn_lookups.patch (5.9 KB) - hinzugefügt von er13 vor 4 Jahren.
Mathias Kresin's patches referenced in comment:32

Alle Anhänge herunterladen als: .zip

Änderungshistorie (35)

comment:1 Geändert vor 7 Jahren durch cuma

7141 (okay)

$ ping thg540

16:08:41 dnsmasq[3840]: query[AAAA] thg540 from 127.0.0.1
16:08:41 dnsmasq[3840]: config thg540 is NODATA-IPv6

16:08:41 dnsmasq[3840]: query[AAAA] thg540.LOCAL from 127.0.0.1
16:08:41 dnsmasq[3840]: forwarded thg540.LOCAL to 192.168.178.1



16:08:41 dnsmasq[3840]: query[A] thg540 from 127.0.0.1
16:08:41 dnsmasq[3840]: config thg540 is NODATA-IPv4

16:08:41 dnsmasq[3840]: query[A] thg540.LOCAL from 127.0.0.1
16:08:41 dnsmasq[3840]: forwarded thg540.LOCAL to 192.168.178.1
16:08:41 dnsmasq[3840]: reply thg540.LOCAL is 192.168.100.1

7320 (fehler)

$ ping thg540

16:06:44 dnsmasq[5684]: query[AAAA] thg540 from 127.0.0.1
16:06:44 dnsmasq[5684]: config thg540 is NODATA-IPv6

16:06:44 dnsmasq[5684]: query[A] thg540 from 127.0.0.1
16:06:44 dnsmasq[5684]: config thg540 is NODATA-IPv4

$ ping thg540.LOCAL

16:13:28 dnsmasq[5684]: query[AAAA] thg540.LOCAL from 127.0.0.1
16:13:28 dnsmasq[5684]: forwarded thg540.LOCAL to 192.168.178.1

16:13:28 dnsmasq[5684]: query[A] thg540.LOCAL from 127.0.0.1
16:13:28 dnsmasq[5684]: forwarded thg540.LOCAL to 192.168.178.1
16:13:28 dnsmasq[5684]: reply thg540.LOCAL is 192.168.100.1

comment:2 Geändert vor 7 Jahren durch ralf

Ich wüsste nicht, was der Kernel damit zu tun haben sollte.

comment:3 Geändert vor 7 Jahren durch cuma

  • Komponente von kernel nach build-system geändert

Ich probier dann mal alle durch. Hängt es vielleicht am build-system?

comment:4 Geändert vor 7 Jahren durch ralf

Wie wäre es mit Busybox oder C-Library?

Normalerweise sollte für so etwas in /etc/resolv.conf diese Zeile stehen:

search local

BUSYBOX_FEATURE_PREFER_IPV4_ADDRESS sollte eben zuerst IPV4 und nicht IPV6 anfragen,

comment:5 Geändert vor 7 Jahren durch cuma

In der resolv.conf steht

nameserver 127.0.0.1
domain LOCAL

wie es generiert wird. Mit BusyBox 1.18.5 ändert sich nichts. Bleibt also die C-Library. Was kann ich das ausprobieren?

comment:6 Geändert vor 7 Jahren durch ralf

Du kannst mal probieren, ob search hilft statt domain.

Ansonsten den Quelltext anschauen.

comment:7 Geändert vor 7 Jahren durch cuma

"seach" hilft auch nicht. Ich hab jetzt von olistudent den Tip bekommen, dass ich die Toolchain selbst bauen muss.

comment:8 Geändert vor 7 Jahren durch cuma

Die Toolchain kann ich nicht bauen, diesem Probleme hab ich ein eigenes Ticket spendiert: #1565

Zuletzt geändert vor 7 Jahren von cuma (vorher) (Diff)

comment:9 Geändert vor 7 Jahren durch cuma

Mit selbst gebauter Toolchain und uClib 0.9.31.1 gleiches Problem :-/

comment:10 Geändert vor 7 Jahren durch cuma

Mit PTR gibt es auch Probleme

7320 (fehler)

$ traceroute thg540.LOCAL
traceroute to thg540.LOCAL (192.168.100.1), 30 hops max, 38 byte packets
 1  router..192.in-addr.arpa (192.168.178.1)  0.640 ms  0.678 ms  0.476 ms
 2  thg540.168.192.in-addr.arpa (192.168.100.1)  1.780 ms  1.973 ms  2.210 ms

7141 (okay)

$ traceroute thg540.LOCAL
traceroute to thg540.LOCAL (192.168.100.1), 30 hops max, 38 byte packets
 1  router.LOCAL (192.168.178.1)  1.427 ms  0.762 ms  router.LOCAL (192.168.178.1)  0.791 ms
 2  thg540.LOCAL (192.168.100.1)  3.518 ms  4.707 ms  1.888 ms

comment:11 Geändert vor 7 Jahren durch cuma

Neue Beobachtung mit der 7320 (7330 Alien)

# traceroute thg450
traceroute: bad address 'thg540'

# traceroute thg540.LOCAL
traceroute to thg540.LOCAL (192.168.100.1), 30 hops max, 38 byte packets
 1  date..192.in-addr.arpa (192.168.178.1)  0.602 ms  0.734 ms  0.514 ms
 2  thg540.168.192.in-addr.arpa (192.168.100.1)  3.633 ms  2.337 ms  2.905 ms

# rc.dnsmasq stop

# traceroute thg450
 1  dns.fritz.2.in-addr.arpa (192.168.178.1)  1.166 ms  0.558 ms  0.481 ms
 2  thg540.168.192.in-addr.arpa (192.168.100.1)  2.045 ms  3.626 ms  1.594 ms

vorher waren dies alle 3 Sekunden im syslog:

multid: _dns_gethostbyname: context "default" not initialized

comment:12 Geändert vor 7 Jahren durch cuma

Mit der 7390 funktioniert es nach r8828.

Mit uClibc 0.9.31

nslookup svn.freetz.org |tail -n1
Address 1: 85.214.100.221 vserver02.cte.

Mit uClibc 0.9.32

nslookup svn.freetz.org |tail -n1
Address 1: 85.214.100.221 vserver02.cte.de

comment:13 Geändert vor 7 Jahren durch cuma

  • Beobachter er13 hinzugefügt

comment:14 Geändert vor 7 Jahren durch cuma

Mit der 7320 FW 7330.05.20 (jetzt auch uClibc 0.9.32) funktioniert es. Da Toolchain selbst bauen nicht halt,müsste uClibc-0.9.31 die Ursache sein?

Zuletzt geändert vor 7 Jahren von cuma (vorher) (Diff)

comment:16 Geändert vor 7 Jahren durch cuma

In [8840]:

uClibc 0.9.31.1:

thx er13 (refs #1560)

comment:17 Geändert vor 7 Jahren durch cuma

Cool, Volltreffer!

 find /lib/ -name *uCli*
/lib/ld-uClibc-0.9.31.1.so
/lib/ld-uClibc.so.0
/lib/libuClibc-0.9.31.1.so

 nslookup svn.freetz.org |tail -n1
Address 1: 85.214.100.221 vserver02.cte.de

comment:18 Geändert vor 7 Jahren durch cuma

DL-Toolchain (EDIT: welche Box hat denn noch mips+uclibc-0.9.31??)

wie auch schon in #1637

Zuletzt geändert vor 7 Jahren von cuma (vorher) (Diff)

comment:19 Geändert vor 7 Jahren durch cuma

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert

comment:20 Geändert vor 6 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-2.0 geändert

comment:21 Antwort: Geändert vor 5 Jahren durch cuma

  • Lösung fixed gelöscht
  • Meilenstein von freetz-2.0 nach freetz-next geändert
  • Status von closed nach reopened geändert

Mit der 7490 die uClibc-0.9.32.1 verwendet gibt es wieder das Problem, dass eine lokale Namensauflösung nur mit angehängtem Domainnmane möglich ist
@er13: Fehlt da der Patch oder ist das was anderes?

comment:22 als Antwort auf: ↑ 21 Geändert vor 5 Jahren durch er13

Replying to cuma:

Mit der 7490 die uClibc-0.9.32.1 verwendet gibt es wieder das Problem, dass eine lokale Namensauflösung nur mit angehängtem Domainnmane möglich ist
@er13: Fehlt da der Patch oder ist das was anderes?

Passiert es wirklich nur auf 7490? Verwendest Du dnsmasq? Teste mal dnsmasq-2.68rc4, 2.67 ist buggy, 2.68-final ist wahrscheinlich diese Woche noch zu erwarten.

comment:23 Antwort: Geändert vor 5 Jahren durch cuma

Ich hab im LAN einen DNS (192.168.178.1) der alle internen Namen auflösen kann. Der wird von allen Geräten genutzt. Bei Hostnamen gebe ich die Domäne normal nicht an. Daher gehe ich davon aus, dass es mir aufgefallen wäre.
Mit 7270 04.8x uClibc-0.9.29 Freetz-11285 und 7390 06.00 uClibc-0.9.33.2 Freetz-11313 gibt es keine Probleme
Die /etc/resolv.conf sieht auf der 7490 gut aus (auch wenn ich mich frage weshalb nicht 127.0.0.1):

nameserver 127.0.0.2
domain local
options timeout:2
options attempts:2
#ping modem
dnsmasq[1388]: query[AAAA] modem from 127.0.0.2
dnsmasq[1388]: config modem is NODATA-IPv6
dnsmasq[1388]: query[A] modem from 127.0.0.2
dnsmasq[1388]: config modem is NODATA-IPv4

#ping modem.local
dnsmasq[1388]: query[AAAA] modem.local from 127.0.0.2
dnsmasq[1388]: forwarded modem.local to 192.168.178.1
dnsmasq[1388]: query[A] modem.local from 127.0.0.2
dnsmasq[1388]: forwarded modem.local to 192.168.178.1
dnsmasq[1388]: reply modem.local is 192.168.100.1

Dnsmasq ist installiert (und genau so konfiguriert wie auf der 7270), ich teste mal den RC, danke für den Tipp!

EDIT

2.68rc4 half nicht.
Wenn ich in die /etc/resolv.conf der 7490 den DNS auf den zentralen DNS ändere gehts. Log von diesem (kein RC)

dnsmasq[17581]: query[AAAA] modem from 192.168.178.69
dnsmasq[17581]: config modem is NODATA-IPv6
dnsmasq[17581]: query[A] modem from 192.168.178.69
dnsmasq[17581]: /etc/hosts modem is 192.168.100.1

Ich nutze übrigens kein IPv6, hab nur vergessen wo man die Präferenz einstellt

Zuletzt geändert vor 5 Jahren von cuma (vorher) (Diff)

comment:24 als Antwort auf: ↑ 23 Geändert vor 5 Jahren durch ralf

Replying to cuma:

2.68rc4 half nicht.
Wenn ich in die /etc/resolv.conf der 7490 den DNS auf den zentralen DNS ändere gehts. Log von diesem (kein RC)

dnsmasq[17581]: query[AAAA] modem from 192.168.178.69
dnsmasq[17581]: config modem is NODATA-IPv6
dnsmasq[17581]: query[A] modem from 192.168.178.69
dnsmasq[17581]: /etc/hosts modem is 192.168.100.1

Ich nutze übrigens kein IPv6, hab nur vergessen wo man die Präferenz einstellt

Das ist kein Fehler des DNS Servers, und auch der vorherige Patch betraf nicht den DNS-Server, sondern die C Library, also den DNS Client oder DNS Resolver.

Du schreibst, dass es mit dem anderen DNS Server geht. Wenn Du aber genauer hinschaust, siehst Du, dass dieser auch nur die Namen ohne das .local bekommt. Der Unterschied ist, dass er modem (nicht modem.local) in der /etc/hosts findet.

Das grundlegende Problem ist aber, dass der Client erst gar nicht nach modem.local fragt.

comment:25 Geändert vor 5 Jahren durch cuma

Der zentrale DNS hat die Hostnamen in der hosts-Datei, ja. Wenn ich "ping modem" (ohne Domäne) von der 7270 aus machen (die auch einen eigenen dnsmasq hat) sieht es im Gegensatz zu oben so am Haupt-DNS aus:

dnsmasq[20006]: query[A] modem.local from 192.168.178.123
dnsmasq[20006]: /etc/hosts modem.local is 192.168.100.1

Die 7270 macht es also richtig und hängt die lokale Domäne an. Die 7270 und 7490 sind in Bezug auf DNS gleich konfiguriert, mit Domäne, DNS und dnsmasq

Das grundlegende Problem ist aber, dass der Client erst gar nicht nach modem.local fragt.

Also Fehler der "resolv library"?

Zuletzt geändert vor 5 Jahren von cuma (vorher) (Diff)

comment:26 Geändert vor 5 Jahren durch er13

Welche uClibc-Version verwendest Du bei der 7490? Per Default wird 0.9.32.x verwendet, also dieselbe wie bei 7390-05.5x. Hast Du eine 7390? Könntest Du bitte 05.5x drauf flashen. Wenn es auf der 7390 geht, dann liegt es NICHT an der uClibc. Wenn es auf der 7390 mit 05.5x auch nicht geht, dann schaue Dir alle 990-res_*-Patches für uClibc-0.9.33.x an.

Edit: alternative Lösung, baue 7490 mit 0.9.33.x - brauchst nicht mal "self-built toolchain" dafür auswählen, geht auch mit der download-toolchain.

Zuletzt geändert vor 5 Jahren von er13 (vorher) (Diff)

comment:27 Geändert vor 5 Jahren durch cuma

Standard uClibc-0.9.32 auf der 7490. Die 7390 ist der DNS mit ein Einträgen in der hosts. Die lief bis vor kurzem auf 5.52, hatte damit keine Probleme - wohl doch nicht diese resolv-library.
7490 mit uClibc-0.9.33.2 funktioniert auch nicht ohne Domainnamen, damit hat es nichts mit uClibc zu tun

comment:28 Geändert vor 5 Jahren durch er13

Könnte doch an uClibc liegen, s. diesen upstream commit. 7490 hat zwei 2 CPUs, damit könnte es theoretisch sein, dass das Problem nur auf der 7490 auftritt (wobei ping ein busybox-applet ist und busybox nicht multi-threaded ist). Bin mir nicht ganz sicher, ob uClibc mehrfach geladen wird oder von allen Prozessen ge'shared wird. Wenn das letztere, könnte es das Problem erklären.

comment:29 Geändert vor 5 Jahren durch er13

In 11418:

uClibc-0.9.33.x:

  • add more upstream patches
  • refs #1939, (maybe?) refs #1560

comment:30 Geändert vor 5 Jahren durch cuma

Hab jetzt für die 7490 ne eigene Toolchain gebaut. Danach fiel mir auf dass diese uClibc 0.9.32.1 verwendet…

comment:31 Geändert vor 5 Jahren durch cuma

Mit selbstgebauter 0.9.33 funktioniert es auch nicht auf der 7490

comment:32 Geändert vor 4 Jahren durch er13

TODOs:

Geändert vor 4 Jahren durch er13

Mathias Kresin's patches referenced in comment:32

comment:33 Geändert vor 4 Jahren durch er13

In 12760:

uClibc-0.9.33.x:

  • add resolver related patches provided by Mathias Kresin on the uClibc mailing list: #1, #2
  • refs #1560, refs #1939

comment:34 Geändert vor 4 Jahren durch er13

  • Lösung auf fixed gesetzt
  • Status von reopened nach closed geändert

Expected to be fixed for uClibc-0.9.33 in r12760. Won't fix for all other uClibc versions.

Feel free to reopen if you're still experiencing this problem with uClibc-0.9.33.

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.