[gelöst mit Labor 17941] resolv.conf / Probleme mit DNS-Auflösung

udosw · 24 Jul 2010

Ich habe heute die Produktive 7270 von Labor-17828 auf 17891 mit jeweils dem aktuellen Freetz-Trunk upgedatet. (Auf meiner Testbox lief die 17828 lief mit Freetz seit Erscheinen ohne Probleme.)

Zunächst schien DNS gar nicht zu gehen. Die /etc/resolv.conf sah zu der Zeit (wie immer) so aus:

Code:

nameserver 192.168.180.1
nameserver 192.168.180.2

Das hatte bisher problemlos funktioniert. Ich bin dann probeweise mal auf die Labor-17891 ohne Freetz gegagen, da gab es keine Probleme mit der DNS-Auflösung. Leider habe ich versäumt zugucken, wie dann die /etc/resolv.conf aussieht, aber ich bin eigentlich ziemlich sicher, dass es so wie oben ist.

Dann habe ich wieder mit Freetz geflasht und in der resolv.conf den DNS meines Providers und Google eingetragen:

Code:

nameserver 83.169.186.161
nameserver 8.8.8.8

Damit erhalte ich jetzt auf der Box und den Rechnern im Netz wieder DNS, allerdings nicht innerhalb der Box, soll heißen, die Anmeldung der SIP-Accounts (hier Sipgate) scheitert mit DNS-Fehler.

Wie sollte denn die resolv.conf 'normalerweise' aussehen? Hat sich in den letzten 3 Tagen in Freetz etwas beim DNSmasq geändert?

Udo

olistudent · 24 Jul 2010

Nutzt du dnsmasq? Hier hatte sich in den letzten Tagen ein Fehler eingeschlichen den cuma aber schon wieder behoben hat.

MfG Oliver

frank_m24 · 24 Jul 2010

Hallo,

was ist mit "/var/tmp/avm-resolv.conf"? Die spielte doch auch immer noch eine Rolle im AVM DNS System.

marcus010676 · 24 Jul 2010

Habe genau den gleichen Fehler mit der aktuellen labor, mit freetz wird mein sipgate Account mit DNS Fehler nicht verbunden.

Der Zeitserver wird auch nicht erreicht.

Mit aktiver DNSmasq funzt die Namensauflösung gar nicht mehr, komme dann nur noch mittels IP auf die Box.

Gruß

Marcus

sf3978 · 24 Jul 2010

frank_m24 schrieb:
was ist mit "/var/tmp/avm-resolv.conf"? ...

Sollte als symlink vorhanden sein:

Code:

/var/mod/root # ls -la /var/tmp/avm-resolv.conf
lrwxrwxrwx    1 root     root            11 Jan  1  2000 /var/tmp/avm-resolv.conf -> resolv.conf

Code:

Nach Analyse mit oliver hat sich herausgestellt, dass die Datei /var/tmp/avm-resolv.conf fehlt. Weshalb ist noch offen. Wohl irgendwas im Zusammenspiel von dnsmasq+multid+warpper. Nach ln -s resolv.conf /var/tmp/avm-resolv.conf funktionieren die sip-Accounts wieder
EDIT: Das Problem lag an rc.dnsmasq. Es ermittelt mit pidof multid ob multid läuft. Da der multid-wrapper multid heisst war das beim Boxstart immer der Fall…

udosw · 24 Jul 2010

olistudent schrieb:
Nutzt du dnsmasq?

Ja (klar ;-) ). U.a. wg. DHCP (Hosts, feste IPs) und auch weil ich bestimmte lokale Adressen per DNS auflösen muss.
Also, mit resolv.conf:

Code:

nameserver 169.254.180.1
nameserver 169.254.180.2

funktioniert es nur wenig besser: Shell auf der Box löst so zwar DNS-Anfragen auf, aber der SIP-Client der Box immer noch nicht.

Workaround: dnsmasq stoppen, Sipgate anmelden, dnsmasq starten. Ich schätze nur, das Sipgate in einer halben Stunde oder so nicht mehr geht ... ich werde berichten.

The Brad · 24 Jul 2010

Kann den Fehler exakt bestätigen, habe ebenfalls versucht, die aktuelle Labor-Firmware zu freetzen und ich nutze ebenfalls dnsmasq.

udosw · 25 Jul 2010

