DECT - Telefone verlieren Verbindung/Registrierung

Neue Firmware 7270_04.70freetz-devel.de_20090228-230019_Rev3115_AVMF_Dropbear_Matrixtunnel_OpenVPN_WoL_ohne-Freetz-Substring.image gebaut und auf der Box.
Registrierung des Telefons geht, Klingeltontest auch, aber bei externen Anrufen klingelt es nicht.
In der Prozeßliste taucht kein cat auf.
In dmesg steht als letzte Zeile "[avm_debug]redirect kernel-messages (/dev/debug)"
In der "/etc/init.d/rc.S" steht "cat /dev/debug &".
Die Konsole schreit lauter Meldungen raus, aber keine DECT Meldungen.

Und jetzt? Ich dachte, der Patch wäre für mein Problem verantwortlich. Scheint wohl nicht so? Was soll ich denn jetzt machen?


Was mich aber mehr stört, ist, dass ich in den Einstellungen zu den Zugangsdaten mit og Firmware Probleme habe (siehe Screenshot). Doof, dass ich dort nichts weiter einstellen kann. Naja, die Einstellungen samt Zugangsdaten hat sich die Box ja gemerkt.

Mal kurz zwischengefragt: Wenn ich mir die changeset_r3018.zip lade und entpacke, befindet sich darin ein Ordner Trunk und darin ein Unterordner root. Ich habe aber kein Verzeichnis trunk, es heißt eben anders (da ich mittlerweile mehrere Verzeichnisse zu versch. Rev. und Tags habe). Jetzt dachte ich mir, ich entpacke die Datei mit unzip und kopiere die Dateien und Ordner im Verzeichnis trunk (das aus dem Zip Archiv) einfach in den entsprechenden Trunk Ordner. Dabei bekomme ich aber immer die Meldung "cp: Verzeichnis â./rootâ ausgelassen". Ich habe das auch mittels sudo probiert (welches ich bei den ganzen Freetz Geschichten ja nicht brauche), das geht auch nicht. Besitzer vom root Ordner bin ich, Rechte passen auch. Warum geht das nicht? Wie kann ich solche changesets denn sonst einspielen? Ich habe ja auch kein patchfile, welches ist mittels patch Kommando nutzen kann. Und das diffile habe ich zwar vorliegen, damit kann ich aber auch nichts anfangen.
 
Kannst du intern telefonieren? Ich hatte da mal was wegen Firewall und VoIP gelesen
 
Die Zip-Archive würde ich nicht nutzten, da dort die Unix-Dateiatribute und Links verloren gehen, man sollte so auch nie ne komplette Version aus dem Trac ziehen, da diese auch als zip angeboten werden im Source-Browser.
Die Patches aus den changesets bekommst du, wenn du unten auf den Link "Unified Diff" klickst.

Du kannst aber auch einfach eine "svn up" machen.
 
Ich habe jetzt wieder 7270_04.67freetz-1.0.2.de_20090227-151658_AVMF_Dropbear_Matrixtunnel_OpenVPN_WoL_ohne-Freetz-Substring_ohne-180-PrintK-Patch.image (also die Freetz 1.0.2 mittels dirclean gesäubert, die Datei 180_PrintK.sh gelöscht, mit menuconfig alles eingerichtet)drauf. So funktioniert das Telefonieren wieder. Komplett, intern, extern, Klingeltontests.

---------------------------
/Offtopic
Darf ich nochmal was zu dem Diff und Patch Kram fragen? Ich suche jetzt schon ziemlich lange um herauszufinden, wie ich mit den diffiles umgehe. Ich habe da im Changeset ja nun ein changeset_r3018.diff runtergeladen. Ich habe verstanden, dass dieses difffile durch das Programm diff erzeugt wurde, indem es 2 versch. Dateien (in diesem Fall Textdateien) miteinander verglichen hat. Das geht wohl auch komfortabel mittels svn diff.
Ich habe auch verstanden, dass man Patches mit dem Programm patch erzeugen kann und vorhandene Patches einspielen kann.
Dazu habe ich im Wiki die folgenden beiden Seiten gefunden:
Patch integrieren
Patch erzeugen

