hostname an FB übertragen

[cwarlich]

Hallo,

wenn ich meinen Rechner mit Windows boote, wird der von mir unter Windows vergebene Hostname vom DHCP Server der FB erkannt und erscheint unter Einstellungen/Netzwerk.
Wenn ich hingegen Linux boote, steht dort nur die IP-Adresse mit PC- vorangestellt.

Ich benutze dhcp3-client unter Ubuntu, ich denke mal, dass hier das Problem liegt, denn wenn man stattdessen die IP mit dem (veralteten?) Paket dhcpcd bezieht, z.B:

dhcpcd -h scooter eth1

erscheint der Hostname auf der FB.

Ich weis, die Frage ist wahrscheinlich etwas OT, aber ich habe sonst keine gute Idee, wo ich sonst fragen könnte.

Gruß,

Christof

 

[RalfFriedl]

Du könntest irgendwo nachfragen, wo man sich mit Ubuntu auskennt, oder besser noch die Dokumentation vom dhcp3-client suchen.

 

[cwarlich]

Die Doku habe ich schon angesehen, (man dhclient.conf und man dhcp-option). Es gibt da eine "option host-name=xxx", aber die scheint nichts zu bewirken.

Aber Du hast natürlich recht, ist hier OT. Da dhcp3-client aber inzwischen recht verbreitet bei Linux-Distributionen zu sein scheint, hätte mich nur interessiert, wie die Linux-Nutzer hier im Forum mit dem Problem umgehen. Immerhin kann man die Linux-Hostst so nur direkt über ihre IP ansprechen.

Alternativ kann man natürlich dnsmasq aus freetz verwenden und für jeden Linux-Rechenr ein festes Mapping Ethernet-Adresse <-> Hostname eintragen. Finde ich aber nicht so schick.

Egal, ich such' mal nach sowas wie einer dhcp3-client Mailing List oder stelle auf dhcpcd um.

 

[smileyman]

Von Linux habe ich da leider zu wenig Ahnung.
Dennoch ohne Modifikation bekommst du wohl auch mit Host-Name keine DNS-Auflösung hin, da die Fritz!Box ja grundsätzlich nur externe (ins Internet) DNS-Anfragen abwickelt.
Bei Windows-Rechnern geht das soweit ich weiß nur via Broadcast, dass die Nachbarrechner gefunden werden.

Ich denke, dass du da zwangsläufig auf dnsmasq setzen musst. - Zwar erflgt dann auch in der Weboberfläche keine Namens-Anzeige. - DNS funktioniert dann aber.

Sollte aber auch dnsmasq den Host-Namen nicht auflösen können wird dieser wohl wirklich nicht mitgegeben.
Scheinbar muss dazu erst in das Config-File vom dhcp3-client 'send host-name "hostname";' eingetragen werden. - (Kannst ja mal danach googlen.)

Grüße
smileyman

 

[cwarlich]

Du hast recht - obwohl der Hostname jetzt im Webinterface drin steht, wird er nicht aufgelöst. Scheinbar hat das Erscheinen des Namens im Web-Interface und DNS-Auflösung nichts miteinander zu tun.

Ich werd's jetzt mal mit dnsmasq probieren, zumindest mit dhcpcd sollte die Namensauflösung dann ja gehen. Aber vielleicht liegst Du ja auch hier richtig und es geht sogar mit dlclient3.

Soweit erstmal vielen Dank für die Tips!

Gruß,

Christof

 

[cwarlich]

Hi smileyman,

Mit dnsmasq geht die Namensauflösung sowohl mit dhcpcd als auch mit dnsclient3! Ich habe mich einfach zu sehr auf das Erscheinen bzw. Nichterscheinen des Hostnamens im Fritz!Box Webinterface mit dem AVM DHCP Client verlassen.

Nochmals danke für Deine kompetente Hilfe,

Christof

 

[smileyman]