sf3978 schrieb:
Nach ln -s resolv.conf /var/tmp/avm-resolv.conf funktionieren die sip-Accounts wieder

Kann ich nicht bestätigen. Der Link ist vorhanden, aber die SIP-Accounts werden wg. DNS-Fehler nicht angemeldet. Eben machte die Box einen spontanen Reboot, den konnte ich an der Console verfolgen. Was mir auffällt ist die Meldung bei dnsmasq 'already running'. Ist das normal?

Code:

Console Ausgaben auf dieses Terminal umgelenkt
fritz:/var/mod/root# Jul 25 09:29:05 capiotcp_server[2284]: 

capiotcp_server - Version 0.1.01.05
        TCP/UDP Port = 5031
        MaxCntrl     = 5
        OffsetCntrl  = 0



MiniD 3.8.38, build 20100721 (+quiet +alloc -pimsg svn 4151 bpi 20070305 frfc 1.58.10 base 004082b0)

run_clock demon started

rc.mod version freetz-devel
Jul 25 09:29:16 MiniD[2431]: brim_stage3(2086): new client (handle 1, mac 000000000000, version(hw 00000005, sw 00000000, oem 00000001, proto 00010027))
create sema UPNPAPI_DATA_fritzmini
Jul 25 09:29:17 MiniD[2431]: brim_stage3(2086): new client (handle 2, mac 001f3f0fd53d, version(hw 00000007, sw 00020011, oem 00000001, proto 0001003a))
read pb_read_entry: Interrupted system call
Jul 25 09:29:17 pbd[2180]: received signal: Broken pipe.
Jul 25 09:29:17 pbd[2180]: received signal: Broken pipe.
Starting crond...Jul 25 09:29:18 crond[2523]: crond: crond (busybox 1.16.2) started, log level 8
done.
Starting telnetd...done.
Starting Freetz webinterface...done.
Starting swap...done.
Starting syslogd...done.
Staring klogd...failed.
Updating inetd config for dropbear: inactive.
Updating inetd config for rrdstats (webcfg-one): inactive.
Updating inetd config for rrdstats (webcfg-rrd): inactive.
Updating inetd config for telnetd: inactive.
Updating inetd config for vnstat (webcfg-vns): inactive.
Updating inetd config for webcfg: inactive.
Reloading inetd...not running.
Writing /var/flash/freetz...done.
44032 bytes written.
Starting inetd...done.
Setting up SSH authorized_keys for root...done.
Starting dropbear SSH server...done.
Starting dnsmasq...already running.
Starting openntpd...done.
callmonitor is disabled
openvpn is disabled
Starting nfsd...done.
RRDstats 
backup skipped, no files found...
Starting rrdstats...done.
rsync is disabled.
Starting vnstat...done.
              total         used         free       shared      buffers
  Mem:        60968        57348         3620            0         3056
 Swap:       131064            0       131064
