FB_CALLMONITOR disconnected

Begonnen von elektrikpe2, 03 April 2018, 21:38:34

Vorheriges Thema - Nächstes Thema

elektrikpe2

#15
Hallo,

Ergebnis meiner Recherchen: Ich kann die Beobachtung von Darrol bestätigen. Es gibt nicht nur einen Logeintrag, wenn die FB den Callmonitor schließt sondern auch ungeloggte Schließungen des Callmonitors auf der FB. Das wurde auch schon in einem anderen Thread (https://forum.fhem.de/index.php/topic,41195.msg572276.html#msg572276) beschrieben. Insofern halte ich eine Kombination aus dem beschriebenen at und dem readlog für die Lösung des Problems, wenn nicht jemand noch eine elegantere findet. Ich habe das jetzt so eingebaut und beobachte mal die Funktionsweise. Also für Faule:
define Callmonitor_Reopen at +*00:20:00 set Callmonitor  reopen und
defmod n_reopenCallMonitor notify .*xx\.xx\.xx\.xx:1012.reappeared.* {fhem("set CallMonitor reopen");; Log3(undef,3,"notify CallMonitor reopen");;}
attr n_reopenCallMonitor readLog 1

Gut, den zusätzlichen Log kann man sich irgendwann sparen.

VG Peter

Darrol

Hi elektrikpe2,

ich habe  eben auch nochmal etwas bei avm recherchiert und bin dabei hierauf gestoßen:
https://avm.de/service/fritzbox/fritzbox-7270/wissensdatenbank/publication/show/907_Anwendung-z-B-SSH-verliert-gelegentlich-die-Verbindung-zu-Gegenstellen-im-Internet/

Dort heißt es:
ZitatUm die Sicherheit der Geräte im FRITZ!Box-Heimnetz zu gewährleisten ..., löscht die FRITZ!Box automatisch alle TCP-Verbindungen nach 15 Minuten und alle UDP-Verbindungen nach 5 Minuten ohne Datenaustausch aus ihrer NAT-Tabelle ("NAT-Timeout")...
...Um zu verhindern, dass die FRITZ!Box Verbindungsinformationen aus ihrer NAT-Tabelle löscht, richten Sie die Internetanwendung so ein, dass sie regelmäßig Datenpakete ins Internet sendet.

Dieser Beitrag dort ist zwar für die FB7270 hinterlegt (ich selbst besitze das 1&1-Konstrukt FB7412) aber das klingt schon sehr verdächtig nach dem hier beschriebenen Verhalten.
Zudem schreibt Markus Bloch in dem von dir verlinkten Forenthread:
ZitatFHEM 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).

Und hier noch etwas Literatur zum TCP-KeepAlive:
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html

Darin lese ich(man korrigiere mich falls ich irgendwo voll daneben liege), dass

  • die TCP-KeepAlive- Funktion bei mir und auch anderswo nicht funktioniert wie sie soll
  • das KeepAlive im Zweifelsfall genau das gleiche leistet wie das "reopen" per notify oder at
  • durch die Verwendung von at/notify somit kein zusätzlicher traffic entsteht

Bleibt die Frage was mit dem KeepAlive nicht stimmt, dass es nur starkt verzögert bis gar nicht greift.  ???
IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB

Markus Bloch

Hallo Darrol,

kleine Anmerkung zum Thema KeepAlive. Bei Perl ist der Standardinterval für ein TCP-KeepAlive 2 Stunden. Aus den Aussagen von AVM werden Verbindungen nach 15 Minuten Inaktivität bereits aus der NAT-Tabelle gelöscht.

Ich würde daher anbieten, einen optionalen KeepAlive-Mechanismus aller 10 Minuten direkt in FB_CALLMONITOR zu implementieren um die Verbindung offenzuhalten (Senden eines Newlines).

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Hallo zusammen,

ab morgen gibt es ein neues Attribut "sendKeepAlives". Ich würde in eurem Falle empfehlen dies mal auf 5m oder 10m zu stellen. Damit sollten die Disconnects verschwinden ohne, das man mit einer at-Definition nachhelfen muss.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Darrol

IntelNUC
-Fhem 5.8 in Ubuntu 16.04-Container
-dbLog & configDB auf Postgres-DB

elektrikpe2

och manno, war gerade so stolz, dass ich das Problem im Griff hatte  :) nee Spaß. Schon eingebaut, beobachte und berichte. Krasse Arbeit. Danke.

VG Peter

elektrikpe2

Hallo,

bis zum 16.04. lief Callmonitor und Calllist wie gewünscht. Nach Update vom 16.04. bekomme ich wieder disconnect. Weiß natürlich nicht, ob das damit zusammenhängt. Hatte bis dahin auf 10m danach auf 5m gestellt. Leider immer wieder (fast schon regelmäßig 2x am Tag) disonnect. Hab den at wieder eingebaut.

VG Peter