Hallo Christof,
freut mich, dass es geklappt hat.
- Auch ich bin von dnsmasq begeistert, da es endlich eine richtige DNS-Auflösung ermöglicht. (Endlich braucht mein Drucker keine Fix-IP mehr und kann via Namen angesprochen werden. - Schon eine super Sache)

Grüße
smileyman

 

[cwarlich]

Scheinbar habe ich mich doch zu früh gefreut:

Wenn ich die FB neu starte, geht die DNS-Auflösung erstmal nicht, obwohl dnsmasq läuft. Wenn man dnsmasq dann über das Webinterface stoppt und wieder startet, geht es plötzlich.

Ich rate mal, daß die Namensauflösung von dnsmasq nur dann funktioniert, wenn es _nach_ dem dsld gestartet wird. Aber leider blicke ich bei der Startreihenfolge der Scripte in /etc/init.d nicht durch. Kann mir jemand sagen, von wo die Scripte in welcher Reihenfolge gestartet werden?

Gruß,

Christof

 

[ao]

(Endlich braucht mein Drucker keine Fix-IP mehr und kann via Namen angesprochen werden. - Schon eine super Sache)

Sorry, dass ich mal nachfrage:
Aber wieso nutzt Du nicht feste IPs und schreibst die Hostnamen (u.a. auch von Deinem Drucker) nach /etc/hosts zu den IP-Adressen dazu?

 

[cwarlich]

... weil es einfach nicht so schön ist : Jeder neue Nutzer im Netz muß dann seinen PC erst in der /etc/hosts eintragen. Dazu braucht er Admin-Rechte auf der Box. Dagegen hat man mit DHCP und dnsmasq alles auf Client-Seite in der Hand.

 

[olistudent]

multid macht DNS- und DHCP-Server. Und eigentlich sollte sichergestellt sein, dass der dnsmasq immer den Port vor dem multid belegt.

MfG Oliver

 

[cwarlich]

multid macht DNS- und DHCP-Server. Und eigentlich sollte sichergestellt sein, dass der dnsmasq immer den Port vor dem multid belegt.

Ich glaube auch nicht, dass dnsmasq beim Booten der FB wegen belegten Ports nicht richtig tut, denn dann würde das Problem ja nicht verschwinden, wenn man dnsmasq nochmal von Hand neu startet.

Der wesentliche Grund, weswegen ich ein Reihenfolgeproblem bzgl. dnsmasq und dsld in Verdacht habe:

1. Wenn man man dsld beim Build mit make menuconfig ganz rauskonfiguriert (ich brauche kein DSL, da ich die FB nur als Ethernet-Router betreibe) geht kein Routing mehr. dsld scheint also für's Routing nötig zu sein.
   
2. Wenn man nach dem Booten "ps" auf der FB eingibt, erscheint dnsmasq _vor_ dsld. Meine Theorie ist, dass er dann traurig ist, weil das Routing noch nicht geht.
   
