FBF 7050/7170 - BETA-Firmware Build 3274/3306 (14.04.03-xx/29.04.03-xx) (+Recovery)

[Mr-Fly]

Hallo,
auch ich möchte mich mal zu Worte melden.
Seit der Beta werden bei mir alle Gespräche nach exakt 30 Minuten getrennt.
Kann das noch Jemand nachvollziehen?
Das war vor der Beta nicht so.
Im Ereignisprotokoll ist Dieses nicht protokolliert.

Hallo.
Definitiv nicht, denn ich hab am Wochenende mehrere Gespräche >2 Std geführt ueber VOIP

Gruß Fly

 

[Mr-Fly]

Du solltest dir das aber nicht zu einfach machen. Bei mir waren alle Einstellungen so das die Umleitung hätte in der Vst passieren müssen. Trotzdem hat die FritzBox bei der Hälfte der Anrufe die Umleitung selbst gemacht. Und wohl gemerkt nur in der Hälfte der Anrufe! Das hat also sicher nix mit falschen Einstellungen zu tun. Es muss also was das betrifft schon noch einen Bug geben. Möglicherweise ja in der Kommunikation mit der Vst. Denn manchmal scheint die FBF einfach zu "denken" die Umleitung in der Vst würde nicht funktionieren. Und genau in diesem Fall versucht sie es dann wohl selbst.

Hallo Grassi2000.

Die Umleitung in der Vermittlungsstelle sollte für die Box völlig transparent sein, denn man bekommt eigentlich keine Mitteilung wenn an der VST umgestellt wird.
Der ISDN-Kanal zu dir nach Hause wird noch nicht mal geöffnet.
Somit muss eigentlich ein Konfigurationsfehler vorliegen, so dass die Umleitung nicht richtig eingetragen ist (auf der VST) oder die Fritzbox selbstständig irgendwie laufend die VST-Umleitung wegnimmt.

Gruß Fly

 

[grassi2000]

Die Umleitung trage ich direkt bei der T-Com auf der Homepage ein. Die waren ja auch seit Jahren korrekt eingetragen. Die Box hat diese Umleitungen mit der neuen Firmware dann auch korrekt angezeigt (umleiten über war auch frei, Art und Ziel der Umleitung stimmten). Sie hat halt einfach nur nicht mehr zuverlässig funktioniert. Manchmal wurde eben in der Vst umgeleitet (dann kommt ja die richtige Ansage) und manchmal in der FBF (dann kommt "Geben sie ihre PIN ein").

Eine Fehlkonfiguration kann ich also definitiv ausschließen. Es muss ein Fehler in der FW vorliegen. Was die FBF da nun genau falsch macht kann ich natürlich nicht sagen.

 

[xsapling]

Grassi, ich muss Dir 100%ig zustimmen!

Die Umleitung trage ich direkt bei der T-Com auf der Homepage ein. Die waren ja auch seit Jahren korrekt eingetragen. Die Box hat diese Umleitungen mit der neuen Firmware dann auch korrekt angezeigt (umleiten über war auch frei, Art und Ziel der Umleitung stimmten). Sie hat halt einfach nur nicht mehr zuverlässig funktioniert. Manchmal wurde eben in der Vst umgeleitet (dann kommt ja die richtige Ansage) und manchmal in der FBF (dann kommt "Geben sie ihre PIN ein").

Eine Fehlkonfiguration kann ich also definitiv ausschließen. Es muss ein Fehler in der FW vorliegen. Was die FBF da nun genau falsch macht kann ich natürlich nicht sagen.

 

[casodo]

bei mir auch

auch ich kann die Beobachtung von Grassi in allen Einzelheiten bestätigen

 

[Läppi]

Von dem Problem haben ja bereits andere berichtet. Hast Du auch einen ArcorDSL-Anschluß?

Ich würde sagen, da mußt Du die Beta wieder runterwerfen. Allerdings kannst Du dann nur die 29.04.01 installieren, da es die 02 nicht als Recover gibt, soweit ich weiß. Oder Du wartest auf die nächste Beta, die ja angeblich schon in den Startlöchern steht.