Ich finde aber nirgendwo eine Anleitung, wie ich euer diff zu benutzen habe. Wenn ich patch -p0 < *.diff eingebe, bekomme ich
Code:
~/downloads/freetz/freetz-test/test/trunk$ patch -p0 < changeset_r3018.diff
(Stripping trailing CRs from patch.)
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: /trunk/root/usr/bin/webcfg
|===================================================================
|--- /trunk/root/usr/bin/webcfg (revision 2156)
|+++ /trunk/root/usr/bin/webcfg (revision 3018)
--------------------------
File to patch:
Dabei habe ich probiert, den Patch oberhalb des Freetz Trunks auszuführen, ich habe das diff in den trunk kopiert. Geht beides nicht.

Wenn ich patch -uN changeset_r3018.diff > my.patch eingebe, passiert für Minuten gar nichts, keine CPU Last, keine Ausgaben auf der Konsole. Nach Abbruch der Aktion finde ich dann zwar ein file my.patch, aber ohne Inhalt.

Ich weiß, dass ist hier OT, aber mag mir bitte einer erklären, was ich zu tun habe, damit ich die Dateien aus dem Changeset in eine beliebige bestehende freetz Installation bekomme? Ich möchte in diesem Fall in freetz 1.0.2 die Änderung mit dem Benutzernamen (Changeset 3018) integrieren. Ich würde das dann auch, sofern ich das verstanden habe, für Laien verständlich ins Wiki aufnehmen :)
 
Nochmal zum Festhalten:
Mit 04.67 ohne den Patch funktionieren deine Telefone?
Mit 04.70 (Patch von mir gelöscht) funktionieren deine Telefone nicht?
Wie siehts in beiden Fällen mit original Firmware aus? Die Frage zielt darauf ab, ob es an Freetz liegt oder ein AVM Problem ist.

MfG Oliver
 
Jetzt wirds blöd. Ich habe 2, heute morgen neu kompilierte, Images getestet:
7270_04.67freetz-1.0.2.de_20090301-113724_16MB-Flash_Remove-Patches_AVM-F_Dropbear_STunnel_OpenVPN_WoL_ohne-Freetz-Substring_inkl-Cert_mit-180-PrintK-Patch.image
und
7270_04.67freetz-1.0.2.de_20090301-113724_16MB-Flash_Remove-Patches_AVM-F_Dropbear_STunnel_OpenVPN_WoL_ohne-Freetz-Substring_inkl-Cert_ohne-180-PrintK-Patch.image

Der Unterschied zwischen beiden: Beim Image ohne 180_PrintK.Patch habe ich die Datei 180_PrintK.sh aus dem Package vor dem Compilieren gelöscht. Danach ein make dirclean durchegführt und dann neu compiliert.