3. In jedem Fall hat es mich gewundert, dass route -n auf der FB weder mit noch ohne dsld (und unabhängig davon, ob man dnsmasq benutzt oder nicht) eine Default-Route zu dem Router anzeigt, der den (DSL)-Zugang ins Internet bereitstellt. Mit meiner Konfiguration (FB 7170 als DSL-Router mit der IP 192.168.178.1 und FB 7270 als Ethernet-Router mit der IP 192.168.178.3 zum DSL Router und 192.168.0.1 zum LAN) habe ich auf meinem Client PC wie zu erwarten:
   

   christof@scooter:~$ route -n
   Kernel-IP-Routentabelle
   Ziel            Router          Genmask         Flags Metric Ref    Use Iface
   192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
   169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth1
   0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth1

   auf der FB 7270 aber nur:
   

   /var/mod/root # route -n
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
   192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
   192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 lan
   169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
   0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

   Hier fehlt mir eine Zeile in der Art:
   

   0.0.0.0         192.168.178.1     0.0.0.0         UG    0      0        0 ???

   wobei ich nicht weiß, welches Interface da stehen müsste, denn bei einem ifconfig auf der FB gibt es keins mit der IP 192.168.178.3:
   

   /var/mod/root # ifconfig
   ath0      Link encap:Ethernet  HWaddr 00:1C:4A:4E:E4:B8
             UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:2290  Metric:1
             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
             TX packets:95 errors:0 dropped:2 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:0 (0.0 B)  TX bytes:20472 (19.9 KiB)
   
   cpmac0    Link encap:Ethernet  HWaddr 00:1C:4A:68:25:BD
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:1464 errors:0 dropped:0 overruns:0 frame:0
             TX packets:1270 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:256
             RX bytes:716079 (699.2 KiB)  TX bytes:699300 (682.9 KiB)
   
   dsl       Link encap:Point-to-Point Protocol
             inet addr:169.254.2.1  P-t-P:169.254.2.1  Mask:255.255.255.255
             UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
             RX packets:84 errors:0 dropped:0 overruns:0 frame:0
             TX packets:363 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:100
             RX bytes:7948 (7.7 KiB)  TX bytes:35807 (34.9 KiB)
   
   eth0      Link encap:Ethernet  HWaddr 00:1C:4A:68:25:BD
             UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
             RX packets:701 errors:0 dropped:0 overruns:0 frame:0
             TX packets:363 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:75681 (73.9 KiB)  TX bytes:56752 (55.4 KiB)
   
   lan       Link encap:Ethernet  HWaddr 00:1C:4A:68:25:BD
             inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
             UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
             RX packets:698 errors:0 dropped:0 overruns:0 frame:0
             TX packets:365 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:62847 (61.3 KiB)  TX bytes:56864 (55.5 KiB)
   
   lan:0     Link encap:Ethernet  HWaddr 00:1C:4A:68:25:BD
             inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
             UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
   
   lo        Link encap:Local Loopback
             inet addr:127.0.0.1  Mask:255.0.0.0
             UP LOOPBACK RUNNING  MTU:16436  Metric:1
             RX packets:289 errors:0 dropped:0 overruns:0 frame:0
             TX packets:289 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:37076 (36.2 KiB)  TX bytes:37076 (36.2 KiB)
   
   wan       Link encap:Ethernet  HWaddr 00:1C:4A:68:25:BD
             UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
             RX packets:763 errors:0 dropped:0 overruns:0 frame:0
             TX packets:473 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:640398 (625.3 KiB)  TX bytes:50177 (49.0 KiB)
   
   wifi0     Link encap:Ethernet  HWaddr 00:1C:4A:4E:E4:B8
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:151 errors:0 dropped:0 overruns:0 frame:9
             TX packets:121 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:26423 (25.8 KiB)  TX bytes:25957 (25.3 KiB)
             Interrupt:80 Memory:c0320000-c0330000

Egal, Punkt 3 verstehe ich zwar nicht und es ist auch schade, dass man dsld nicht rausschmeißen kann, um Speicherplatz zu sparen. Aber das Routing geht ja immerhin, solange dsld läuft.

Es bleibt also die Kernfrage, warum der DNS Lookup nach innen (ins 192.168.0.0-Netz) erst geht, wenn dnsmasq neu gestartet wird. Um hier weiter zu debuggen, würde ich dnsmasq testweise gerne erst später (nach dsld) starten. Aber leider finde ich nicht, wo dnsmasq gestartet wird: Über /etc/inittab wird /etc/init.d/rc.S und von da /etc/init.d/rc.net
aufgerufen. Und in /etc/init.d/rc.net finde ich die Zeilen:

   igddstart
   multidstart

   if [ "$CONFIG_DSL" ] ; then
     if [ "`pidof dsld`" = "" ] ; then
       if [ "$CONFIG_RAMSIZE" = 8 ] ; then
         dsld -i -n $NICEPARAM -r 600 $VERBOSEPARAM $DSLDDPARAM
       else
         dsld -i -n $NICEPARAM $VERBOSEPARAM $DSLDDPARAM
       fi
     fi
   fi
}