Total:       192032        57348       134684
INFORMATION: Installing asterisk16 (http://www.spblinux.de/fbox.new/0.9.29/26-ur8) to /var/media/ftp/uStor01/addons ...
INFORMATION: asterisk16 already on USB-Device ... skipping extract phase.
#####################################################################
Performing root install ... This may take a couple minutes.
Aborting during this period will render your system inoperable!!!
#####################################################################
INFORMATION: asterisk16 start disabled during ROOT overlaying phase ...
Installation progress: ........
INFORMATION: ROOT overlaying phase finished. asterisk16 starting enabled!
              total         used         free       shared      buffers
  Mem:        60968        57744         3224            0         2740
 Swap:       131064            0       131064
Total:       192032        57744       134288
to use asterisk16 type ./cfg_asterisk16 start
(/var/media/ftp/uStor01/addons/cfg_asterisk16 start or simply asterisk16)

After a reboot you may reinstall asterisk16 from usb with
/var/media/ftp/uStor01/addons/cfg_asterisk16 usb_install
killall: minid: no process killed
killall: minid: no process killed
modprobe: failed to load module rfcntl (kernel/drivers/net/rfcntl/rfcntl.ko): Input/output error

MiniD 3.8.38, build 20100721 (+quiet +alloc -pimsg svn 4151 bpi 20070305 frfc 1.58.10 base 004082b0)

Jetzt läuft dnsmasq, aber die Sipgate-Accounts sind nicht angemeldet, obwohl die DNS-Auflösung funktioniert:

Code:

fritz:/var/mod/root# nslookup sipgate.de
Server:    169.254.180.1
Address 1: 169.254.180.1

Name:      sipgate.de
Address 1: 217.10.79.9 sipgate.de
fritz:/var/mod/root# cat /etc/resolv.conf 
nameserver 169.254.180.1
nameserver 169.254.180.2

Dann habe ich dnsmasq gestoppt, die Sipgate-Accounts angemeldet und dnsmasq wieder gestartet. Die waren übrigens bis zum Neustart eben die ganze Nacht über angemeldet geblieben, trotz dann laufendem dnsmasq.

Ich kann nicht sagen, dass ich das versehe ...

sf3978 · 25 Jul 2010

udosw schrieb:
Kann ich nicht bestätigen. Der Link ist vorhanden, [...]

Wie sind bei dir folgende Ausgaben:

Code:

# cat /var/tmp/avm-resolv.conf

Code:

# cat resolv.conf

Code:

# cat /var/tmp/resolv.conf

frank_m24 · 25 Jul 2010

Hallo,

ich hatte jetzt Gelegenheit, in meine Box zu sehen, und ich habe in den dnsmasq Einstellungen im Feld Zusätzliche Kommandozeilen-Optionen (für Experten) folgendes drin:

Code:

--resolv-file=/var/tmp/avm-resolv.conf

Ich weiß nicht mehr genau, was damals die Ursache war, aber irgendeinen Grund werde ich gehabt haben, diese Eintragung vorzunehmen ...

sf3978 · 25 Jul 2010

Die Box hat ja einige "resolv.conf"-Dateien bzw. symlinks auf diese:

Code:

# find / -iname '*resolv*.conf'
(/etc/resolv-dnsmasq.conf)
/etc/resolv.conf
/var/tmp/avm-resolv.conf
/var/tmp/flash/mod/resolv.conf
/var/tmp/resolv.conf

Weiß jemand welche "resolv.conf"-Datei benutzt wird und welche geeignete nameserver dort eingetragen werden müssen, wenn:

- Die Box als dns-Server für Clients fungiert
- z. B. ein nslookup in der Konsole der Box gemacht wird
- für interne Boxanwendungen
- ...

Durch "Try and Error" kann man das feststellen.

olistudent · 25 Jul 2010

Bei der Nutzung von dnsmasq wird die avm-resolv.conf auf die resolv.conf verlinkt. Vergleicht doch mal bitte die IPs in den Dateien bei der Nutzung von dnsmasq und falls er aus ist. Dabei solltet ihr darauf achten, dass der multid die avm-resolv.conf neu anlegt also nicht den Symlink nutzt. Der multid legt die avm-resolv.conf übrigens nur an, wenn der dnsmasq nicht läuft!

MfG Oliver

sf3978 · 25 Jul 2010

Bei mir läuft dnsmasq. Und der symlink "/var/tmp/avm-resolv.conf" existiert und zeigt auf "/var/tmp/resolv.conf". Und in der "/var/tmp/resolv.conf" sind andere nameserver eingetragen, als in der "/etc/resolv.conf" & Co.

EDIT:
Wenn dnsmasq nicht läuft, dann gibt es bei mir den symlink "/var/tmp/avm-resolv.conf" nicht. Dafür gibt es die Datei ""/var/tmp/avm-resolv.conf" mit dem Eintrag wie vorher der symlink. Die Datei "/var/tmp/resolv.conf" hat jetzt den Eintrag:

Code:

# cat /var/tmp/resolv.conf
nameserver 127.0.0.1

Evtl. haben die Anwendungen jetzt Pech, die die "/var/tmp/resolv.conf" nutzen. Aber dnsmsq läuft bei mir immer. außer systembedingte Restarts von dnsmasq.

udosw · 25 Jul 2010

sf3978 schrieb:
Wie sind bei dir folgende Ausgaben:

Neustart der Box, dnsmasq läuft, DNS-Fehler:

Code:

# find / -iname '*resolv*.conf' -exec echo === {} === \; -exec cat {} \;
=== /etc/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/avm-resolv.conf ===
nameserver 192.168.180.1
nameserver 192.168.180.2
=== /var/tmp/flash/mod/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/resolv.conf ===
nameserver 192.168.180.1
nameserver 192.168.180.2

dnsmasq gestoppt, SIP-Accounts melden sich (nach einer Weile) von selber an:

Code:

# find / -iname '*resolv*.conf' -exec echo === {} === \; -exec cat {} \;
=== /etc/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/avm-resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/flash/mod/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/resolv.conf ===
nameserver 127.0.0.1

dnsmasq wieder gestartet, SIP-Accounts bleiben auch langfristig angemeldet:

Code:

# find / -iname '*resolv*.conf' -exec echo === {} === \; -exec cat {} \;
=== /etc/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/avm-resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/flash/mod/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2

Gelöst:
Erste Zeile in meiner rc.custom lautet jetzt:

Code:

ln -sf /etc/resolv.conf /var/tmp/avm-resolv.conf

nun ist:

Code:

# find / -iname '*resolv*.conf' -exec echo === {} === \; -exec cat {} \;
=== /etc/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/avm-resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/flash/mod/resolv.conf ===
nameserver 169.254.180.1
nameserver 169.254.180.2
=== /var/tmp/resolv.conf ===
nameserver 192.168.180.1
nameserver 192.168.180.2

SIP-Accounts melden sich nach Neustart sofort an, dnsmasq läuft und DNS-Auflösung ist überall OK. Übrigens funktioniert jetzt die Anmeldung des Mini auch spontan, da gab es vorhin auch noch ein Problem, was offenbar auch mit diesem zusammenhing.

Das würde bedeuten, dass die SIP-Accounts der Box ihren DNS über die /var/tmp/avm-resolv.conf finden, denn der ist jetzt anders.

Udo

olistudent · 25 Jul 2010

Hast du hier im Thread schon geschrieben welche Freetz-Version du verwendest? Da hatte sich ein Fehler eingeschlichen, der ist in r5270 behoben und sollte deinen Eintrag in der rc.custom überflüssig machen. Falls dem nicht so ist bitte melden!

MfG Oliver

sf3978 · 25 Jul 2010

Auf welche "resolv.conf" soll der symlink "/var/tmp/avm-resolv.conf" zeigen? Denn die "resolv.conf" gibt es nicht.

Code:

/var/mod/root # ls -la /var/tmp/avm-resolv.conf
lrwxrwxrwx    1 root     root            11 Jul 25 12:04 /var/tmp/avm-resolv.conf -> resolv.conf

olistudent · 25 Jul 2010

Hm. Der Symlink zeigt dann auf /var/tmp/resolv.conf. Wobei er ja eigentlich auf /etc/resolv.conf zeigen sollte!? Da sollten wir nochmal nachschauen.

MfG Oliver

udosw · 25 Jul 2010

olistudent schrieb:
Hast du hier im Thread schon geschrieben welche Freetz-Version du verwendest?MfG Oliver

Ich verwende 5284.

olistudent schrieb:
Hm. Der Symlink zeigt dann auf /var/tmp/resolv.conf. ...

In der Tat. Dieser Symlink ohne absoluten oder relativem Pfad kam mir gleich komisch vor!!!
Udo

olistudent · 25 Jul 2010

Könntest du mal ein Screenshot von der Internt Einstellungsseite machen? Ich versteh momentan nicht warum dein voipd ein Problem mit den AVM-IPs (192.168.180.1/2) hat.

MfG Oliver

udosw · 26 Jul 2010

olistudent schrieb:
Könntest du mal ein Screenshot von der Internt Einstellungsseite machen?

Kann ich jetzt nicht, aber als Info sollte doch reichen, dass ich über ein Kabelmodem ins Netz gehe:
[X] Internetzugang über LAN 1
[X] Internetverbindung selbst aufbauen (NAT-Router mit PPPoE oder IP)
[X] Zugangsdaten werden nicht benötigt (IP)

olistudent schrieb:
Ich versteh momentan nicht warum dein voipd ein Problem mit den AVM-IPs (192.168.180.1/2) hat.

Ganz einfach: Wenn ich in der /etc/resolv.conf die 192.168.180.1/2 stehen habe, läuft die DNS-Abfrage gegen einen Timout. Der antwortet einfach nicht.

Udo

[gelöst mit Labor 17941] resolv.conf / Probleme mit DNS-Auflösung

Aktives Mitglied

IPPF-Urgestein

IPPF-Urgestein

Neuer User

IPPF-Promi

Aktives Mitglied

Mitglied

Aktives Mitglied

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

Aktives Mitglied

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Statistik des Forums