FHEM2FHEM verliert Verbindung

[tobias.faust]

Hallo zusammen,

ich habe eine Remote-FHEM Installation per  FHEM2FHEM Modul an meine "Haupt"-FHEM-Installtion gekoppelt. Das funktioniert auch super. Aber nach ein paar wenigen Tagen empfängt mein Haupt-FHEM keine Daten mehr vom "Client"-FHEM.
Nach einem "shutdown restart" werden wieder Daten empfangen.

Gibt es in FHEM2FEHM keine Reconnect-Logik? Oder kann ich mit einem Befehl es zum Reconnect zwingen wenn ich feststelle das seit ca 10min keine Daten mehr kommen? Ein "shutdown restart" ist schon ziemlich die Holzhammer-methode..... ;)

[Rudolf Koenig]

> Aber nach ein paar wenigen Tagen empf�ngt mein Haupt-FHEM keine Daten mehr
> vom "Client"-FHEM.

Steht in einem der FHEM-logs was auffaelliges? Kann man noch ueber den Client
Kommandos auf dem Haupt-Server auffuehren? Wie sind die beiden verbunden, LOG
oder RAW?

> Gibt es in FHEM2FEHM keine Reconnect-Logik?

Doch, aber erst wenn die Verbindung zwischen den beiden getrennt ist.
Evtl. hat der Haupt-fhem den Client (warum auch immer) aus der Verteilerliste
gestrichen. Kannst Du folgendes testen (im Normall und im Fehlerfall):

{ my $r="";; foreach my $c (keys %client) { $r .= "\n$client{$c}{addr}/$client{$c}{inform}" if($client{$c}{inform}) } ;; $r }

Das ist eine Zeile, ausgefuehrt auf dem Haupt-Fhem (telnet oder FHEMWEB), mich
interessiert der Rueckgabewert.

> Oder kann ich mit einem Befehl es zum Reconnect zwingen wenn ich feststelle
> das seit ca 10min keine Daten mehr kommen?

Nur via
{ FHEM2FHEM_Disconnected($defs{<F2F-InstanName>}) }

[Willi]

On 7 Jun., 09:16, "tobias.faust" <tobias.fa...@gmx.net> wrote:
> Hallo zusammen,
>
> ich habe eine Remote-FHEM Installation per  FHEM2FHEM Modul an meine
> "Haupt"-FHEM-Installtion gekoppelt. Das funktioniert auch super. Aber nach
> ein paar wenigen Tagen empfängt mein Haupt-FHEM keine Daten mehr vom
> "Client"-FHEM.
> Nach einem "shutdown restart" werden wieder Daten empfangen.

Seltsam. Ich stelle bei mir auf der Fritzbox 7390 die angeschlossenen
Devices CUL sowie RFXtrx433 per FHEM2FHEM meinem Haupt-FHEM-Server
(Sheevaplug) unter Debian Squeeze bereit. Das läuft seit Monaten und
stabil.

Normalerweise überstehen TCP-Verbindungen auch Netzwerkprobleme
klaglos. Da stören auch Paketverluste nicht.

Versuch mal zwischen beiden Systemen parallel eine SSH (bzw. bei
Fritzbox) eine Telnet-Verbindung aufzumachen und zu beobachten, ob
diese nach einigen Tagen noch problemlos läuft.

Was für eine Konfiguration (Betriebsysteme) hast Du?

[tobias.faust]

Also in den Logs (fakelog) sehe ich nix. Es fällt nur auf das keine Events mehr rein kommen. Verbunden sind sie per Internet, die letzten Events die reinkommen sind aber zeitlich gesehen ungleich des Fritzbox-Reconnects
Verbunden sind sie per RAW

Deine Perl-Zeile habe ich im Webif ausgeführt, da kommt aber nix zurück??

Am Donnerstag, 7. Juni 2012 10:18:18 UTC+2 schrieb Rudolf Koenig:

> Aber nach ein paar wenigen Tagen empf�ngt mein Haupt-FHEM keine Daten mehr

[Rudolf Koenig]

> Deine Perl-Zeile habe ich im Webif ausgef�hrt, da kommt aber nix zur�ck??

Welche der beiden? Vor oder nach dem Neustart des Clients?

