hostname an FB übertragen

[RalfFriedl]

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.

Warum es so ist, kann ich zwar nicht sagen, aber noch einige Details dazu, wie es ist:
Das NAT der Box wird wie schon erwähnt nicht vom Linux System umgesetzt, sondern vom dsld. Die Default route zeigt auf das Interface dsl, unanhängig davon, ob daran wirklich das DSL-Modem hängt oder Internet über LAN1.

Die Adressen 192.168.180.1 und 192.168.180.2 sind in /etc/resolv.conf als Nameserver eingetragen. Diese beiden speziellen Adressen werden an die externen Nameserver weitergeleitet, vermutlich auch vom dsld.

Durchaus eine seltsame Konstruktion, deren Gründe vermutlich nur bei AVM bekannt sind.

 

[cwarlich]

@Matze: Gute Idee mit der debug.cfg, ich habe dort jetzt

/etc/init.d/rc.dnsmasq stop;
/etc/init.d/rc.dnsmasq start;

eingetragen, und jetzt geht der interne DNS Lookup direkt nach dem Booten. Bin also erstmal glücklich und zufrieden .

@Ralf: Danke für die Details, ich habe mir fast schon so was gedacht. Brr, da bekommt man fast Lust, basiernd auf Freetz ein "FritzBox from scratch" Projekt zu starten ;-).

@All: Da ich noch ziemlich grün bzgl. Freetz bin: Soll ich jetzt einen Bug-Report in Trac schreiben? Mir reicht zwar die Lösung mit der debug.cfg, aber der nächste wird bestimmt wieder über das gleiche Problem stolpern ....

Gruß,

Christof

 

[olistudent]

Kannst du nochmal genau aufschreiben wie ich die Box konfigurieren muss um deinen Fall nachzustellen?
Deiner Meinung nach wäre dies Lösung des Problems den dnsmasq nach dem dsld zu starten?
dnsmasq wird übrigens mit einem Wrapper Skript vor dem multid gestartet. Dafür ist in patches/$boxname jeweils ein Patch mit dem Namen 100-rc.S-dnsmasq.patch.

--- etc/init.d/rc.net.orig 2007-11-01 18:01:07.000000000 +0100
+++ etc/init.d/rc.net 2007-11-05 23:52:06.000000000 +0100
@@ -7,6 +7,11 @@
 
 PATH=/bin:/usr/bin:/sbin:/usr/sbin
 
+# allow wrapper
+PKG=dnsmasq
+BASE=/mod/pkg/$PKG
+PATH=$BASE/usr/lib/$PKG/bin:$PATH
+
 case "`uname -r`" in
   2.6* ) KERNEL_26=yes; ;;
   *    ) KERNEL_26=no; ;;

Der Rest sollte in make/dnsmasq/files/root zu finden sein.

MfG Oliver

edit: Da fällt mir gerade noch was ein. Was ist denn mit dem mutlid wait patch? Sollte der sowas nicht verhindern?

 

[cwarlich]

Kannst du nochmal genau aufschreiben wie ich die Box konfigurieren muss um deinen Fall nachzustellen?

Die FB ist als NAT-Router konfiguriert (WAN über LAN1). Außerdem läuft

dnsmasq -S 192.168.178.1 -p 53 -E -s fritz.box

(-S 192.168.178.1 im Web-Interface unter Optionen eingetragen, damit dnsmasq den Upstream Server findet). LAN ist 192.168.0.0/24. Client-PC hat IP (192.168.0.95) über DHCP bekommen. Er schickt seinen Hostnamen (option host-name = scooter) beim DHCP request an dnsmasq. Aber DNS Lookup auf scooter schlägt fehl, z.B.

ping scooter

von FB geht nicht.

Ein

/etc/init.d/rc.dnsmasq stop;
/etc/init.d/rc.dnsmasq start;

mauell oder per debug.cfg behebt das Problen, d.h. scooter wird nun aufgelöst.

Deiner Meinung nach wäre dies Lösung des Problems den dnsmasq nach dem dsld zu starten?

Da lag ich wohl falsch: Auch mit abgeschossenem dsld funktioniert der interne DNS Lookup, sobald man dnsmasq wie oben beschrieben neu startet. dsld kann also nichts damit zu tun haben.

dnsmasq wird übrigens mit einem Wrapper Skript vor dem multid gestartet. Dafür ist in patches/$boxname jeweils ein Patch mit dem Namen 100-rc.S-dnsmasq.patch.

--- etc/init.d/rc.net.orig 2007-11-01 18:01:07.000000000 +0100
+++ etc/init.d/rc.net 2007-11-05 23:52:06.000000000 +0100
@@ -7,6 +7,11 @@
 
 PATH=/bin:/usr/bin:/sbin:/usr/sbin
 
+# allow wrapper
+PKG=dnsmasq
+BASE=/mod/pkg/$PKG
+PATH=$BASE/usr/lib/$PKG/bin:$PATH
+
 case "`uname -r`" in
   2.6* ) KERNEL_26=yes; ;;
   *    ) KERNEL_26=no; ;;

Der Rest sollte in make/dnsmasq/files/root zu finden sein.

MfG Oliver