Mit beiden Images funktionieren die Telefone jetzt. Haa, wie doof :(
Allerdings bekomme ich mit beiden Images keine DECT Ausgaben auf die Konsole. In beiden Images habe ich in dmesg die Zeile "[avm_debug]redirect kernel-messages (/dev/debug)" als letzte Zeile stehen (was ja auch gewollt ist).

Schalte ich im Image ohne Patch zwischen AVM_PrintK und STD_PrintK hin und her, kommt es zu nicht reproduzierbaren Verhalten.
Bei STD_PrintK: Mal klingelt eines der beiden Telefone, mal keins.
Zurück zu AVM: Hier klingelt jetzt plötzlich gar kein Telefon mehr.

Mit dem AVM Original Image 54.04.67 funktionierten beide Telefone bisher immer ohne Probleme. Erst nach dem Einspielen einer gefreetzen Firmware traten die DECT Probleme auf.
Mit dem AVM Original Image 54.04.70, welches zu diesem Zeitpunkt auf der Box läuft, funktionieren ebenfalls beide Telefone.

Jetzt die Preisfrage: Wer wird daraus schlau?
Meine Vermutung: Der Fehler sitzt bestimmt vor dem Monitor.
Allerdings weiß ich nicht, welchen Fehler ich gemacht haben könnte, da ich ja immer diesselben fertig kompilierten Images probiert habe.

Zum Schluß habe ich mir die Images mit einer sauberen Neuinstallation erneut gefreetz. Da scheint es egal zu sein, ob ich den PrintK Patch nutze oder nicht. Warum auch immer.

Will dazu jemand was sagen oder muss ich mich in meiner Ecke verstecken gehen :(
 
Ich habe heute die neue Firmware 04.70 freetz revision 3115 mit dem von olistudent deaktivierten printk patch aufgespielt.

Bisher keine Probleme mit DECT. AB funktioniert auch noch.

Die DECT messages / iptables messages kommen wie gewohnt auf der 1. console an.
Ich bin soweit zufrieden, werde es aber noch intensiver testen, da ich mit den labor versionen vor dem release probleme hatte und deshalb zurück auf die 67er musste.

Aber wie gesagt, bisher alles OK mit der neuen release. (Signatur angepasst ;) )

Viele Grüße

cando

@ Viprex:

Deine Frage kann ich Dir auch nur bedingt beantworten. Du hast relativ viele Dienste in deiner freetz FW. Sind die alle aktiv? Ich benutze nicht die stable 1.0.2, sondern den aktuellen trunk.
Da Du nach wie vor keine DECT Meldungen auf deiner ersten Konsole siehst, scheint es, dass der Patch noch wirksam ist.
Wenn Du STD_PRINTK aktivierst, ist es normal, dass DECT nicht / nicht sauber funktioniert. Die umschaltung weg von AVM_PRINTK solltest Du am besten lassen.

Ich habe nun erfolgreich auf die 70er in meiner wunsch-config upgedatet (ohne Tricks und Weglassen vom Patch, da olistudent den ja im Trunk für die 7270 auskommentiert hat).
Bisher funktioniert alles wie von der vorhergehenden 67er Firmware gewohnt. Bei mir laufen folgende Dienste: swap, webcfg, syslogd, inetd, avm-fw, dropbear, samba, rrdstats, netfilter/iptables mit conntrack.
Ich habe kein VoIP, meine Telefone hängen über die Fritz!Box (FAX Analog, 4xDECT, ISDN Telefon am S0) am ISDN Festnetz.
 
Zuletzt bearbeitet:
Dies ist nur eine kurze Zwischenantwort: Meine beiden Telefone funktionieren jetzt doch nicht mehr. Haben beide die Verbindung zur Basis verloren. Auch ein kurzes "Auswählen" der Basis am Mobilteil hilft diesmal nicht. Bei externen Anrufen klingeln beide Telefone nicht. Ich bin also doch nicht ganz doof.

Wie finde ich raus, welche Firmware ich gerade installiert habe? Wie sehe ich, ob der Patch eingespielt wurde oder nicht? Ich habe hier ja 2 Images liegen, einmal mit Patch und einmal mit händisch gelöschtem Patch. Bei beiden sehe ich keine Ausgaben auf der Konsole.

Code:
/var/mod/root # cat /etc/init.d/rc.S |grep "cat /dev/debug "
/bin/cat /dev/debug &
/var/mod/root #

... bedeutet, der Patch ist aktiv, da die Anweisung auf /bin/cat ungeschrieben wurde?! Falls das der Fall ist, werde ich heute Abend mal die andere Firmware ohne Patch draufballern. Dann sollte es ja damit wieder funktionieren. Komme da leider erst heute Abend zu.
 
Ja, heisst es wohl. Denn der Patch ändert eben in genau diesen Eintrag.
 
Ach, das macht doch keinen Spaß. Ich habe jetzt seit ein paar Stunden das Image ohne Patch drauf, Patch ist auch nicht aktiv:
Code:
/var/mod/root # cat /etc/init.d/rc.S |grep "cat /dev/debug "
cat /dev/debug &

Dennoch sehe ich kaum Meldungen auf der Konsole. Das mag daran liegen, dass die Telefone auch hier nicht klingeln (vielleicht besteht keine Verbindung zur Box?).
Auf der Konsole sehe ich nur:
Code:
Mar  2 19:18:13 telefon[777]: SIGCHLD received!
Mar  2 19:18:48 telefon[1528]: SIGCHLD received!
Mar  2 19:19:04 telefon[777]: SIGCHLD received!

Um das nochmal für mich klar zu machen: Die Meldungen auf der Konsole, von denen wir immer sprechen, sollte ich sehen, wenn ich mich per SSH oder Telnet auf die Box schalte und mich mit root einlogge? Zumindest steht dort immer
Code:
ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
. Nicht das ich immer auf der falschen Konsole gucke oder hier irgendwo der Fehler liegt.


Ich mag nicht mehr, das macht jedenfalls einfach keinen Spaß. Ich nutze jetzt doch diesselben Images wie gestern. Gestern funktionierten beide, heute melden beide Images nur Funkstille.

Was kann/soll ich noch probieren außer Aufgeben? Gibt es noch andere Hinweise, denen ich nachgehen kann? Vielleicht hats bei mir ja einen anderen Grund? Was könnt ihr euch noch vorstellen?

Edit: Interessant ist außerdem, dass ich keine Faxe mehr empfangen kann. Die FritzBox nimmt den Anruf vom entfernten Faxgerät nichtmal an. Ich habe eine ISDN Telefonanlage. Da hängt die Fritzbox dran, und zwar analog. Zwischen diese Verbindung ist eine Telefondose geschaltet, welche Klickgeräusche macht, wenn ein Anruf kommt und der Anruf beendet wird. Rufe ich mit meinem Handy hier zu Hause an, höre ich das Klicken. Die Telefone klingeln ja aber nicht. Das Klicken höre ich momentan nicht, wenn ein Fax ankommen soll. Kann auch gut an etwas Anderem liegen, wollte das nur mal nebenbei erwähnt haben. Faxe mittels FritzFax vom PC versenden geht aber problemlos.
 
Zuletzt bearbeitet:
Hast Du mal versucht, die Fritz!Box direkt am Telekom Anschluss anzuschliessen, anstatt sie hinter einer ISDN Anlage als analoge Nebenstelle an einer Fax Weiche (ich nehme mal an, das ist der Grund für das Klicken - Relais?) anzuklemmen.

Wenn dann die Box funktioniert, kannst Du die ISDN Anlage nach der Box am S0 Bus anhängen oder parallel zu der Fritte am NTBA anstöpseln. Wenn Du eh schon ISDN hast, warum dann erst auf Analog runter?

Also ich tippe mal stark auf Deine Verkabelung...

Für oli:
Meine Box läuft bisher sauber und stabil mit der neuen FW bei intensiver Nutzung von DECT / analog Fax. Alles OK ohne den Patch, vielen Dank noch mal.
 
Zuletzt bearbeitet:
@Viprex
Eigentlich ist es so gedacht, dass keine Meldungen auf der Konsole kommen. Das "cat /dev/debug &" sollte am Ender der rc.S beendet werden. Wenn du das eingibst, dann kommen alle alten Meldungen.

@cando
Warum ist das bei dir noch aktiv? Startest du was aus der debug.cfg/rc.custom?

MfG Oliver
 
ich lade die Module mit modprobe für die iptables firewall aus der debug.cfg heraus und dort stehen auch die Regeln für iptables drin.
 
Nein, die Verkabelung ist es nicht, es funktionierte vorher ja alles problemlos. Aber ich muss zugeben, so ganz optimal ist das nicht. Ich habe aber keine andere Möglichkeit, es geht nur so. Die ISDN Anlage steht bei meinem Vermieter, der Router bei mir. Wir teilen uns aber Telefon und DSL über einen Anschluß. Die Alternative wäre, die FB zum Vermieter zu stellen und das dann so zu verkabeln. Das will ich aber nicht, da ich dann keinen physikalischen Zugriff mehr auf die Box habe. Daher bleibt es bei dieser Verkabelung (die ja auch vorher immer funktionierte - inkl. Fax, Anrufbeantworter und 2 DECT Telefonen)

@Oli: Das bedeutet, dass ich auch gar keine Ausgaben auf der Konsole erwarten darf? Interessant ist, dass ich ja sowohl mit Patch als auch ohne Patch keine Ausgaben auf der Konsole bekomme. Wohlmöglich funktioniert daher "cat /dev/debug &" als auch "/bin/cat /dev/debug &" bei der 7270 korrekt? (eine Eingabe von /dev/debug & direkt auf der Konsole wird mit Permission denied abgelehnt - wollte mal testen, ob meine Konsole dann gesprächiger wird).
 
Code:
cat /dev/debug
funktioniert auf alle Fälle.

MfG Oliver
 
Ahh, ok Danke!
Nach Eingabe des Befehls kommen ganz viele Zeilen auf der Konsole. Ich habe mal die letzten Zeilen C&P:

Code:
[05128362][DCTDRV] (API_MONITOR_PP_STATUS_REQ) LINETASK->UI_TASK [16 F6 02]
[05128362][DCTDRV] (MONITOR_DRV_STUB_PP_STATUS_REQ) UI_TASK->FP_CCF_TASK [20 F6 02]
[05128365][DECTSTUB] {monitor_drv_stub_pp_status_cfm} 2
[05128366][DECTSTUB] {monitor_drv_stub_pp_status_cfm} encryption: 0
[05128366][DCTDRV] (MONITOR_DRV_STUB_PP_STATUS_CFM) FP_CCF_TASK->UI_TASK [21 F6 02 04 00 36 00 00 00]
[05365413][DECTSTUB] MacRcv (First): [FA BE FA BD 7F A9], slot 8, chan 7
cat: read error: Broken pipe

Was bedeutet denn die letzte Zeile?
 
/dev/debug ist eine Pipe und das normale Verhalten ist, dass cat mit einem read error schließt, wenn alles daraus gelesen ist. Das wird durch folgende Zeilen in der /etc/init.d/rc.S erreicht:
Code:
## cleanup - if running, stop debug (0 normal, 1 flush buffer)
if `ps | grep -v grep | grep -q "cat /dev/debug"` ; then
echo Info: have to stop 'cat /dev/debug'.
echo AVMDBG_EOF 1 >/dev/debug
MfG Oliver
 
Ok, nochmal vielen Dank.

Ich mag dich gar nicht mehr fragen, aber hast du noch eine Idee, was ich testen könnte? So ist der Zustand ja nicht haltbar. Klar könnte ich die Telefone auch wieder direkt verkabeln und nicht über die Box laufen lassen, dann kann ich aber auch AB und Fax nicht mehr nutzen. Außerdem wollte ich mir demnächst ein 3. Telefon kaufen (wohl das AVM Fon). Das muss dann über DECT funken. Andere Alternative wäre Freetz runter. Damit wäre euch zwar geholfen meine mittlerweile nervigen Posts abzustellen, aber zielführend ist das ja auch nicht.
 
Was mir nicht klar ist, warum das nur bei dir passiert. Es nutzen doch viele hier die 7270 mit DECT-Telefonen. Und außer dir hat noch niemand davon berichtet, dass mit Freetz seine Telefon nicht mehr funktionieren.

MfG Oliver
 
Ich könnt zumindest mal davon berichten, dass ich grad das 3. oder 4. mal beobachtet hab, wie meine Box spontan rebootet, wenn ich ans Telefon gehe, nur weil eines der Telefone per DECT angeschlossen ist. Ohne die DECT-Verbindung (und dem rauspatchen des DECT-Zeugs) funktioniert sie nämlich ohne dieses Problem.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.