Haette gerne folgendes
- Server: Status-Perl
- Client: FHEM2FHEM_Disconnected
- Server: Status-Perl
- Client: Neustart
- Server: Status-Perl

[tobias.faust]

Ok,

auf dem Client kommt folgendes zurück wenn der Connect noch funktioniert.

192.168.10.37:50743/raw

Wenn die Verbindung abgebrochen ist melde ich mich wieder mit dem output des Scriptes, incl Neustart

[Willi]

On 7 Jun., 14:24, "tobias.faust" <tobias.fa...@gmx.net> wrote:
> mehr rein kommen. Verbunden sind sie per Internet, die letzten Events die
> reinkommen sind aber zeitlich gesehen ungleich des Fritzbox-Reconnects
> Verbunden sind sie per RAW

Verstehe ich richtig, dass die beiden FHEM-Instanzen per Internet
verbunden sind?
Dann verwendest Du zwei Internet-Anschlüsse?

Wenn die Internet-Anschlüsse dynamische IP-Adressen haben, Dein
Provider täglich eine Zwangstrennung mit Vergabe neuer IP-Adresse
durchführt und Du daher einen DynDNS-Dienst oder ähnliches verwendest,
ist die Situation klar.

Das das nicht genau zeitlich zusammenpasst, ist verständlich. Für den
Abbau einer TCP-Verbindung gibt es verschiedene Möglichkeiten
(Timeouts (sofern KEEPALIVE genutzt wird), ICMP-Pakete, etc.). Bis der
Rechner bei TCP merkt, dass etwas nicht stimmt, kann es ziemlich lange
dauern. Das kommt auch darauf an, wem Dein Provider die alte IP-
Adresse neu zuweist und wie der Router des neuen Kunden auf Deine TCP-
Pakete reagiert.

Das Scenario würde nur funktionieren, wenn Du Du zeitgesteuert die
FHEM2FHEM-Verbindung trennen und neu aufbauen würdest (mit neuer
Namensauflösung). Ob das FHEM2FHEM_Disconnected($defs{<F2F-
InstanName>} ausreicht und FHEM2FHEM die Namensauflösung erneut macht,
ist mir unklar (Rudi?). Eine genaue Synchronisation ohne Verlust von
Daten wird aber schwer.

Eine andere Alternative (meines Erachtens nach besser), wäre die
beiden Internet-Anschlüsse per VPN zu verbinden (z.B. OpenVPN oder
IPSEC) und diese Verbindungen so einzustellen, dass nach
Zwangstrennung die VPN-Verbindung schnell wieder aufgebaut wird. Die
Realisierung kommt darauf an, welches VPN-Protokoll Du verwendest.

Alternativ kannst Du auch die beiden Anschlüsse per IPv6 mit
statischer IPv6-Adresse verbinden. Dazu kannst Du einen IPv6-Tunnel-
Provider wie z.B. http://www.sixxs.net/ verwenden. Wenn ich es richtig
verstanden habe, müßte FHEM auch mit IPv6 zurecht kommen. Wenn nicht,
wird es sicherlich später mal gebraucht, so dass dies ein Anlass zur
Realisierung wäre.

[Rudolf Koenig]

> Ob das FHEM2FHEM_Disconnected($defs{<F2F- InstanName>} ausreicht und

> FHEM2FHEM die Namensaufl�sung erneut macht, ist mir unklar (Rudi?).

Wenn Willis Theorie korrekt ist, dann muesste das FHEM Client regelmaessig die
Verbindung testen, z.Bsp indem auf dem Client ein at alle 10 Sekunden auf dem
Server einen dummy aendert. Damit wuerde das Client OS ein Paket rausschicken,
und merken dass die Gegenseite weg ist. Ein Reconnect muesste dann die neue
Adresse holen, sofern dieser beim DNS Provider schon aktuell ist, und nirgendwo
gecached wurde.

Ich sehe mit so eine Verbindung zwei grundsaetzliche Probleme:
- Die Verbindung ist weder verschluesselt, noch wird ein Passwort verlangt,
deswegen ist VPN ratsam.
- Nach Zwangstrennung gibt es defintiv ein "Loch" (egal ob VPN oder anders),
da FHEM2FHEM keine Events puffert, damit muss man rechnen.

[tobias.faust]

Um etwas Klarheit zu schaffen, es sind zwar beide Instanzen per Internet verbunden, befinden sich aber im VPN. Sieht man auch, da der Client in meinem letzten Post die 192.168.10.37 als verbundene Instanz ausweist und keine öffentliche IP ;)

Der Client ist einer täglichen Zwangstrennung unterbunden, die Haupt-FHEM Instanz nicht.
Ich schaue morgen nochmal rein ob die Verbindung noch steht, die Zwangstrennung liegt gegen 3Uhr morgens

[tobias.faust]

Kurzer Zwischenbericht.
Verbindung war wieder weg. Rudis Perl Zeile hat auf dem Client keine Ausgabe gebracht. Nach einem { FHEM2FHEM_Disconnected($defs{"CUNO_Remote"}) } war die Verbindung wieder da und die PerlZeile auf dem Client gab auch wieder den Connectstring zurück.

Was ich nicht verstanden habe, wie soll ich vom Haupt-FHEM auf dem Client ein dummy ändern?? Wenn ich auf dem Client einen dummy anlege "define dummy dummy" und ich versuche auf dem Haupt-Fhem ein "set dummy on" so kommt nur lapidar "please define dummy first"

[Rudolf Koenig]

> Verbindung war wieder weg. Rudis Perl Zeile hat auf dem Client keine
> Ausgabe gebracht.

Das ist nett, mich interessiert aber der Server :) Zitat:

> - Server: Status-Perl
> - Client: FHEM2FHEM_Disconnected
> - Server: Status-Perl
> - Client: Neustart
> - Server: Status-Perl

> Was ich nicht verstanden habe, wie soll ich vom Haupt-FHEM auf dem Client

> ein dummy �ndern??

Auf dem Server ein FS20 oder HM Geraet anlegen, es mit attribut "dummy"
versehen. Geraet auf dem Client auch anlegen, und IODev dem FHEM2FHEM zuordnen.
Oder automatisch anlegen lassen. Jetzt kann man das Geraet auch auf dem Client
schalten. Kann sein dass ich irgendwo noch ein Denkfehler habe, habs nicht
getestet.

[tobias.faust]

{ my $r="";; foreach my $c (keys %client) { $r .= "\n$client{$c}{addr}/$client{$

c}{inform}" if($client{$c}{inform}) } ;; $r }

- Server: Status-Perl
  -> leere ausgabe
- Client: FHEM2FHEM_Disconnected
  -> ok
- Server: Status-Perl
  -> 192.168.10.37:42592/raw
- Client: Neustart
  -> ok
- Server: Status-Perl
   -> 192.168.10.37:36124/raw

Hoffe das war jetzt richtig...

[Rudolf Koenig]

> - Server: Status-Perl
> -> leere ausgabe

Das bedeutet, dass der Server den Client nicht mehr benachrichtigen will, ich
vermute er hat den Verbindungsabbruch schon entdeckt, und den Client komplett
entfernt. Der Client hat den Verbindungsbbruch dagegen nicht gemerkt, und
wartet geduldig.

Kannst Du bitte in 93_FHEM2FHEM.pm unter der Zeile
my $conn = IO::Socket::INET->new(PeerAddr => $dev);
die Zeile
setsockopt($conn, SOL_SOCKET, SO_KEEPALIVE, 1);
einfuegen, und nochmal testen.

Alternativ kann ein regelmaessig durchgefuehrter "set serverDummy on" (bei
richtig angelegten serverDummy) auch helfen.

[tobias.faust]

Diese Nacht ist die Conn wieder verloren gegangen. Habs jetzt eingefügt und beobachte ein paar Tage....

[tobias.faust]

Leider hat es nicht den gewünschten Erfolg gebracht. Gestern abend ist wieder die Verbindung abgebrochen. Falls das mit dem Dummy wert auch nichts bringt werde ich einfach die Zeiten der letzten Aktualisierungen prüfen. Wenn die irgendwann größer werden (i.d.R. größer 15min) soll ein reconnect erfolgen.

Trotzdem Danke! für die eingebrachten Ideen...