edit: Da fällt mir gerade noch was ein. Was ist denn mit dem mutlid wait patch? Sollte der sowas nicht verhindern?

Hmm - warum wird dnsmasq nicht nach dem multid gestartet? Soweit wie ich obigen Thread verstanden habe, sorgt multid doch scheinbar für die Konfiguration der Interfaces, oder? Da kann es doch nicht gut sein, dnsmasq vorher zu starten?!

 

[Silent-Tears]

Hmm - warum wird dnsmasq nicht nach dem multid gestartet? Soweit wie ich obigen Thread verstanden habe, sorgt multid doch scheinbar für die Konfiguration der Interfaces, oder? Da kann es doch nicht gut sein, dnsmasq vorher zu starten?!

Weil sonst der multid die Services des dnsmasq übernimmt und der dnsmasq vollkommen sinnfrei startet.

 

[cwarlich]

Weil sonst der multid die Services des dnsmasq übernimmt und der dnsmasq vollkommen sinnfrei startet.

Das hört sich dann aber nach Henne - Ei Problem an:

1. dnsmasq muß vor multid laufen, damit der DNS Port nicht von multid belegt wird
2. dnsmasq muß nach multid laufen, damit die Interfaces konfiguriert sind

Damit wäre das Stoppen und Starten von dnsmasq beim Booten unvermeidlich - es sei denn, man findet einen anderen Weg, multid von Port 53 bzw. seiner DNS-Tätigkeit fernzuhalten. Wenn es keinen schöneren Weg gibt, würde ich so was wie den folgenden Patch vorschlagen:

--- etc/init.d/rc.net	2008-06-10 18:08:22.000000000 +0200
+++ etc/init.d/rc.net.mod	2008-06-10 18:25:22.000000000 +0200
@@ -284,6 +284,8 @@
 
    igddstart
    multidstart
+   /etc/init.d/rc.dnsmasq stop
+   /etc/init.d/rc.dnsmasq start
 
    if [ "$CONFIG_DSL" ] ; then
      if [ "`pidof dsld`" = "" ] ; then

Ich habe den Patch mal unter

patches/7270/500-dnsmasq-stop-start.patch

abgelegt und probier's mal aus. Sollte gehen, denn genau das hat ja auch in der debug.cfg geholfen, und wenn wir keinen eleganteren Weg finden, ist der doch gut genug, oder?

Bis gleich,

Christof

 

[cwarlich]

Mit dem Patch geht es, ich war erst nur verwirrt, weil dnsmasq immer noch vor multid in der Prozessliste steht.

@Oliver: Meinst Du, das dass so ein akzeptabler Workaround ist, den man ins ofizielle Image aufnehmen kann?

 

[olistudent]

Sowas ist natürlich kein akzeptabler Workaround. Dabei müssen 2 Daemons erst gestoppt und anschließend wieder gestartet werden.

MfG Oliver

 

[cwarlich]

Dann lass mich wissen, wenn Du noch irgendwelchen Input für eine entgültige Lösung brauchst. Ich kann mit dem Workaround erstmal gut leben .

 

[olistudent]

Hi.
Das sind so viele Einstellungen. Ich bekomm das so nicht nachgebaut. Und in einem ersten Test konnte ich das bei mir auch nicht nachvollziehen. Wobei meine PCs eine "statische" IP vom dnsmasq zugewiesen bekommen. Deshalb stehen die auch in der /etc/hosts.

MfG Oliver

 

[cwarlich]

Hi Oliver,

ja, wenn der Client-PC in der /etc/hosts eingetragen ist geht der DNS Lookup auch ohne Patch. Die Probleme gibt es nur dann, wenn der Hostname beim DHCP Request an die FB übermittelt wird. Das kann man unter Debian/Ubuntu z.B. mit dem Paket dhcp3-client, indem man z.b. die Zeile

send host-name "scooter";

in die Datei /etc/dhcp3/dhclient.conf einträgt.

Danach ein reboot, oder schneller:

killall dhclient
ifconfig eth0 down #zur Sicherheit
dhclient eth0

Durch den erneuten DHCP Request wird jetzt der Hostname an die FB geschickt. Die FB (bzw. dnsmasq) sollte scooter jetzt also kennen, ein

ping scooter

müsste damit von jeden Client-PC und insbesondere von der FB möglich sein. Aber leider Fehlanzeige. Sobald man aber mit

/etc/init.d/rc.dnsmasq stop
/etc/init.d/rc.dnsmasq start

dnsmasq (und damit auch den multid) neu startet und dann die oben beschriebene Prozedur (reboot des Client-PCs oder dhclient neu starten) wiederholt, ist scooter der FB plötzlich bekannt und der

ping scooter

geht.

Finde ich halt viel schicker, anstatt alle Hostnamen auf der FB (in der /etc/hosts) und auf den Clients konzistent zu halten. Ausserden braucht man so zumindest bei Windows und bei SuSE nicht einmal mehr auf Client-Seite etwas zu tun, da die Betriebssysteme den Hostnamen beim DHCP Request schon standandmäßig mitschicken . Damit ist _jeder_ neue PC, der vom der FB über dnsmasq eine IP bekommt, sofort im ganzen lokalen Netz unter seinem Namen bekannt.

Gruß,

Christof