Nein, bin bei der Telecom.

Die schicken ein Router mit einer Beta raus???

Ahhhhh.... wir sind die Tester!

 

[mega]

Hat noch wer das Problem, das die Trennung bei inaktivität nicht geht?
Bei mir bleibt die 7050 jetzt ständig online.
Ist zwar nicht wirklich ein Problem, ist mir aber aufgefallen.

 

[florianr]

Nein, bin bei der Telecom.

Die schicken ein Router mit einer Beta raus???

Ahhhhh.... wir sind die Tester!

Ähm ich glaube der Poster sprach von der .02 Firmware, die Beta ist .03 ...
Mit der .02 scheinen die AVM Geräte ausgeliefert zu werden.

 

[Snake Plissken]

Hallo,
auch ich möchte mich mal zu Worte melden.
Seit der Beta werden bei mir alle Gespräche nach exakt 30 Minuten getrennt.
Kann das noch Jemand nachvollziehen?
Das war vor der Beta nicht so.
Im Ereignisprotokoll ist Dieses nicht protokolliert.

Tja, ich habe wohl das gleiche Problem. Ruft mich meine Holde (7050) auf meine Box (7170) an, so ist nach genau 30 min das Gespräch vorbei.

Wir haben beide die 3306 auf der Box.

hone:

 

[Knighty]

konnte ich noch nicht feststellen, längstes gespräch waren 73min ununterbrochen, allerdings hatte die gegenstelle keinerlei boxen dazwischen, ging nur über meine 7170, vll. liegts an der 7050er.

 

[mega]

konnte ich noch nicht feststellen, längstes gespräch waren 73min ununterbrochen, allerdings hatte die gegenstelle keinerlei boxen dazwischen, ging nur über meine 7170, vll. liegts an der 7050er.

Wenn hier jemand bei Sipgate ist und 30 min Zeit hat, können wir das mal testen. Ich hab ne 7050 mit der Beta. Einfach gespräch aufbauen und stehen lassen.

 

[Läppi]

Ähm ich glaube der Poster sprach von der .02 Firmware, die Beta ist .03 ...
Mit der .02 scheinen die AVM Geräte ausgeliefert zu werden.

alles klar.

Habe jetzt mal bei AVM angerufen die wollen sich bei mir morgen melden.
Werde berichten was sie alles vorschlagen um das Problem zu lösen.

 

[WALKLiFE]

Moin!

nach dem letzten sync sieht es jetzt so aus

12.03.06 18:31:31 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 82.82.90.xxx, DNS-Server: 195.50.140.114 und 195.50.140.252, Gateway: 82.82.64.1

12.03.06 18:31:29 Internetverbindung wurde getrennt.

12.03.06 18:31:29 PPPoE-Fehler: Zeitüberschreitung. 

12.03.06 18:31:26 Internetverbindung wurde getrennt.

12.03.06 18:31:26 PPPoE-Fehler: Zeitüberschreitung.

hmm, ich habe auch die 3306 drauf, aber bei mir trennt die Box nicht mit der Fehlermeldung "PPPoE-Fehler: Zeitüberschreitung", sondern mit "DSL antwortet nicht (Keine DSL-Synchronisierung)." und das zum Glück nicht ganz so oft, sondern etwa alle ein bis zwei Stunden.

EDIT: ups, mein Fehler, ich sehe gerade in den Logs/eMails, dass sie das vorher auch schon gemacht hat -- aber seltener (4-5 mal pro Tag)


