CALLMONITOR verliert die Verbindung

[AxelSchweiss]

Hallo

Ich habe das Phänomen das der CALLMONITOR sporadisch die Verbindung zur Fritzbox verliert.
Das Äussert sich dadurch das ein Telefonat (call, disconnect) nicht mehr registriert wird.

FHEM ist aktuell und die Fritzbox ist eine 7360 mit der 6.30 Firmware.

Die Config-Section ist wie folgt :

Code Auswählen Erweitern

define Callmonitor FB_CALLMONITOR 192.168.12.1
attr Callmonitor group Anrufe
attr Callmonitor country-code 0049
attr Callmonitor local-area-code 0XXXX
attr Callmonitor reverse-search phonebook
attr Callmonitor reverse-search-cache 1
attr Callmonitor reverse-search-cache-file /opt/fhem/log/callmonitor_cache.txt
attr Callmonitor reverse-search-phonebook-file /opt/fhem/config/telefonbuch.xml
attr Callmonitor icon phone_call
attr Callmonitor room Anrufe
attr Callmonitor unique-call-ids 1
attr Callmonitor fritzbox-remote-phonebook-via tr064


Im Logfile finde ich dann irgendwann folgenden Eintrag

Code Auswählen Erweitern

2015.09.17 17:15:21 1: 192.168.12.1:1012 disconnected, waiting to reappear (Callmonitor)
2015.09.17 17:15:21 1: 192.168.12.1:1012 reappeared (Callmonitor)


Aber Stunden später ... nachdem einige Anrufe unbemerkt durchgingen  .... quasi wenn FHEM merkt das da was nicht stimmt.

Kennt das Problem jemand oder weiss jemand was ich da falsch mache?

[Markus Bloch]

Dieses Problem zeigt, dass du ein Stabilitätsproblem mit deinem Netzwerk hast. Das kann verschiedene Ursachen haben:

- Paketverluste
- Verbindungsabreiser (WLAN)
- Stromverlust der Netzwerkinfrastruktur

Wenn FHEM mit der FritzBox verbunden ist, werden dort keinerlei zyklische Daten übermittelt. Nur, sobald ein Anrufevent stattfindet, wird dies durch die FritzBox an FHEM gesendet. FHEM sendet aber keinerlei Daten an die FritzBox. Somit kann FHEM nicht erkennen, ob eine Verbindung "tot" ist, da keinerlei Daten ausgetauscht werden, wenn keine Anrufe stattfinden. Es gibt im TCP-Protokoll einen Keep-Alive Mechanismus den FHEM aktiviert um solche toten Verbindungen ohne regelmäßige Datenübertragungen zu erkennen und automatisch neu aufzubauen (so wie es bei dir passiert ist).

Ein Fehlverhalten ist das also nicht.

Viele Grüße

Markus

[tca]

Hallo @Markus Bloch,

dieser Thread ist zwar schon etwas älter, aber ich habe hier ein ähnliches/gleiches Problem - und evtl. kann man etwas am Callmonitor 'einbauen'...:

Mein Verkabelungsschema sieh so aus:   Internet -- Fritzbox 1 (FB1) -- Router -- Intranet/local
Im Intranet/local befindet sich FHEM/Raspberry, eine zweite Fritzbox (FB2, sip-client), etc.

Der Callmonitor funktioniert fehlerfrei mit FB2. Für die Verbindung zu FB1 wird aber im FHEM-log immer wieder die Fehlermeldung

Code Auswählen Erweitern


2017.01.29 07:11:22 1: 192.168.101.2:1012 disconnected, waiting to reappear (FB_CallMonitor)
2017.01.29 07:11:22 1: 192.168.101.2:1012 reappeared (FB_CallMonitor)

angezeigt.

Das hängt meines Erachtens mit dem Router zusammen, der für eine aus seiner Sicht ausgehende Verbindung (Session, Callmonitor) von FHEM nach FB1 einen NAT-Eintrag (ipNatTable) schreibt.
Dieser NAT-Eintrag wird benötigt, um sobald FB1 ein Pakte zurückschickt (Benachrichtigung bei eingehenden Anruf), den ursprünglichen Adressat zu kennen. Diese Einträge haben ein Timeout (bei mir 3600s). Sollte für diese Zeitspanne kein Datenpaket gesendet sein, wird der Eintrag gelöscht. Danach eintreffende Datenpakete können dann nicht mehr zugewiesen werden.

