[INFO] opendd, ein DynDNS-Client

[sf3978]

... und eher schrotte ich die Fritzbox bei meinen Experimenten.

Die FritzBox kannst Du nicht schrotten, denn das Ganze machst Du ja in deinem Buildsystem (make opendd-precompiled) und ein neues (anderes) Freetz-Image musst Du auch nicht flashen, denn es reicht ja wenn Du das funktionierende opendd-binary in einen rw-Bereich der FritzBox (evtl. auch USB-Stick mit z. B. ext3-Dateisystem) kopierst und mit Hilfe der rc.custom-Datei startest.

... werde vielleicht die Jungs von Freetz fragen ob die den Daemon als Option einbauen können.
Soll ich auf dein Patch hinweisen?

Ja, diese Option für opendd als daemon wäre gut. Für diese Option wird der Patch aber nicht zwingend benötigt. Es gibt aber auch einen ähnlichen Patch im Ticket 818 (siehe: http://freetz.org/attachment/ticket/818/opendd_no_border_stun_static.patch) mit hardcodierten stun-server, der aber evtl. mit dem aktuellen Freetz-trunk nicht mehr funktioniert.

 

[jocale]

Habe opendd so kompiliert wie du beschrieben hast und vom USB-Stick gestartet und Daemon läuft, aber er findet das Ipfile nicht.

Jan  1 01:01:32 fritz kern.warn kernel: [   92.060000] [0]system-load 100 % loadavg 5.24 1.69 0.59 - 80 tasks:61 % curr:opendd(3 %) max:mediasrv(10 %, pid:2606), readytorun: 7, pgfault 2864/s (max 6 avg 1.4)
Jan  1 01:01:32 fritz daemon.info opendd[3222]: -- running OpenDD 0.7.9 as daemon
Jan  1 01:01:32 fritz daemon.err opendd[3222]: dyndns() : Can't read external IP file!
Jan  1 01:01:35 fritz user.notice ONLINECHANGED[2186]: [online] executing /etc/onlinechanged/20-opendd
Jan  1 01:01:36 fritz user.notice ONLINECHANGED[2186]: [online]  * Running OpenDD ... already running.

Ich habe es in die rc.custom eingetragen und manuell über Telnet versucht und vorher opendd mit Killall beendet, es bleibt bei dem fehlenden Ipfile.

 

[sf3978]

Habe opendd so kompiliert wie du beschrieben hast ...

Das musst Du schon etwas genauer beschreiben.

EDIT:

BTW: Wenn die stun-Server im opendd-binary hardcodiert sind, dann brauchst Du nicht das ipfile. Wenn das opendd-binary das ipfile braucht, dann kannst Du das mit der rc.custom vergessen.

 

[jocale]

Ich habe im Ordner von Freetz-devel

make opendd-precompiled

Ausgeführt und dann die kompilierte opendd auf ein USB-Stick kopiert und dort eine opendd.conf mit den passenden Parameter angelegt.
Ich habe es auch einmal mit deinen Patch gepacht und dann im Buildsystem kompiliert.
Beide Versionen starten den Daemon, aber finden den Ipfile nicht.

##do not change
cert_path = /tmp/flash/opendd/opendd.pem
runasdaemon = 1
pollfrequency = 300
pidfile_path = /var/run/opendd.pid
use_syslog = 1

##accounts
servername = update.spdns.de
hostname = ip.firewall-gateway.com
username = ip
password = ezihf

##advanced
wildcard = 0
backupmx = 0
offline = 0

##depends on make!
use_ssl = 0

Eingetragen habe ich es in die rc.custom

/var/media/ftp/U1GB/opendd/opendd   -c /var/media/ftp/U1GB/opendd/opendd.conf

 

[sf3978]

Ich habe es auch einmal mit deinen Patch gepacht und dann im Buildsystem kompiliert.

Mit welchem Patch? Hattest Du die stun-Server in diesem opendd-binary?

 

[jocale]

Den du mir am Anfang für Kubuntu gegeben hast.

Den hier
http://freetz.org/attachment/ticket/818/opendd_no_border_stun_static.patch
Habe ich auf mein Buildsystem angewendet, Image erzeugt und geflasht, danach musste ich die Box recorvern.

P.S.Geht übrigens unter Linux viel besser als unter Windows ohne lästiges Reboot

 

[sf3978]

Den du mir am Anfang für Kubuntu gegeben hast.

Ich habe doch geschrieben, dass Du diesen Patch nicht für Freetz benutzen kannst.

Den hier
http://freetz.org/attachment/ticket/818/opendd_no_border_stun_static.patch
Habe ich auf mein Buildsystem angewendet, Image erzeugt und geflasht, danach musste ich die Box recorvern.

Zu diesem Patch habe ich geschrieben, dass Du nur das binary kompilieren bzw. auf die Box kopieren sollst und kein Freetz-Image flashen sollst.

 

[jocale]

1. War nur ein Versuch

2. Patch, muss ich überlesen haben, sorry

Fritzbox läuft aber wieder

Habe eben den Patch aus dem Link angewendet , kompiliert und auf den Stick gepackt, läuft auch nicht.

Dec 30 00:44:53 fritz daemon.err openddpf[6567]: dyndns() : Can't read external IP file!

Gute Nacht und danke

 

[sf3978]

Habe eben den Patch aus dem Link angewendet , kompiliert und auf den Stick gepackt, läuft auch nicht.

Dec 30 00:44:53 fritz daemon.err openddpf[6567]: dyndns() : Can't read external IP file!

Hast Du vor dem Anwenden des Patches aus dem Link, im Build-System das opendd-Package bzw. opendd-Reste gelöscht? Dieser Patch soll ein neues opendd-Package erstellen. Aus welchem Verzeichnis deines Build-Systems hast Du diesen Patch ausgeführt? Wie waren die Ausgaben von:

patch -p0 < opendd_no_border_stun_static.patch

? Wie sind im make-Verzeichnis deines Build-Systems, die Ausgaben von:

ls -la | grep -i opendd
ls -la opendd

? Wie ist vom kompilierten opendd-binary, die Ausgabe von:

strings opendd | grep -i ekiga

?

 

[jocale]

ja, ich habe vorher den alten Sourcecode in
"/pfad/freetz-devel/source/target-mips_gcc-4.8.4_uClibc-0.9.33.2-nptl/opendd"
gelöscht und dann opendd.0.7.9.tar.gz dort entpackt

cd /pfad/freetz-devel/source/target-mips_gcc-4.8.4_uClibc-0.9.33.2-nptl/opendd
 patch -p0 </pfad/opendd_no_border_stun_hardcoded.patch 

 patching file extip.h
patching file include/sendmail.c
patching file include/setproctitle.c
patching file include/setproctitle.h
patching file include/strlcat.c
patching file include/strlcpy.c
patching file include/util.c
patching file Makefile
patching file opendd.c
patching file opendd.h

 ls -la | grep opendd
-rwxr-xr-x  1 jo jo 110677 Dez 30 10:39 opendd
-rw-r--r--  1 jo jo  46552 Dez 30 10:39 opendd.c
-rw-r--r--  1 jo jo   2057 Nov 16  2006 opendd.conf
-rw-r--r--  1 jo jo   1910 Dez 30 10:39 opendd.h
-rw-r--r--  1 jo jo  34392 Dez 30 10:39 opendd.o
-rw-r--r--  1 jo jo   3538 Okt 29  2005 opendd.pem

ls -la opendd
-rwxr-xr-x 1 jo jo 110677 Dez 30 10:39 opendd

strings ./opendd | grep ekiga
nichts

 

[sf3978]

j

 patch -p0 < /pfad/[color=red]opendd_no_border_stun_hardcoded[/color].patch 
patching file extip.h
patching file include/sendmail.c
patching file include/setproctitle.c
patching file include/setproctitle.h
patching file include/strlcat.c
patching file include/strlcpy.c
patching file include/util.c
patching file Makefile
patching file opendd.c
patching file opendd.h

Das ist aber nicht der Patch (opendd_no_border_stun_static.patch) aus dem Link. Du hast geschrieben:

Habe eben den Patch aus dem Link angewendet ...

 

[jocale]

Ja, diese Option für opendd als daemon wäre gut. Für diese Option wird der Patch aber nicht zwingend benötigt. Es gibt aber auch einen ähnlichen Patch im Ticket 818 (siehe: http://freetz.org/attachment/ticket/818/opendd_no_border_stun_static.patch) mit hardcodierten stun-server, der aber evtl. mit dem aktuellen Freetz-trunk nicht mehr funktioniert.

Genau diesen habe ich benutzt, am Ende der Seite war ein Downloadlink und von da habe ich es runtergeladen.

Die Freetz Hompage ist momentan nicht erreichbar, daher kann ich Moment nicht nochmal dort nachschauen.

_________________________________

Aber warum nicht ein Contrab Eintrag, ich habe mal in Contrab folgenden Code eingetragen und funktioniert seit Gestern super.

*/10 * * * * /etc/init.d/rc.opendd run > /dev/null 2>&1

Ausgabe nachdem ausführen

Dec 30 18:40:01 fritz cron.info crond[5012]: crond: USER root pid 5404 cmd /etc/init.d/rc.opendd run > /dev/null 2>&1
Dec 30 18:40:02 fritz daemon.info opendd[5423]: -- running OpenDD 0.7.9 in normal mode
Dec 30 18:40:02 fritz daemon.info opendd[5423]: main() : getting my ip address : 79.242.81.152
Dec 30 18:40:02 fritz daemon.info opendd[5423]: getdyndnshostnames() : no need to update meinehompage.firewall-gateway.com with 79.242.81.152
Dec 30 18:40:02 fritz daemon.err opendd[5423]: main() : No hostname(s) to update

Was spricht dagegen?

Onlinechanged führt ja auch

/etc/init.d/rc.opendd run

aus und nicht

opendd -c /var/mod/etc/opendd.conf

 

[sf3978]

Was spricht dagegen?

Nichts spricht dagegen. War so nicht vorgesehen, aber wenn es so funktioniert ist es ok.

 

[jocale]

OK, dann werde ich es so nutzen und für mich ist das Problem gelöst.

Danke nochmals für deine freundliche und ausdauernde Hilfe, habe dadurch viel dazu gelernt.

Noch eine letzte Frage, wie sieht es mit dem Ressourcenverbrauch von crond aus in der Fritzbox?

Und wäre ein opendd Daemon sparsamer, aber der läuft doch auch über crond oder?

 

[sf3978]

Und wäre ein opendd Daemon sparsamer, aber der läuft doch auch über crond oder?

Da wird kein großer Unterschied sein. Je nach Konfiguration kann opendd aus Freetz, auch cron benutzen:

cron)
		[ "$OPENDD_ENABLED" != "yes" ] && return
		logger -t info Run OpenDD by cron.
 		run
		;;

 

[jocale]

Das habe ich auch schon entdeckt und deswegen habe ich es mit dem cron Job versucht, OK danke nochmal.

 

[jocale]

Mittlerweile läuft opendd mit dem Crontab Job ohne Probleme, aber mit aktiven SSL in opendd gibt es nur Fehlermeldungen, also habe ich mich auf die Suche gemacht.

Die Datei mit dem Schlüssel liegt in

/etc/default.opendd/opendd.pem

So wie ich es verstehe sollte diese Datei nach

/var/tmp/flash/opendd/opendd.pem

kopiert werden beim ausführen von opendd, denn das Textfeld unter

Freetz > opendd > opendd.pem

ist leer und in der

/etc/init.d/rc.opendd

ist der Pfad zur opendd.pem ein anderer

mkdir -p /tmp/flash/opendd
[ ! -e /tmp/flash/opendd/opendd.pem ] && touch /tmp/flash/opendd/opendd.pem

modreg cgi 'opendd' 'OpenDD'
modreg file opendd opendd_pem 'opendd.pem' 0 "opendd_pem"
modreg daemon --hide opendd

Also habe ich die opendd.pem manuell kopiert

cat /etc/default.opendd/opendd.pem >/var/tmp/flash/opendd/opendd.pem

und schon geht prompt der Dyndns Update auch über SSL und im Textfeld von opendd.pem in Freetz ist auch der entsprechende Schlüssel drin.

#
# opendd.pem
# 
# CA Root Certificate used by DynDNS
#
# The content of this file has been grabbed from the following
# URL: http://curl.haxx.se/docs/caextract.html
# 
# From this URL, you can find 
# a bundle of X.509 certificates of public Certificate Authorities 
#
# For OpenDD, only the Equifax trust certificate is needed
#

Equifax Secure Global eBusiness CA
==================================

MD5 Fingerprint=8F:5D:77:06:27:C4:98:3C:5B:93:78:E7:D7:7D:9B:CC
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
        Validity
            Not Before: Jun 21 04:00:00 1999 GMT
            Not After : Jun 21 04:00:00 2020 GMT
        Subject: C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ba:e7:17:90:02:65:b1:34:55:3c:49:c2:51:d5:
                    df:a7:d1:37:8f:d1:e7:81:73:41:52:60:9b:9d:a1:
                    17:26:78:ad:c7:b1:e8:26:94:32:b5:de:33:8d:3a:
                    2f:db:f2:9a:7a:5a:73:98:a3:5c:e9:fb:8a:73:1b:
                    5c:e7:c3:bf:80:6c:cd:a9:f4:d6:2b:c0:f7:f9:99:
                    aa:63:a2:b1:47:02:0f:d4:e4:51:3a:12:3c:6c:8a:
                    5a:54:84:70:db:c1:c5:90:cf:72:45:cb:a8:59:c0:
                    cd:33:9d:3f:a3:96:eb:85:33:21:1c:3e:1e:3e:60:
                    6e:76:9c:67:85:c5:c8:c3:61
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type: 
                SSL CA, S/MIME CA, Object Signing CA
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier: 
                keyid:BE:A8:A0:74:72:50:6B:44:B7:C9:23:D8:FB:A8:FF:B3:57:6B:68:6C

            X509v3 Subject Key Identifier: 
                BE:A8:A0:74:72:50:6B:44:B7:C9:23:D8:FB:A8:FF:B3:57:6B:68:6C
    Signature Algorithm: md5WithRSAEncryption
        30:e2:01:51:aa:c7:ea:5f:da:b9:d0:65:0f:30:d6:3e:da:0d:
        14:49:6e:91:93:27:14:31:ef:c4:f7:2d:45:f8:ec:c7:bf:a2:
        41:0d:23:b4:92:f9:19:00:67:bd:01:af:cd:e0:71:fc:5a:cf:
        64:c4:e0:96:98:d0:a3:40:e2:01:8a:ef:27:07:f1:65:01:8a:
        44:2d:06:65:75:52:c0:86:10:20:21:5f:6c:6b:0f:6c:ae:09:
        1c:af:f2:a2:18:34:c4:75:a4:73:1c:f1:8d:dc:ef:ad:f9:b3:
        76:b4:92:bf:dc:95:10:1e:be:cb:c8:3b:5a:84:60:19:56:94:
        a9:55
-----BEGIN CERTIFICATE-----
MIICkDCCAfmgAwIBAgIBATANBgkqhkiG9w0BAQQFADBaMQswCQYDVQQGEwJVUzEc
MBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEtMCsGA1UEAxMkRXF1aWZheCBT
ZWN1cmUgR2xvYmFsIGVCdXNpbmVzcyBDQS0xMB4XDTk5MDYyMTA0MDAwMFoXDTIw
MDYyMTA0MDAwMFowWjELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlmYXggU2Vj
dXJlIEluYy4xLTArBgNVBAMTJEVxdWlmYXggU2VjdXJlIEdsb2JhbCBlQnVzaW5l
c3MgQ0EtMTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuucXkAJlsTRVPEnC
UdXfp9E3j9HngXNBUmCbnaEXJnitx7HoJpQytd4zjTov2/KaelpzmKNc6fuKcxtc
58O/gGzNqfTWK8D3+ZmqY6KxRwIP1ORROhI8bIpaVIRw28HFkM9yRcuoWcDNM50/
o5brhTMhHD4ePmBudpxnhcXIw2ECAwEAAaNmMGQwEQYJYIZIAYb4QgEBBAQDAgAH
MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUvqigdHJQa0S3ySPY+6j/s1dr
aGwwHQYDVR0OBBYEFL6ooHRyUGtEt8kj2Puo/7NXa2hsMA0GCSqGSIb3DQEBBAUA
A4GBADDiAVGqx+pf2rnQZQ8w1j7aDRRJbpGTJxQx78T3LUX47Me/okENI7SS+RkA
Z70Br83gcfxaz2TE4JaY0KNA4gGK7ycH8WUBikQtBmV1UsCGECAhX2xrD2yuCRyv
8qIYNMR1pHMc8Y3c7635s3a0kr/clRAevsvIO1qEYBlWlKlV
-----END CERTIFICATE-----

Ich will mir jetzt nicht anmassen ein Fehler im opendd Paket gefunden zu haben, aber nach meinen bescheidenen Kenntnisse sieht danach aus.

Ich habe mich damit beholfen und unter onlinechanged der entsprechenden Eintrag eingefügt.

case $1 in
 start)
   cat /etc/default.opendd/opendd.pem >/var/tmp/flash/opendd/opendd.pem
   # Kommandos beim Start des Routers
   # ggf. sollten hier die Einträge von online) stehen
   ;;
 online)

Nun die Frage an die Experten hier soll ich den Pfad in der

/etc/init.d/rc.opendd

anpassen oder den Befehl in der onlinechanged?

 

[sf3978]

... ein Fehler im opendd Paket gefunden zu haben, aber nach meinen bescheidenen Kenntnisse sieht danach aus.

Das kann man so nicht erkennen, denn Du verwendest das opendd-Paket aus Freetz, in modifizierter Form.

Nun die Frage an die Experten hier soll ich den Pfad in der

/etc/init.d/rc.opendd

anpassen oder den Befehl in der onlinechanged?

Mach es so wie es für deinen Anwendungsfall gut bzw. geeignet ist.

 

[jocale]

Ich meine ja nicht das der Fehler eigentlich in opendd liegt, sondern an der Umsetzung/Anpassung von opendd in Freetz.

 

[sf3978]

..., sondern an der Umsetzung/Anpassung von opendd in Freetz.

Das könnte man feststellen, wenn man ein Freetz-Image mit dem nicht modifizierten opendd-Paket auf die FritzBox flasht und danach schaut wo auf der Box, sich die opendd.pem-Datei befindet.