Mir ist aber noch ein (sehr kleiner/unwichtiger) Fehler aufgefallen:
Es gibt nun ja auch ein Telefonbuch, wenn man da auf den Button "Druckansicht" klickt werden die Kurzwahl- und Vanity-Code falsch angezeigt. (die # müsste ans Ende, nicht vor die Kurzwahl/Vanity)

BDD!
WALKLiFE

PS: da ich noch keine Signatur eingerichtet habe: DSL habe ich bei Versatel, achja: FB 7170

 

[mega]

Von Fritz!Box 7050 14.04.03-3274 BETA nach 7170 - Release 3306 über sipgate abbruch nach ziemlich genau 30 min.

 

[Zyco]

Verbindungsabbrüche

Also ungewollte Verbindungsabbrüche hatte ich noch keine. Nur die Probleme eine Verbindung herzustellen am gestrigen Sonntag (s.o.). Allerdings geht jetzt wieder alles ganz normal und der GMX Support schrieb mir heute in der Antwort auf meine Störungsmeldung:
"wie ich dem Protokoll entnehmen konnte scheint es sich um eine kurzfristige Störung gehandelt haben." (fehlt ein "zu").
Weiß ja nicht ob vielleicht mehrere Anbieter irgendwas bei sich umstellen? Oder die T-Com, oder ... jedenfalls daß es vielleicht gar nicht direkt mit den Beta FWs zusammenhängt?

 

[mega]

Von Fritz!Box 7050 14.04.03-3274 BETA nach FB 7050 mit 14.04.03-3306 + LCR 1.44.10. über sipgate läuft seit 42 min.
Bei 44 Min verreckt.

 

[Moonbase]

Hier dazu die Auszüge aus dem syslog:

Mon Mar 13 20:48:27 2006: 192.168.170.1: <14>voipd[422]: >>>UDP Request: UPDATE sip:[email protected];uniq=8E51B5AB55F7FCA638A399269FF6B
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: <<<UDP Request: BYE sip:[email protected];uniq=7A33A4BD4739FB6ADF40A944E6540
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: QoS-Report(< 7654321 via sipgate.de): PS=87426;OS=20692320;SP=0/0;SO=0;PR=87385;OR=21730020;CR=0;SR=0;PL=0;BL=0;EN=PCMA,G726-32;DE=PCMA,G726-32;JI=0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: QoS-Report(> 7654321 via sipgate.de): PS=87397;OS=20684280;SP=0/0;SO=0;PR=87426;OR=21741432;CR=0;SR=0;PL=0;BL=0;EN=PCMA,G726-32;DE=PCMA,G726-32;JI=0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: Codec - (-) - audio 0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: bridgelimit: nConnections=0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: bridge lan set to full speed
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: ocfree: fail 0 normal 0 small 100 large 87189
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         underrun 0 max_ackqueuelen 8
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         small packets merged 0, output 0 and consumed from CNG 0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: ocmode: normal 87289 merged 0 delayed 0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: dropped 147 packets with 35280 samples and one sample in 8599 packets
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: generated noise: 100
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[0]: 2 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[1]: 76 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[2]: 6633 (  7.5%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[3]: 1180 (  1.3%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[4]: 371 (  0.4%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[5]: 71478 ( 81.8%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[6]: 6282 (  7.1%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         capiqueue[7]: 1267 (  1.4%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[  0ms]: 2 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 10ms]: 8 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 20ms]: 14 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 30ms]: 83 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 40ms]: 85 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 50ms]: 369 (  0.4%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 60ms]: 6185 (  7.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 70ms]: 71514 ( 81.9%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 80ms]: 611 (  0.6%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[ 90ms]: 5805 (  6.6%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[100ms]: 985 (  1.1%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[110ms]: 336 (  0.3%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[120ms]: 1292 (  1.4%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[130ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[140ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[150ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[160ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[170ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[180ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[190ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[200ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[210ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[220ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:         txqueue[230ms]: 0 (  0.0%)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: call from sip:[email protected] terminated (200)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: sent: 87397 (20684280) voice, 0 (0) CN, 0 silence
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: jitter packets 87426 bytes 20692320 drop_toolate 0 drop_duplicates 0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]:        wrong_seq 0 packets lost 0 (max burst 0)
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: rtpsession drop_nobuffer 0 drop_nonaudio 0 drop_tooshort 0 decoder failed 0
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: >>>UDP Status: 200 OK
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: <<<UDP Status: 200 OK
Mon Mar 13 20:48:28 2006: 192.168.170.1: <14>voipd[422]: no transaction for status: 200 OK
Mon Mar 13 20:48:35 2006: 192.168.170.1: <14>voipd[422]: disconnected(appl=5 plci=0x1305 ncci=0x11305 outgoing): local: 0x3490 (0x3301) -

Hm... Wunderlich.
Ein BYE als Antwort auf ein UPDATE?

Ketzerisch gefragt: Hat vielleicht nicht jeder SIP-Anbieter unter
ALLOW: ... UPDATE
in der Liste? Und könnte es sein, das die FB davon ausgeht, dass UPDATE *immer* zulässig ist?

Ich meine, wenn ich das richtig sehe, erlaubt eine FB (xx.04.01) INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE.

Wenn ich mir da manch andere Gerätschaften anschaue (z.B. ein Lancom PBX), sieht das schon ganz anders aus:

User-Agent: LANCOM PBX
Server: xxx
Allow: INVITE, ACK, CANCEL, BYE

 

[6139639]

Heute hat ein Freund mir folgendes berichtet: Mitten in unserem Gespräch wollte er mir "ins Wort" reden, um meinen Redefluss zu beenden, und dann wurde ich bei ihm ausgeblendet. Also er konnte meine Sprache nicht mehr hören (es war Stille, nur seine eigene Sprache hörte er). Nachdem er mir das Problem geschildert hatte, probierte ich auch ebendieses und versuchte im ins Wort zu sprechen (sowohl leise als auch laut) und in beiden Fällen war seine Stimme weg.
Zur Sicherheit haben wir nochmal ein Festnetzgespräch geführt, dort ist es wie immer, ich kann ihm ins Wort reden, höre ihn aber, und andersrum. Auch berichtet mein Freund, dass dieses vor dem Betaupdate noch nicht der Fall war. VAD habe ich deaktiviert und hatte es auch schon vorm Betaupdate deaktiviert.

Hat einer ähnliche Erfahrungen gemacht? Hat sich bei der VoIP-Behandlung was in der Beta geändert?

Also mit einem Freund (er 7050 .01 - ich 7170 mit aktueller Beta) haben über VOIP das gleiche Problem.
Festnetzverbindung ist ok.
Wir haben 1&1 und SIPDISCOUNT als Provider getestet - gleiches Ergebnis

 

[mega]

Diesen ins-wort-fallen-Abbrauch hatte ich beim 30 min-Test nicht

 

[t.o.b.i]

Unexpected EOF bei 3306 update

Hallo,

das Update von 14.04.01 auf 14.04.03-3306 bleibt beim Auspacken des kernel.image stehen. In /var/tmp/update_error.log habe ich den Fehler "tar: Unexpected EOF" gefunden.

Ich hab die .exe unter Linux direkt mit Wine ausgepackt, zum Test auch mit 7zip -> gleiches Ergebnis. Auf meinem PC (Linux) kann ich das Image ohne Probleme auspacken... Verstehe ich nicht. Hat jemand einen Tipp für mich?

# cd /var/tmp/
# ls -l
-rw-r--r--    1 root     root         8483 Mar 13 22:24 Anrufliste_vom_13.03.2006.csv
-rw-r--r--    1 root     root        20374 Mar 13 22:24 alt_detail.txt
drwxr-xr-x    1 root     root            0 Sep  8  2002 csem
-rw-r--r--    1 root     root        74571 Mar 13 22:24 detail.html
-rw-r--r--    1 root     root           12 Mar 13 22:23 fw_ip
-rwxrwxrwx    1 root     root           10 Feb  1 16:44 group
-rwxrwxrwx    1 root     root           44 Feb  1 16:44 hosts
-rw-r--r--    1 root     root         3598 Sep  8  2002 igddesc.xml
-rwxr-xr-x    1 root     root       581618 Mar 13 22:25 kernel.image
-rwxrwxrwx    1 root     root           26 Feb  1 16:44 passwd
-rwxrwxrwx    1 root     root           50 Sep  8  2002 resolv.conf
-rwxrwxrwx    1 root     root           26 Feb  1 16:44 shadow
-rw-r--r--    1 root     root           20 Mar 13 22:25 update_error.log
-rw-r--r--    1 root     root           41 Mar 13 22:25 update_out.log
# cat update_out.log
./var/
./var/tmp/
./var/tmp/kernel.image
# cat update_error.log
tar: Unexpected EOF

Danke!
tobi