Bei AVM ist dieses Problem bekannt, für z.B. die SIP-Client Anwendung: Internet -- FB1 (sip-server) -- Router -- FB2 (sip-client)
Die FB2 (sip-client) baut zunächst einen Verbindung zu FB1 (sip-server) auf und wartet dann auf rückgehenden Datenverkehr. Damit die Verbindung -in dieser Konstellation- aufrecht erhalten wird, erneuert FB2 die Session nach einer kurzen Zeit.
Bei AVM/Fritzbox heisst diese Option "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" und sollte sich unter Telefonie-->Eigene Rufnummern-->Anschlusseinstellungen finden lassen.

Lässt sich etwas ähnliches für den Callmonitor implementieren? Z.B.eine Funktion 'ReEstablishConnection', die man jede 30 min. über at aufruft ...?

Danke und Grüße,
Tom

[Markus Bloch]

Ich habe ein neues Set-Kommando "reopen" im SVN eingecheckt.

Gibt es morgen via update.

Viele Grüße

Markus

[tca]

Super! Ich habe die neue Version direkt heruntergeladen und schon zwei Stunden laufen ... es geht!

Danke,
Tom

[tca]

Hallo Markus,

die Meldung erscheint doch noch im Log - nach etwas mehr als zwei Stunden.

Ich habe gerade ein netstat -c --timer | grep FB1 auf dem raspberry laufen lassen. Es sieht so aus, als ob das reopen bzw. DevIo_CloseDev die Verbindung nicht beendet. Eine neue telnet-Verbidung wird zwar geöffnet, die alte läuft aber weiter und geht dann nach ca. 7300s in ein TimeOut.

Eventuell muss vor dem DevIo_CloseDev ein ^]quit gesendet werden?

Grüße,
Tom

[Markus Bloch]

Hallo Tom,

ich habe bei mir das Reopen extra mit Wireshark nachgeprüft. Die Verbindung wurde sofort beendet (TCP FIN, FIN/ACK, ACK) und neu aufgebaut.

Es kann sein, dass in deinem Fall der NAT-Eintrag bereits abgelaufen ist und daher der Verbindungsabbau bereits ins Leere läuft. Klappt es denn mit geringeren Abständen?

Gruß
Markus

[tca]

Hallo Markus,

mit jedem 'set callmonitor reopen' -sei es manuell oder per 'at', nach wenigen Sekunden oder Minuten- wird bei mir auf dem raspberry/FHEM eine neue telnet-Verbindung aufgemacht. Die alte wird aber nicht geschlossen, sondern bleibt auf ESTABLISHED keepalive.

Es ist kein Widerspruch, dass ggf. ein Paket mit TCP FIN, FIN/ACK, ACK rausgeht, die telnet-Verbindung aber lokal offen gehalten wird. Wird vor dem DevIo_CloseDev ein quit innerhalb telnet gesendet? Ansonsten wird telnet offen gehalten (ähnlich wie z.B. bei ctrl-Z). Was zeigt das netstat bei dir an?

Grüße,
Tom

[Markus Bloch]

Hallo Tom,

es handelt sich bei der Verbindung um eine reine TCP-Verbindung die direkt in FHEM etabliert wird. Hierbei ist kein Telnet involviert. Es werden keine Shell-Befehle gestartet oder dergleichen.

FHEM ist in Perl geschrieben und direkt in Perl kann man eine TCP-Verbindung zu einer Ziel-Adresse/-Port öffnen. Dafür gibt es in FHEM das Hilfsmodul DevIo, welches dies einfach in der FHEM-Umgebung ermöglicht.

Netstat kann ich erst prüfen, wenn ich Feierabend habe

Gruß
Markus

[tca]

... stimmt, die Verbindung wird ohne Shell von FHEM bereitgestellt; mit telnet konnte ich das manuell 'schön' reproduzieren und hab's im Eifer so formuliert...

Mir ist jetzt gerade aufgefallen: schaltet man mit

Code Auswählen Erweitern

attr callmonitor disable 1; attr callmonitor disable 0; klappt es; die neue listen-Verbindung wird sofort aufgebaut, die alte listen-Verbindung wird lokal nach 60s geschlossen;