HMLAN disconnected, waiting to reappear

[marco82]

Hi

Leider komme ich einfach nicht weiter. Ich habe in meinem Log immer wieder disconnects vom HMLAN.
Das ganze schaut dann ca so aus:

Code Auswählen Erweitern


2013.06.24 00:17:04 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 00:17:14 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 00:29:02 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 00:29:12 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 00:56:23 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 00:56:35 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 01:05:24 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 01:05:35 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 01:08:34 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 01:08:42 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 01:32:34 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 01:32:42 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 01:41:31 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 01:41:44 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 01:53:29 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 01:53:39 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 02:05:24 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 02:05:34 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 02:32:44 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 02:32:54 1: 192.168.20.220:1000 reappeared (HMLAN1)
2013.06.24 03:08:57 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 03:09:07 1: 192.168.20.220:1000 reappeared (HMLAN1)


Ich habe das mal mit loglevel 5 mitgeloggt:

Code Auswählen Erweitern


2013.06.24 11:58:30 5: HMLAN_Send:  HMLAN1 I:K
2013.06.24 11:58:30 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:GEQ0208326 d:12D1E2 O:123ABC t:239FC955 IDcnt:0001
2013.06.24 11:58:55 5: HMLAN_Send:  HMLAN1 I:K
2013.06.24 11:58:56 5: HMLAN_Send:  HMLAN1 I:K
2013.06.24 11:58:57 5: HMLAN_Send:  HMLAN1 I:K
2013.06.24 11:58:58 5: HMLAN_Send:  HMLAN1 I:K
2013.06.24 11:58:59 1: 192.168.20.220:1000 disconnected, waiting to reappear
2013.06.24 11:58:59 5: Triggering HMLAN1 (1 changes)
2013.06.24 11:58:59 5: Notify loop for HMLAN1 DISCONNECTED
2013.06.24 12:00:03 1: 192.168.20.220:1000 reappeared (HMLAN1)

Wenn ich das richtig verstehe, wird genau nach 25 sekunden ein K an das HMLAN gesendet. So wie sich das darstellt, antwortet das HMLAN aber darauf nicht mehr. Bin ich hier auf dem richtigen Weg?

Ich würde als nächstes mal mitsniffen, was und ob in diesen Fällen übers Netzwerk geht.

Hat irgendjemand ein ähnliches Verhalten, oder stehe ich damit alleine?

LG

[UliM]

Hi,
Falls Du das WOL-Modul benutzt liegt es daran
Die ping-Zeit muss dort auf 1s begrenzt werden.
Workarounds:
- im Forum den entspr Post suchen und die Änderung selbst einbauen
- oder WOL erst mal nicht nutzen

Habe im Subforum 'Sonstiges' bereits gepostet, dass ich diesen fix einchecke, falls der Modulautor das bis Ende Juni nicht selbst tut.
Gruß Uli

[marco82]

Hi

Danke für die Antwort
Ich benutze das WOL Modul nicht. Wenn ich das aus den anderen Posts richtig verstehe, würde in diesem Fall nach 25s das Keep-Alive an den HMLAN nicht versendet werden, da fhem beschäftigt ist. Hier kann man aber sehen, dass es lt. Log genau nach 25s versendet wird.

LG

[martinp876]

Hi Marco,

Erst einmal hast du recht, der HMLAN will alle ~30sec ein 'k' sehen, daher schicken wir alle 25sec eines. Das wird ggf wiederholt, wenn wie bei dir keine Antwort kommt

Ich sehe das nicht so wie Uli, WOL kann es nicht sein. Das Problem mit dem '10sec ping' war, dass FHEM 10sec blockiert wurde. Dann kaeme aber das 'send K' nicht rechtzeitg - kommt aber. Auch die Antwort kann nicht in FHEM verbummelt werden, da die 'k' Wiederholungen ja kommen.

Waere also interesant an der ethernet-schnittstelle zu sniffern, ob eine Antwort zu sehen ist - oder aus irgendwelchen anderen gruenden das k nicht das Kabel erreicht ;-)

Sicherheitshalber: Das Problem besteht nicht erst seit gestern? Da habe ich abends eine neue HMLAN SW eingestellt.

@Uli,
wenn du die WOL SW aendern kannst, sollte dies keine Problem sein - der Entwickler hat aktuell keine Zeit und es sollte dir frei stehen.
Du solltest aber ueberlegen, ob die 1sec immer ok sind. Pings im Heimnetz sollten mit 1sec absolut reichen - aber auch beim Aufwachen? Ping ins Internet koennen auch einmal laenger dauern (daher der default von 10 sec). Alternative ist eine Impementierung mit 'blocking' und 10sec. Das sollte besser sein, da auch 1sec warten lange ist. Gut waere, alle pings in WOL zu sammeln undnur einmal zu forken. Sollte jemand auf die Idee kommen, viele devices zu 'WOLen' erzeugt das staendige forken und connected nicht unerheblich Last...

Gruss Martin

[Dietmar63]

Ich habe mit Boris zusammen eine Version von WOL mit Blocking.pm erstellt - finde ich sie aber nicht wieder.
Sie lief bei mir auf der FB nicht stabil, so dass ich alles wieder herausgeworfen habe.