aber ein "ps" ergibt (Ausschnitt):

/etc/init.d # ps
...
  604 root       3828 S   usermand
  609 root       4960 S   igdd
  638 root        860 S   dnsmasq -S 192.168.178.1 -p 53 -E -s fritz.box
  641 root       3996 S   multid
  657 root       4984 S   dsld -i -n
...

Irgendjemand startet also offensichtlich dnsmasq zwischen dem Aufruf von iggdstart und multidstart, aber hier komme ich einfach nicht weiter: Ich finde einfach nicht, wo.

Sorry für das lange Posting und vielen Dank schonmal für jede Hilfe,

Christof

 

[McNetic]

Es würde mich stark wundern, wenn der dsld dafür notwendig wäre, das Problem wäre dann ja schon lange aufgefallen, denn den 'remove dsld' patch gibt es ja auch schon lange. Ich vermute eher, daß die Box nicht korrekt für ATA konfiguriert ist. Ich kenn mich damit nicht aus, aber hier im Forum findest Du vielleicht was dazu.

 

[cwarlich]

Hmm - was soll ich dazu sagen? Auch wenn ich dsld im laufenden Betrieb mit kill abschieße, während ein ping von meinem Client-PC läuft, passiert das:

christof@scooter:~/freetz/freetz-trunk$ ping www.suse.de
PING turing.suse.de (195.135.220.3) 56(84) bytes of data.
64 bytes from turing.suse.de (195.135.220.3): icmp_seq=1 ttl=52 time=60.8 ms
64 bytes from turing.suse.de (195.135.220.3): icmp_seq=2 ttl=52 time=60.2 ms
64 bytes from turing.suse.de (195.135.220.3): icmp_seq=3 ttl=52 time=60.1 ms
64 bytes from turing.suse.de (195.135.220.3): icmp_seq=4 ttl=52 time=60.5 ms
64 bytes from turing.suse.de (195.135.220.3): icmp_seq=5 ttl=52 time=60.0 ms
....
64 bytes from turing.suse.de (195.135.220.3): icmp_seq=53 ttl=52 time=60.3 ms
From fritz.box (192.168.0.1) icmp_seq=56 Destination Net Unreachable
From fritz.box (192.168.0.1) icmp_seq=57 Destination Net Unreachable
From fritz.box (192.168.0.1) icmp_seq=58 Destination Net Unreachable
From fritz.box (192.168.0.1) icmp_seq=59 Destination Net Unreachable

Sobald man den dsld mit "dsld -i -n" wieder startet, geht der ping sofort wieder.

Dabei ist die FB nur über LAN1 mit der Außenwelt verbunden, der DSL-Anschuß ist unbenutzt.

 

[RalfFriedl]

Beim Patch "remove dsld" steht doch, daß man ihn nur verwenden soll, wenn die Box als IP-Client läuft. Vielleicht nicht deutlich genug steht, daß man den Patch nicht verwenden soll, wenn man die Box als NAT-Router über LAN1 verwendet.

 

[cwarlich]

Fein. Und jetzt wissen wir auch, warum man ihn braucht, wenn die FB als NAT-Router konfiguriert ist: dsld macht offensichtlich das Routing zum Upstream-Router.

Mich würde zwar immer noch interessieren, warum das Default-Gateway auf der FB bei route-n nicht auftaucht und ifconfig kein Interface für LAN1 mit der entsprechenden IP (in meinem Fall 192.168.178.3, s.o.) konfiguriert, aber vielleicht kann die Frage ja nur der entsprechnde AVM-Entwickler beantworten.

Und mein Hauptproblem bleibt: Warum klappt der DNS Lookup ins interne Netz erst, wenn dnsmasq restarted wird? Ich bin weiter intensiv auf der Suche nach dem Grund, freue mich aber über jeden Tip, von allem bzgl. des Stelle, wo und wie dnsmasq beim booten gestartet wird.

 

[smileyman]

