[r3243] dnsmasq und WLAN-Probleme

[meilon]

Hallo!

Seit mir das Problem mit den "Permission denied" der resolv.conf, hosts und ethers aus /etc beim Laden von dnsmasq aufgefallen ist viel mir nun auch auf, das mein iPhone seit längerem sich nicht mehr in mein WLAN eingebucht hat. Zudem erhält der iPod touch keine IP, obwohl im syslog die ganzen DHCP-Meldungen von Discover bis Ack aufgeführt werden. Ich weiß nicht, wie das normalerweise aussehen muss, aber dass die Meldungen für das Interface lan aufgeführt werden, erscheint mir nicht normal.

Hier nochmal die Start-Meldung von dnsmasq

Apr  5 18:55:08 fritz daemon.info dnsmasq[2092]: started, version 2.47 cachesize 150
Apr  5 18:55:08 fritz daemon.info dnsmasq[2092]: compile time options: no-IPv6 GNU-getopt no-DBus no-I18N TFTP
Apr  5 18:55:08 fritz daemon.info dnsmasq[2092]: asynchronous logging enabled, queue limit is 10 messages
Apr  5 18:55:08 fritz daemon.info dnsmasq[2092]: DHCP, IP range 192.168.178.100 -- 192.168.178.200, lease time 12h
Apr  5 18:55:08 fritz daemon.warn dnsmasq[2092]: failed to access /etc/resolv.conf: Permission denied
Apr  5 18:55:08 fritz daemon.err dnsmasq[2092]: failed to load names from /etc/hosts: Permission denied
Apr  5 18:55:08 fritz daemon.err dnsmasq[2092]: failed to read /etc/ethers:Permission denied

Im Changelog konnte ich nicht herausfinden, was die Änderungen verursacht. Genauso wie die nötigen make $package-precompiled die bisher nicht nötig waren.

Jemand eine Idee?

Gruß
meilon

 

[Silent-Tears]

Existieren die Symlinks bei dir denn? Und wenn wohin zeigen sie und sind die Ziledateien vorhanden? Welche Rechte haben die?

ls -l /etc/hosts /etc/ethers

 

[olistudent]

Das könnte damit zusammenhängen, dass wir var.tar nicht mehr mit "--mode=0755" einpacken.
Wie ist das denn gedacht, wenn der dnsmasq als nobody läuft? Müssen dann auch alle die Datei lesen können?

MfG Oliver

 

[Silent-Tears]

Zumindest nobody. /etc/hosts hat normalerweise die Rechte 644 und dne Owner root, somit lesbar für nobody. Auf der Box übrtigens genauso mit r3242M

 

[meilon]

Habe eben ein Recover gemacht und neu geflasht, das hat schon mal nicht geholfen.

So sieht das auf meiner Box aus:

# ls -l /etc/hosts /etc/ethers
lrwxrwxrwx    1 root     root           17 Apr  5 18:28 /etc/ethers -> ../var/tmp/ethers
lrwxrwxrwx    1 root     root           16 Apr  5 18:28 /etc/hosts -> ../var/tmp/hosts

 

[sf3978]

Sind diese Links identisch, oder unterscheidet hier Freetz, und AVM evtl. nicht:

resolv.conf -> [B][COLOR="Red"]..[/COLOR][/B]/var/tmp/resolv.conf
resolv.conf -> /var/tmp/resolv.conf

Ich frage weil die Links, die über Freetz im Ordner /etc erstellt werden, so ausschauen:

hosts.allow -> /var/tmp/hosts.allow
hosts.deny -> /var/tmp/hosts.deny
inetd.conf -> /var/tmp/flash/inetd.conf

 

[Silent-Tears]

Du hast die verlinkten Dateien nicht gepostet. Also Rechte und Ownership

 

[sf3978]

/var/tmp

635 0 -rw-r--r-- 1 root root 0 Jan 1 2000 ethers
634 4 -rw-r--r-- 1 root root 54 Jan 1 2000 hosts
1566 4 -rw-r--r-- 1 root root 219 Jan 1 2000 hosts.allow
1565 4 -rw-r--r-- 1 root root 50 Jan 1 2000 hosts.deny
541 4 -rwxr-xr-x 1 root root 50 Jan 1 2000 resolv.conf

/etc

620 4 lrwxrwxrwx 1 root root 17 Apr 4 23:48 ethers -> ../var/tmp/ethers
551 4 lrwxrwxrwx 1 root root 16 Apr 4 23:47 hosts -> ../var/tmp/hosts
618 4 lrwxrwxrwx 1 root root 20 Apr 4 23:48 hosts.allow -> /var/tmp/hosts.allow
684 4 lrwxrwxrwx 1 root root 19 Apr 4 23:48 hosts.deny -> /var/tmp/hosts.deny
690 4 lrwxrwxrwx 1 root root 22 Apr 4 23:47 resolv.conf -> ../var/tmp/resolv.conf

 

[RalfFriedl]

Sind diese Links identisch, oder unterscheidet hier Freetz, und AVM evtl. nicht:

resolv.conf -> [B][COLOR="Red"]..[/COLOR][/B]/var/tmp/resolv.conf
resolv.conf -> /var/tmp/resolv.conf

Da der Link (wenn wir von /etc/resolv.conf sprechen) eine Ebene unter dem Hauptverzeichnis steht, macht das keinen Unterschied. Entweder aus /etc ein Verzeichnis zurück ins Hauptverzeichnis, und dann weiter, oder direkt im Hauptverzeichnis anfangen.

 

[sf3978]

OK, verstanden. Dann ist es nur eine andere Schreibweise für den Pfad der verlinkten Datei.

 

[meilon]

Sonst irgend einen Lösungsansatz, außer das es an dem var.tar Packvorgang liegen könnte?

 

[olistudent]

Die Frage ist warum dnsmasq die Dateien angeblich nicht mehr öffnen/lesen kann. Ohne Lesen und Nachschauen kann ich dir das jetzt auch nicht beantworten. Kannst ja auch mal schauen welche Rechte die Dateien in einem Desktop-Linux haben.

MfG Oliver

 

[RalfFriedl]

Sonst irgend einen Lösungsansatz, ...

Hast Du denn mittlerweile die Zugriffsrechte der Dateien kontrolliert? Wie oben schon geschrieben wurde, hast Du nur die Links angezeigt und nicht die Dateien selbst.

 

[sf3978]

In einem Desktop-Linux, haben die Dateien die von dnsmasq evtl. nicht gelesen werden können, folgende Rechte:

0 -rw-r--r-- 1 root root 0 Jan 1 2000 ethers
4 -rw-r--r-- 1 root root 54 Jan 1 2000 hosts
4 -rwxr-xr-x 1 root root 50 Jan 1 2000 resolv.conf

 

[Silent-Tears]

Folgendes Prozedere macht diesem Fehelr auch nciht:

Nagelneu ausgecheckter Trunk (absichtlich die r3243), vollkommen unmodifiziert, dazu eine recoverte Box. Gebaut mit dropbear und dnsmasq. Und dennoch schmeisst dnsmasq bie mir diese Fehlermeldungen nicht raus und funktioniert.

 

[RalfFriedl]

Bei mir läuft dnsmasq auch.
Die Frage ist also nicht, welche Rechte die Dateien auf einem normalen Linux-PC haben,sondern welche Rechte die Dateien (nicht die Links) auf der Box haben, wo es nicht läuft.

Übrigens ist es ungewöhnlich, daß die Datei resolv.conf Execute Rechte hat.

 

[Silent-Tears]

Es ist sowieso irrelevant, was die Symlinks für Rechte haben, denn es gilt immer noch das Recht des Files/Des Verzeichnisses, was dort verlinkt ist.
Mein natives Linux lässt auch keine Rechteänderungen eines Symlinks zu, sondern ändert schlicht die Rechte der/des verlinkten Datei/Verzeichnisses.

 

[meilon]

So sieht es bei mir aus:

/etc # ls -al /etc/resolv.conf /etc/hosts /etc/ethers
lrwxrwxrwx    1 root     root           17 Apr  5 18:28 /etc/ethers -> ../var/tmp/ethers
lrwxrwxrwx    1 root     root           16 Apr  5 18:28 /etc/hosts -> ../var/tmp/hosts
lrwxrwxrwx    1 root     root           22 Apr  5 18:28 /etc/resolv.conf -> ../var/tmp/resolv.conf
/etc # ls -al ../var/tmp/ethers ../var/tmp/hosts ../var/tmp/resolv.conf
-rw-r--r--    1 root     root          249 Jan  1  2000 ../var/tmp/ethers
-rw-r--r--    1 root     root          366 Jan  1  2000 ../var/tmp/hosts
-rw-r--r--    1 root     root           50 Apr  5 20:26 ../var/tmp/resolv.conf

 

[RalfFriedl]

Dann sollten die Rechte ausreichen. Scheint ein Fall für strace zu sein.

 

[meilon]

Hier der strace des Aufrufes von dnsmasq.

Zudem macht Callmonitor auch komische Sachen seit 3243 oder ein paar Releases davor:

Apr  7 18:16:45 fritz daemon.info callmonitor: Auto-dialing #96*5* to enable telefon's interface ...
Apr  7 18:16:46 fritz daemon.info callmonitor: Trying again in 1 seconds ...

Das kommt (wie es ja da steht) im Sekundenrhytmus und geht so lange, bis ich callmonitor beende. Telefonie via Fritz!Box nutze ich noch nicht, kommt aber demnächst.

Und das das WLAN sich die Geräte aussucht, mit denen es sich unterhält, ist auch verdammt nervig. Also irgendwas läuft da im aktuellen Trunk gewalltig anders als sonst.

Wann wurde das denn mit dem --mode für var.tar geändert? Könnte mir da jemand einen gegen-Patch für den aktuellen Trunk machen, um zu testen, ob die Probleme sich dadurch beheben lassen?

Grüße
meilon