Ich fahre WOL mit 1s - das läuft gut. Bei mir gibts aber auch kein HMLAN.

Ehrlich gesagt ist der Auwand nur für den ping, die Sache eigentlich nicht Wert. Wenn ich der Autor des Moduls wäre und entscheiden könnte, würde ich den ping und das Prüfen auf on/off eliminieren.

Im Thread NAS_CONTROL ist eine Version von WOL beschrieben und  veröffentlicht, die Buffalo-NAS wecken und wach halten kann.
Diese Version wollte ich irgendwann mal einchecken lassen, aber die Probleme mit ping bzw. HMLAN machen alle Versuche immer wieder zunichte.

Vielleicht ist es wirklich ersteinmal am Besten den ping auf 1s zu begrenzen - so viele Installationen von WOL gibt es nicht(90/1750), und auf den meisten Installationen werden WOL im lokalen Netz durchgeführt.

[marco82]

Hi Martin

Leider kann mein Switch mehr als ich gedacht hab ;-). Dachte ich schneid einfach mit, was am Port abgeht und krieg mit, wo das Problem sein könnte.
Nun, gesagt getan - das ist ein echter switch - der zeigt mir das nicht mal :(. Port Mirroring aufdrehn - naja, so viel kann er dann auch wieder nicht.

Da ich aus Gründen der Sicherheit das HMLAN und FHEM in einem eigenen VLAN habe ist das doch nicht so easy wie ich dachte.

Werde morgen das VLAN anpassen und den Traffic mitschneiden.

Ich bin gerade dabei meine Installation um ein RFID - Zutrittssystem zu erweitern (so wie wir das aus der Arbeit kennen). Wenn da Interesse besteht, dann kann ich die mal Dokumetieren, was ich schon habe.

LG
Marco

[martinp876]

@Marco
switches machen alle mac-filtering - meussen sie ja auch bei bei automaticher speed-Einstellung. Die guten alten hubs ohne mac-fltering sind alle 10MBit.
Und manuelle Konfiguration mit mirriring ist dann erst wieder in einer Klasse hoeher zu finden.

Aber evtl kann man es auch einfacher machen - es ist ja nicht davon auszugehen, dass eine message verloren geht - deine switches sind alle gebuffered und kollisionen sind seit twisted pair wohl Geschichte. Daher kannst du auch an der Zentrale monitoren. Ein wireshark oder auch etwas einfacheres sollte genau genug sein.

Falls du deine RFID fertig hast wuerde es mich einmal interressieren.

@Dietmar63
Blocking.pm hat einen guten Ansatz und ist genial einfach, hat aber mehrere Nachteile (nicht alle auch liegen direkt an Blocking sondern an der Handhabung)
a) man neigt dazu dies fuer jede Entity zu starten. Das koennen ggf unangemessen viele Prozesse sein. Man sollte versuchen dies Zusammenzufassen. Im Falle von WOL wuerde es Sinn maachen alle notwendigen Pings des WOL moduls in einem Process auszulagern.
b) Nach jeweils einem "Durchgang" wird der Prozess getoetet. Besser waere mit WOL einen Prozess zu starten und den immer laufen zu lassen. Dort werden dann alle langsamen Aufgaben bearbeitet.
c) jeden rueckmeldung erfolgt ueber ein login. Besser ist, einen IPC socket zu nutzen.

a) und b) kann man erstellen mit dem aktuellen Blocking Ansatz. Evtl etwas tuning.
c) ist etwas komplexer, das muss sich dann in fhem.pl wiederspiegeln.

So ein Ansatz sollte dann auch stabil laufen - und das OS nicht unangemessen mit forken und connecten belasten. Ich habe etwas damit experimentiert aber noch nicht geschafft, den socket fehlerfrei in allen fehlerfaellen zu bedienen. Ausserdem habe ich noch kein Konzept, wie man es einfach allgemeingueltug einbauen kann...

Die pings auf 1sec zu begrenzen ist nur ein workaround. Dir bleiben einigen offene Punkte:
- reaktionszeiten auf Useraktionen (lichtschalter) werden ggf um 1sec verzoegert
- Protokoll-abbrueche bei wakeup und Config devices koennen stattfinden (1sec warten ist zu lang)
- falls du mehr Devices ueberwachst erhoeht kommt die 1sec oefter vor und kann sich u.U. addieren.
=> bei einem WOL device ist die 1sec ein pragmatischer, einfacher und schneller Ansatz.



Gruss Martin

[marco82]

Hallo zusammen

Ich habe nun einen einfachen Weg gefunden, die Kommunikation mitzuschneiden - und es scheint tatsächlich, dass der HMLAN einfach nicht mehr antwortet:

(http://s16.postimg.org/bsrzfg2p1/HMLAN.jpg)

auf das FIN danach reagiert der HMLAN hingegen sofort.

Hat jemand eine Idee dazu?

LG
Marco

[martinp876]

Hi Marco,

den mitschnitt sieht nach wireshark aus. kannst du den kompletten trace schicken? Kann/sollte auf die IP adresse des HMLAN gefiltert sein (src|dst)
Der Paket inhalt ist so nicht sichtbar.
Gut waeren ein paar Packets aussen herum - wenn es noch geht bis es wieder geht
Gruss Martin