ds26-15.2 mit 29.04.39/40

RalfFriedl · 18 Sep 2007

Von wo hast Du das? Ich habe den Text mit etwas Suche unter ftp://ftp.avm.de/fritz.box/license.txt gefunden.

Punkt 3 der Lizenz sagt aber:

3. All advertising materials mentioning features or use of this software must display the following acknowledgment:
"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

Das heißt also nicht irgendwo versteckt bei den Lizenzbedingungen, sondern überall in Werbematerialien, wo die Eigenschaften des Produkts genannt werden.

andreasz · 18 Sep 2007

aus der Info.txt des Images (Quelle : http://www.avm.de/files/fritz.box/fritzbox.fon_wlan_7170/firmware/deutsch/info.txt)

Code:

(ftp://ftp.avm.de/fritz.box/license.txt).
Der Source Code der als Open Source verbreiteten Dateien kann schriftlich 
angefordert werden über [email protected].

der Auszug aus meinem letzten Beitrag kommt aus der license.txt
(Quelle : ftp://ftp.avm.de/fritz.box/license.txt)

user31085 · 20 Sep 2007

und bei der neuen 40er firmware welche 130-rc.S-logging.patch einstellungen muss ich da vornehmen?

olistudent · 20 Sep 2007

Der Patch aus #7 tut bei mir immer noch.

MfG Oliver

wonderdoc · 20 Sep 2007

Hallo,

gibt es eigenlich schon was neues zu den Problem mit dnsmasq
in Verbindung mit der 7170 + 29.04.40 und ds26-15.2?

mfg
Wonderdoc

cuma · 20 Sep 2007

Das Problem ist doch, dass AVM keine Sourcen veröffentlicht hat und deshalb nicht entsprechen kompiliert werden kann. Aus dem gleichen Grund geht auch "Replace Kernel" nicht. Schreib doch mal an AVM ne eMail und frag wo's hängt (siehe Post #43)
Das sollten im übrigen alle mal machen, damit AVM voran macht!

wonderdoc · 20 Sep 2007

Hi,

dnsmasq benötig aber keinen Replace Kernel.
Problem ist doch, daß bei akt. dnsmasq sich die VoIP-Rufnummern wegen DNS-Fehler nicht registrieren können.
Die Firmware ohne DS-Mod oder mit deak. dnsmasq wird ja ordnungsgemäß gebaut(mit patch aus#7) und VoIP läuft.
Was soll AVM denn da machen.
Scheint doch eher ein dnsmasq Problem zu seien.

Im 1. Posting steht ja gerade(gerade gesehen), dass die Probleme untersucht werden.

mfg
Wonderdoc

olistudent · 20 Sep 2007

Wenn immer alles an mir hängen bleibt, dann müsst ihr halt warten bis ich Zeit und Lust hab, irgendwelche Probleme zu untersuchen.

Ergebnis: multid legt beim Start die Datei /var/tmp/avm-resolv.conf an. Das macht er nicht, wenn dnsmasq läuft. voipd fragt diese Datei ab, wenn er sie nicht findet dann kommt sowas bei rum:

Code:

sendto ... {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("[COLOR=red]1.0.0.127[/COLOR]")}, 16) = 37

Korrekt wäre:

Code:

sendto ... {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("[COLOR=red]127.0.0.1[/COLOR]")}, 16) = 37

oder

Code:

sendto ... {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("[COLOR=red]192.168.180.1[/COLOR]")}, 16) = 37

Sieht nach einem Programmierfehler seitens AVM aus, oder?
Das Problem kann also gelöst werden, indem /var/tmp/avm-resolv.conf vor dem Start vom voipd sinnvollen Inhalt hat.

Code:

/ $ cat /var/tmp/avm-resolv.conf
nameserver 192.168.180.1
nameserver 192.168.180.2

Vorschläge sind willkommen.

(Nein, in der debug.cfg ist es zu spät).

MfG Oliver

wonderdoc · 20 Sep 2007

Hi Oliver,

Ich muß zwar zugeben, daß ich von dem Startvorgang der FB keine Ahnung habe, aber vieleicht brings trotzdem etwas.
Bei mit wird der dnsmasq beim Boxstart automatisch geladen.
(Nutze noch 29.04.37 mit ds26-15.2)
Bei mir gibt es auf der Box unter /var/tmp/ eine Datei resolv.conf

/ $ cat /var/tmp/resolv.conf
nameserver 192.168.180.1
nameserver 192.168.180.2

Wer legt die Datei eigentlich an? AVM oder dnsmasq?

mfg
Wonderdoc

cuma · 20 Sep 2007

Das Problem müsste doch beim DHCP Client zu suchen sein, da dieser ja die DNS Server in die /var/tmp/avm-resolv.conf schreiben muss.
Was passiert denn, wenn man die Internetverbindung trennt und wieder aufbaut? Kommt dann ein echter DNS Server in die Datei?
Hab leider keine Ahnung wie ich das das selbst debuggen kann. Muss ich dazu einen seriellen Anschluss an die Box löten?

EDIT:
Übrigens enthalten die Dateien /etc/resolv.conf und /var/tmp/resolv.conf bei mir "nameserver 192.168.180.*" was unsinnig ist. Werden die Dateien überhaupt gebraucht?

olistudent · 21 Sep 2007

Nein, das passt schon so wie es ist. Die Dateien werden gebraucht, zumindest vom dnsmasq. mulitd beachtet die nicht, glaube ich.
Du brauchst auch nichts mehr debuggen. Wir müssen die Datei irgendwie selbst erstellen bzw. verlinken.

MfG Oliver

kriegaex · 21 Sep 2007

Evtl. könnte jemand dem AVM-Support schreiben, damit das kein Dauerzustand bleibt. Oliver?

Silent-Tears · 21 Sep 2007

Vielleicht ein dummer Gedanke, und meinerseits mangels Hardware und VoIP nicht verifizierbar, aber was passiert, wenn man der benötigten Adressen fix in die "/etc/hosts" einträgt? Die Reihenfolge der Namensauflösung ist laut /etc/host.conf ja nun

Code:

order hosts,bind

Somit würde eben genau die /etc/hosts zuerst abgefragt, und bei einem positiven Match gar kein DNS-Lookup mehr gemacht.

Ist nicht die ultimative Lösung, aber sollte zumindest als Workaround genutztz werden können, bis der Rest wieder so funktioniert, wie es soll.

LG

RalfFriedl · 21 Sep 2007

Ein Eintrag für localhost ist in der hosts schon vorhanden.
Das Problem scheint zu sein, daß der Default für den Nameserver falsch ist (Aufruf von htonl() vergessen).
Aus welchem Grund eine Datei /var/tmp/avm-resolv.conf sinnvoll ist, wenn es schon eine /etc/resolv.conf gibt, kann ich nicht nachvollziehen.
Die einfachste Lösung, die Datei rechtzeitig zu erstellen ist, sie in var.tar mit aufzunehmen. Eine Kopie von /var/tmp/resolv.conf sollte funktionieren. Oder mal 127.0.0.1 als Nameserver ausprobieren, sollte auch gehen.

Wegen GPL-Quellen habe ich am 18.09. an AVM geschrieben, bisher keinerlei Antwort.

derheimi · 21 Sep 2007

Sorry, ich seh gerade nicht, wo das Problem liegt. Die Startreihenfolge ist doch multid, später dann der voipd und irgendwann hinterher kommt eventuell dnsmasq. Das Init-Script von dnsmasq beendet aber den multid erst (der dabei vermutlich die avm-resolv.conf wieder löscht, oder?) damit er sich die Ports schnappen kann und startet den multid dann wieder. Dabei legt dieser die avm-resolv.conf aber nicht wieder an. Hab ich das richtig verstanden?

Dann sollte es doch eine mögliche Lösung sein, das Init-Script von dnsmasq so zu patchen, dass ein Link auf die /var/tmp/resolv.conf erstellt wird. Diese muss natürlich sinnvollen Inhalt enthalten, was zumindest auf meinen Boxen aber auch der Fall ist. Bei "nameserver 192.168.180.*" würde ich mal checken, was der Abschnitt "servercfg" der ar7.cfg enthält?!

Der Programmierpatzer seitens AVM wird damit natürlich nicht behoben, aber die Registrierung der VoIP-Nummern sollte wieder gehen.

Code:

--- rc.dnsmasq.orig     2007-07-09 08:21:44.000000000 +0200
+++ rc.dnsmasq  2007-09-21 10:09:26.000000000 +0200
@@ -46,6 +46,7 @@
        exitval=$?
        if [ "$1" != "nomultid" ]; then
                multid $MULTIDPARAM > /dev/null 2>&1
[b]+               ln -s resolv.conf /var/tmp/avm-resolv.conf[/b]
        fi

        if [ ! -L "/var/flash/multid.leases" -a \
@@ -67,6 +68,7 @@
        echo -n 'Stopping dnsmasq...'
        if [ "$1" != "nomultid" ]; then
                multid -s > /dev/null 2>&1
[b]+               rm /var/tmp/avm-resolv.conf[/b]
        fi
        killall $DAEMON > /dev/null 2>&1
        exitval=$?

Leider kann ich das gerade nicht am lebenden Objekt testen, meine Remote-Hands sind noch nicht wach

Update:
Dresdner Box mit diesem Patch online. VoIP-Registrierung damit ohne DNS-Fehler möglich. Läuft aber erst seit ca. 10min...

Krckstck · 22 Sep 2007

Nachdem ich das hier besprochene ausprobiert habe, musste ich eben zurück recovern. Ich hab mit dem Patch und der Veränderung im InitScript des Dnsmasq leider überhaupt keine Internetverbindung bekommen. DSL blieb ebenfalls getrennt.

Gruß
Thomas

derheimi · 22 Sep 2007

Sehr seltsam. Zumindest auf die DSL-Verbindung sollte obiger Patch keine Auswirkung haben.

Was mich aber noch mehr verwirrt: mit einer Originalen 39er oder 40er habe ich auch die DNS-Fehler, wenn die Box an ein Wimax-Modem angeschlossen wird (PPPoE via LAN 1). Die /var/tmp/resolv.conf enthält dabei "nameserver 127.0.0.1", die avm-resolv.conf ist angelegt und enthält ebenfalls "nameserver 127.0.0.1". Ich habe testhalber beide Dateien mit den Ip-Adressen von öffentlichen DNS-Servern gefüllt, was aber nichts bewirkt hat.

Eagle3386 · 23 Sep 2007

Ich hab aus deinem Patch oben (http://www.ip-phone-forum.de/showpost.php?p=944684&postcount=55) einfach nur die Zeile

Code:

ln -s resolv.conf /var/tmp/avm-resolv.conf

kopiert, auf der Box ausgeführt und dann im Web-Interface meine beiden SIP-Nummern aktiviert.

Ergebnis: alles läuft bestens und die Nummern wurden erfolgreich registriert!

Ganz vielen lieben Dank für diesen Patch bzw. Hinweis!

staubsauger-nono · 23 Sep 2007

OK, das hat wunderbar funktioniert, alle Nummern sind registriert.
Wie baue ich das jetzt in den ds-mod ein?
In welchem Verzeichnis muss der Link erstellt werden, bzw wie baue ich den Patch aus #55 ein.

[EDIT]
Asche auf mein Haupt

Richtige Datei gefunden und editiert.

Eagle3386 · 23 Sep 2007

Und? Infos für andere gibts nicht?

ds26-15.2 mit 29.04.39/40

IPPF-Urgestein

Neuer User

Mitglied

IPPF-Urgestein

Mitglied

Aktives Mitglied

Mitglied

IPPF-Urgestein

Mitglied

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

IPPF-Promi

IPPF-Urgestein

Mitglied

Neuer User

Mitglied

Neuer User

Aktives Mitglied

Neuer User

Statistik des Forums