Meine 7170 läut nur als Router und nicht als Modem und hängt hinter meinem Kabelmodem.
Bei mir funktioniert dnsmasq allerings problemlos. - Ich lasse es jedoch mit dem Parameter "--resolv-file=/var/tmp/avm-resolv.conf -p 53" laufen.
dsld wird bei mir wesentlich früher hochgezogen. - igdd ebenfalls, jedoch mehrfach. Auf dnsmasq folgt anschließend multid

  PID  Uid        VSZ Stat Command
    1 root       1420 S   init
    2 root            SWN [ksoftirqd/0]
    3 root            SW< [events/0]
    4 root            SW< [khelper]
    5 root            SW< [kthread]
    6 root            SW< [kblockd/0]
   23 root            SW< [pdflush]
   24 root            SW< [pdflush]
   26 root            SW< [aio/0]
   25 root            SW  [kswapd0]
   62 root            SW  [pm_info]
   69 root            SW  [mtdblockd]
   89 root            SW  [tffsd_mtd_0]
  361 root            SW< [capi_oslib]
  362 root            SW< [capi_oslib]
  363 root            SW  [capitransp]
  384 root            SW< [khubd]
  479 root      13100 S N /usr/bin/avm/ctlmgr
  528 root            SWN [scsi_eh_0]
  529 root            SWN [usb-storage]
  537 root      13100 S N /usr/bin/avm/ctlmgr
  538 root      13100 S N /usr/bin/avm/ctlmgr
  540 root      13100 S N /usr/bin/avm/ctlmgr
  571 root       5196 S   igdd
  652 root       4992 S   dsld -i -n
  665 root            RWN [kdsld_token]
  670 root       8236 S   telefon a127.0.0.1
  672 root       1420 S   telnetd -l /sbin/ar7login
  678 root       8432 S < voipd
  681 root       4076 S   pbd
  685 root       8236 S   telefon a127.0.0.1
  686 root       8236 S   telefon a127.0.0.1
  687 root       8236 S   telefon a127.0.0.1
  689 root       4076 S   pbd
  692 root       4076 S   pbd
  693 root       4076 S   pbd
  709 root        960 S   /bin/run_clock -c /dev/tffs -d
  736 root       4160 S   /usr/bin/faxd -a
  750 root       2112 S   capiotcp_server -p5031 -m99
  763 root       5196 S   igdd
  764 root       5196 S   igdd
  765 root       5196 S   igdd
  774 root       1420 S   httpd -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r Fr
  816 root       1624 S N /usr/bin/ntfs-3g /dev/sda1 /var/media/ftp/uStor01 -o
  852 root       8236 S   telefon a127.0.0.1
  854 root       8236 S   telefon a127.0.0.1
  855 root       8236 S   telefon a127.0.0.1
  993 root       3132 S N smbd
 1043 root       1540 S   /bin/ash /usr/sbin/callmonitor
 1044 root       1420 S   logger -t callmonitor -p daemon.info
 1082 root       1540 S   /bin/ash /usr/sbin/callmonitor
 1083 root       1416 S   busybox nc 127.0.0.1 1012
 1084 root       1540 S   /bin/ash /usr/sbin/callmonitor
 1085 root       1412 S   sleep 20000d
 1189 ntp         768 S   ntpd -s -f /mod/etc/ntpd.conf
 1191 root        756 S   ntpd -s -f /mod/etc/ntpd.conf
 1220 root       1420 S   init
 2271 root        868 S   dnsmasq --resolv-file=/var/tmp/avm-resolv.conf -p 53
 2277 root       4004 S   multid
 3656 root       2076 S   wpa_authenticator
 3678 root       1440 S   -sh

Zum Routing: - Ich habe da eine Zeile ala

91.66.134.0     0.0.0.0         255.255.254.0   U     2      0        0 dsl

drin. - Gut, bei mir läuft die 7170 als NAT-Router mit einem vorgeschalteten Kabelmodem. - Somit erscheint mir das soweit schon logisch.

Grüße
smileyman

 

[ao]

Danke für Deinen Tipp!

Ich habe dieselbe Konstellation (FB 7170 via LAN1 an Kabelmodem von KD) und würde mir ggf. auch dnsmasq etc. einrichten, um auf /etc/hosts Einträge verzichten zu können.

 

[cwarlich]

Hallo smileyman,

danke für Deine Prozessliste. Aber dsld wird bei Dir nicht früher, sondern dnsmasq und multid werden bei der 7170 offensichtlich viel später gestartet als auf der 7270. Und das scheint wohl das Problem zu sein, denn es geht ja auch bei mir, wenn ich dnsmasq (und damit auch multid) über die Web-Oberflache neu starte.

Hier zum Vergleich meine vollständige Prozessliste nach dem Hochlauf:

/var/mod/root # ps
  PID  Uid        VSZ Stat Command
    1 root       1420 S   init
    2 root            SWN [ksoftirqd/0]
    3 root            SW  [watchdog/0]
    4 root            SW< [events/0]
    5 root            SW< [khelper]
    6 root            SW< [kthread]
   18 root            SW< [kblockd/0]
   32 root            SW  [pdflush]
   33 root            SW  [pdflush]
   34 root            SW< [kswapd0]
   35 root            SW< [aio/0]
   71 root            SW  [pm_info]
   75 root            SW< [CPMAC]
   79 root            SW  [mtdblockd]
  101 root            SW  [tffsd_mtd_0]
  283 root            SWN [jffs2_gcd_mtd5]
  307 root            SW< [capi_oslib]
  308 root            SW< [capi_oslib]
  309 root            SW  [capitransp]
  319 root            RW  [avm_dect_thread]
  336 root            SW< [khubd]
  423 root      10512 S N /usr/bin/avm/ctlmgr
  510 root      10512 S N /usr/bin/avm/ctlmgr
  512 root      10512 S N /usr/bin/avm/ctlmgr
  514 root      10512 S N /usr/bin/avm/ctlmgr
  599 root       4480 S   hostapd -B /var/tmp/hostapd.conf
  603 root       3828 S   usermand
  608 root       4960 S   igdd
  637 root        860 S   dnsmasq -S 192.168.178.1 -p 53 -E -s fritz.box
  640 root       3996 S   multid
  656 root       4984 S   dsld -i -n
  661 root            RWN [kdsld_token]
  669 root       8540 S   telefon a127.0.0.1
  673 root       7748 S < voipd
  678 root       4068 S   pbd
  679 root       4068 S   pbd
  684 root       4068 S   pbd
  685 root       3184 S   dect_manager
  686 root       4068 S   pbd
  689 root        960 S   /bin/run_clock -c /dev/tffs -d
  740 root       1416 S   httpd -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r Freetz (user:admi
  777 root       1140 S   dropbear -p 22
  788 root       1420 S   init
  789 root       4960 S   igdd
  790 root       4960 S   igdd
  791 root       4960 S   igdd
  792 root       1196 S   dropbear -p 22
  793 root       1440 S   -sh
  827 root       1420 R   ps

Ansonsten referenziere ich mit -S 192.168.178.1 den Upstream DNS Server direkt anstatt über die resolv.conf, finde ich sicherer und transparenter, zumal die Datei /var/tmp/avm-resolv.conf trotz richtigem Eintrag im Fritz!Box Webinterface (Internet/primärer und sekundarer DNS Server: 192.168.178.1) immer noch die blödsinnigen Defaultwerte

nameserver 192.168.180.1
nameserver 192.168.180.2

enthält.

Ich versuche gerade, den Firmware-Build so hinzupatchen, dass dnsmasq und multid auch erst ganz am Ende gestartet werden und hoffe, damit das Problem in den Griff zu bekommen.

Gruß,

Christof

 

[matze1985]

das ist zwar keine lösung des problems, aber für die zwischenzeit eine behebung der Auswirkung:
Starte den dnsmasq doch einfach in der debug.cfg oder rc.custom beim systemstart neu.