Archiv verlassen und diese Seite im Standarddesign anzeigen : Fataler crash im Homeserver
Hallo Bruno,
im EIB-Monitor zeichnet der HS alle eingegenden und ausgehenden EIB-Telegramme auf.
Bis zu 50.000 Telegramme können im Ringspeicher aufgezeichnet werden.
Per Browser oder e-Mail kann man die Daten bekommen.
Es gibt eine chronologische (auf-/absteigende) Liste oder eine strukturierte Liste zur Analyse.
Damit sollte man sehr schnell den Fehler finden.
__________________
Gruss
Oliver Herrmann
DaCom Database Computing GmbH
www.dacom-homeautomation.de
Diesen Rat habe ich befolgt und das war wohl ein riesen Fehler!
Nach der Änderung auf 50.000 ging erstmal (bis auf lange Ladezeiten) alles klar. Bei der nächsten Änderung (nur ein Parameter an anderer Stelle geändert. Ist nach dem Laden (Hochlauf vom HS) der HS tot.
Er kommt nicht mehr hoch und ist über LAN nicht mehr ansprechbar. Nach Änderung auf serielle Schnittstelle und Spannung ein aus kann ich ihn zwar ansprechen und laden. Er bleibt aber immer hängen und kommt nicht mehr hoch. Erst nach Remanetspeicher löschen ist er wieder über serielle Schnittstelle ansprechbar.
Ich habe es nicht glauben wollen und 2 mal reproduziert. Das ganze wäre ja zu verkraften. Wenn nicht alle Daten Futsch wären. Meine Schönen Archive und Einstellungen.
Das Archivieren des Remanentspeichers auf PC und Rücktransfer ist wohl eines der dringensten Funktionen die dem HS fehlen. Da ich dies jetzt mehrfach hintermich gebracht habe (u.a. beim Versionswechsel auf V2) wäre dies mein dringenster Wunsch für ein neues Update.
Ich gehe davon aus das hier ein Speichüberlauf nicht abgefangen wird, so dass ich jetzt die Befürchtung habe, dass dies mit anderen Einstellungen auch passieren kann?
Gruß Bruno
Hallo Bruno,
das tut mir echt leid. Aber was willst du mit 50.000 Telegrammen? Ich habe so ~ 3.000 Telegramme / Woche.
Bis zu 50.000 Telegramme können im Ringspeicher aufgezeichnet werden.
Diese Aussage bezieht wohl auf das maximal mögliche; ohne Steuerungsfunktionen, Menü oder Visu. Ich schätze das der Speicher nicht dynamisch verwaltet wird, sondern sofort Platz für die 50.000 Telegramme reserviert wird. Dann hast Du natürlich keinen Platz mehr, wenn z.B. statt einem 1 Bit Objekt dann z.B. ein 14 Byte Objekt gespeichert werden soll.
Aber Du hast Recht, das Exportieren der Archive, besonders der Anwesenheitssimu, und die Möglichkeit zum Rückspeichern fehlt mir auch.
Mal sehen was morgen abend beim Stammtisch an Info´s zu dem Thema kommt. Du bist doch dabei?
Wäre mal interessant zu erfahren was der HS mit seinen 32 MB Flash alles so treibt - bzw. wie der HS diesen Speicher verwaltet. Was steht netto (nach OS) zur Verfügung, ist Speicher für bestimmte Anwendungen reserviert? Wieviel Speicher darf ich nutzen z.B. für Grafiken, Visu u.s.w. Prüft der HS-Experte vor dem Programmieren ob der Speicher im HS reicht?
Und wenn ich schon gerade so am Fragen bin:
Dass der Port 80 im Standard offen ist verstehe ich ja einigermassen.
aber:
Port 68 - Bootstrap Protocol Server
Port 69 - TFTP
Port 123 - NTP
Port 137 - NetBIOS NameServer
Port 161 - SNMP
Port 445 - MS CIFS
Port 520 - Router RIP
Port 1167 - Phone
Port 1512 - WINS
Port 2049 - NFS-Daemon
Was soll denn das bitte werden? So eine nette Auswahl von Exoten habe ich schon länger nicht mehr gesehen. SNMP könnte ich ja nocht verstehen - wenn man denn damit aus dem HS wirklich Infos bekommen würde, der HS erzählt mir da leider nichts (ich hatte mich schon gefreut dass ich meine langfristigen Statistiken mit MRTG machen könnte).
Warum läuft da permanent ein RIP?
Was tut der TFTP im HS? Und wenn er denn was tut - muss es denn wirklich TFTP sein? Was unsichereres gibt es wohl kaum.
137 ist auch kein Stück besser - und was soll auf einem HS ein WINS?
Fragen über Fragen.
Hi Michael
die 50000 Telegramme habe ich in drei Stunden voll.
Das heisst ich habe bei Fehler maximal 3 Stunde Zeit zu Checken.
Auf diese Werte kommst Du durch zyklisches senden bei Alarmanlage über EIB und jede Menge Teilnehmer (120). Das mit der Alarmanlage (Merten) gefällt mir auch nicht, lässt sich aber nicht ändern da Überwachungszeiten laufen die ich alle schon auf max. gestellt habe. Ich halte dies für absolut Überflüssig. So eine Überwachung reicht doch voll aus wenn man das im Minutenbereich macht. Ich kann hier max. 15 Sekunden einstellen. Unter der Annahme, dass mal ein Telegramm verschluckt werden kann sende ich alle 6 Sekunden. Das sind 600 pro Fenster in der Stunde mal 15 Fenster und Türen und da läuft sonst noch nichts.
Ich war ja heute schon im Chat wie Du weist:confused:
Ich hasse zyklisches Senden ;)
Sorry, wenn ich drin war und dich nicht gesehen habe. Der neue Server lief heute auch "unbewacht", um die Stabilität für den morgigen "Ansturm" und den Server-Push Modus zu testen:
alles paletti, kein Kick und super Antwortzeiten.
Da kommt ja das Special wohl genau zur richtigen Zeit :D
die 50000 Telegramme habe ich in drei Stunden voll. Das heisst ich habe bei Fehler maximal 3 Stunde Zeit zu Checken.
Da würde ich doch glatt alle 10 Minuten das den Monitor per FTP wegspeichern, z.B. als CSV. Damit kannst Du dann a) die Auswertung schön exceln, b) musst Dich nicht hetzen wegen der 3 Stunden und c) belastest Du den HS nicht mit "unnötigem" Datenmüll. Die 50.000 Telegramme bestehen ja wohl offensichtlich überwiegend daraus, oder?
CHAT?
Original geschrieben von Michel
Dann hast Du natürlich keinen Platz mehr, wenn z.B. statt einem 1 Bit Objekt dann z.B. ein 14 Byte Objekt gespeichert werden soll.
Es ist doch mit Verlaub - Schwachfug - im Jahr 2003 ein System mit 32 MB Speicher auszuliefern. Sicher ist der HS durch das zugrundeliegende Konzept in seiner Hardware etwas limitiert. Wenn man auf Festplatten verzichten will / muss bleibt nicht mehr viel - aber dann eine 32 MB Flashkarte einzubauen ist - meiner Meinung nach - auch nicht gerade eine Grosstat. Dass 32 MB nicht wirklich weit reichen war in der IT-Branche schon um 1985 bekannt.
Wenn man schon so sparsam mit dem Speicher ist sollte man wenigstens dafür sorgen dass die Speicherverwaltung funktioniert - und dann dürfte es nicht passieren dass der HS die Flügel streckt wenn der Speicher zuläuft.
Exception handling sollte das System machen, nicht der User.
Gruss
Markus
Hallo MarkusS
------------------
Ich habe es gerade nochmal bei uns mit NMAP überprüft:
Nur der Port 80 ist am HomeServer offen.
So sollte es auch sein.
Kann es sein, das du in deinem Projekt diese Ports für IP-Telegramme geöffnet hast ??
Hallo Bruno
---------------
Normalerweise sollte das nicht passieren.
Ich denke aber nicht, das es sich um einen Speicherüberlauf handelt.
Kannst du mir das Projekt vielleicht an
ph [at] dacom-homeautomation.de
senden?
Wir werden der Sache dann nachgehen.
Original geschrieben von PeterH
Ich habe es gerade nochmal bei uns mit NMAP überprüft:
Nur der Port 80 ist am HomeServer offen.
So sollte es auch sein.
Kann es sein, das du in deinem Projekt diese Ports für IP-Telegramme geöffnet hast ??
Nein.
Der Bereich "Netzwerk" im HS-Experten ist bei mir noch jungfräulich.
Ich habe den GFI NSS v3.3 verwendet, NMAP kann ich aber auch gerne nehmen:
C:\Programme\nmap>nmap -v -sU 10.100.1.120
Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host homeserver.mms-it.de (10.100.1.120) appears to be up ... good.
Initiating UDP Scan against homeserver.mms-it.de (10.100.1.120)
Too many drops ... increasing senddelay to 50000
Too many drops ... increasing senddelay to 100000
Too many drops ... increasing senddelay to 200000
Too many drops ... increasing senddelay to 400000
Too many drops ... increasing senddelay to 800000
....
The UDP Scan took 1556 seconds to scan 1468 ports.
Adding open port 69/udp
Adding open port 161/udp
Adding open port 275/udp
Adding open port 520/udp
Adding open port 554/udp
Adding open port 28910/udp
Adding open port 718/udp
Adding open port 912/udp
Adding open port 1391/udp
Adding open port 1024/udp
Adding open port 1025/udp
Interesting ports on homeserver.mms-it.de (10.100.1.120):
(The 1460 ports scanned but not shown below are in state: closed)
Port State Service
69/udp open tftp
161/udp open snmp
275/udp open unknown
520/udp open rip
554/udp open rtsp
718/udp open unknown
912/udp open unknown
1024/udp open unknown
1025/udp open blackjack
1391/udp open iclpv-sas
28910/udp open heretic2
Nmap run completed -- 1 IP address (1 host up) scanned in 1557 seconds
Da wo die "...." stehen habe ich paar hundert Zeilen Statusmeldungen rausgeschnitten.
Mit NMAP kriege ich ausser den Port die GFI NSS findet auch noch ein paar andere - ich habe die Scans dreimal über den HS laufen lassen und das Ergebnis war jedesmal ähnlich.
GFI scannt nur auf eine vordefinierte Portliste.
Gruss
Markus
Matthias Schmidt
26.11.03, 12:29
Hallo Markus,
Zwischenfrage:
Hängt Dein HS direkt am Netz oder hinter einem Router?
Hallo MarkusS
------------------
Ein "offener" UDP-Port bedeutet nur, das der HomeServer dieses Paket nicht beantwortet.
Der HomeServer beantwortet die Pakete normalerweise mit einem ICMP-Error.
Um sich aber vor den Attacken eines Portscanners zu schützen wird die Antwortrate begrenzt. (RFC 1812)
Der Portscanner reduziert wiederum ebenfalls seine Geschwindigkeit.
Je nach Netz und Netzlast werden dann einzelne Scans nicht mit einem ICMP-Error quittiert und vom Scanner als "offener" Port bezeichnet.
Am HomeServer ist aber definitiv kein UDP-Port offen oder mit einem Service verbunden.
Wenn du den HomeServer und deinen Rechner direkt verbindest, dann meldet auch NMAP mit deinen Einstellungen keinen angeblich offenen Port.
Der HS (10.100.1.120/16) ist im gleichen Netz wie mein Notebook (10.100.1.5/16). Router / Firewall habe ich nur nach draussen.
Gruss
Markus
Hallo smarteib,
ich habe seit Ende letzter Woche das vermutlich gleiche Problem, war aber nicht so schlau das auf die Vergrößerung des Ringspeichers auf 50.000 beim EIB-Mon zurückzuführen. Ich hatte zuerst auf 50K erhöht - die Übertragung des Projekts lief da noch einwandfrei. Danach fügte ich eine Logikfunktion inkl. Archiveintrag hinzu und schon verlängerte sich die Übertragungszeit per Netzwerk von PC zu HS von ca. 45 sek. auf über 10 min.!
Als Lösungsversuch hab' ich dann die Programmerweiterung rückgängig gemacht und den Ringspeicher erheblich verkleinert, das hat aber gar nix gebracht. Hab' ich das richtig verstanden, daß sobald ich den Remanentspeicher lösche, alles wieder normal ist? Und kann jemand sagen wie gross denn der Ringspeicher für den Eib-Mon dann maximal sein darf - ohne Probleme zu verursachen?
Habe jedenfalls daraufhin die Gira-Hotline bemüht, die daraufhin mein Projekt angefordert haben um zu analysieren. Hab' noch keinen Lösungsvorschlag bekommen, werde aber mal die Ringspeicher-Thematik ansprechen.
Gruß,
Eric
Als Lösungsversuch hab' ich dann die Programmerweiterung rückgängig gemacht und den Ringspeicher erheblich verkleinert, das hat aber gar nix gebracht. Hab' ich das richtig verstanden, daß sobald ich den Remanentspeicher lösche, alles wieder normal ist?
Hallo Eric,
es war bei mir genauso. Ringsspeicher verkleinert Remanentspeicher löschen und neu hochfahren. Allerdings kam ich nicht mehr über LAN an den HS sondern mußte meine serielle Schnittstelle wieder anschmeissen) Also Rechner wieder aus dem Keller Kabel wieder suchen usw. Ich hatte die Hoffnung, dass ich das vergessen kann mit seriell und so.
Die 10 Minuten scheinen normal zu sein braucht meiner auch und Dacom hat mir gerade diese 10 Minuten auch bestätigt. Melde dies doch DACOM die Gira Hotline kann da eh nichts machen.
10 Minuten und länger kannst Du natürlich zum programmieren vergessen (noch ein kleiner Fehler drin, nochmal laden sind schon 20).
Gruß Bruno
Hi Bruno,
danke für die schnelle Antwort. Hmpf, Remanentspeicher löschen macht keinen Spass.... alleine die Zeitschaltuhren wieder herzustellen.... :-(
Naja, was sein muss, muss sein. Ich hoffe es gibt bald 'nen Bugfix oder ähnliches.
Gruß,
Eric
P.S. Mir ist gerade wieder eingefallen, dass ich in der Debug-Liste unter "Exceptions" folgende Meldung finde, die möglicherweise damit zu tun hat:
26.11.2003 17:17:01 (2)
File "/hs/compile/hs_eib.py", line 1309, in setzeZeit
IndexError: list index out of range
Vielleicht kann jemand etwas damit anfangen....
Hallo Leute,
wir haben das Problem mit den langen Startzeiten des HomeServers anhand des Projektes von Bruno bei uns nachgestellt.
Es liegt daran, das der HomeServer beim Starten mit sehr grossen EIB-Monitor-Speichern sehr lange braucht.
Abhilfe schafft die Verkleinerung des EIB-Monitor-Speichers auf z.B. 5000 Einträge.
Dies hat entgegen den Vermutungen in diesem Forum nichts mit der Speichergrösse oder einem Speicherüberlauf zu tun.
Dieser würde selbstverständlich vom HomeServer überwacht und verhindert.
Der Grund liegt in einer Integritätsprüfung der Daten beim Laden.
Die Archive haben feste Satzgrössen und werden deshalb sehr schnell eingelesen.
In der EIB-Monitor-Liste sind die Datensätze aber unterschiedlich lang, da jedes EIB-Telegramm eine andere Länge haben kann.
Ich denke 5000 Einträge in der EIB-Monitorliste reichen auch zur Fehlersuche aus.
Man kann sich ja z.B. die Liste regelmässig zumailen lassen.
Wenn man dann noch einen Trigger auf das zu überwachende Telegramm legt, welcher diesen EMail-Versand auslöst, kann man sehr gut Debuggen.
Wie gesagt, dies betrifft nur die EIB-Monitorliste und hat nichts mit den anderen Archiven zu tun.
Es liegt daran, das der HomeServer beim Starten mit sehr grossen EIB-Monitor-Speichern sehr lange braucht.
Wieso braucht er einmal 10 Minuten und beim nächsten laden ist er nach 30 Miniten noch nicht fertig. Nach 30 Minuten Ladezeit glaubt auch der letzte nicht mehr an den Homeserver.
Ausserdem sah das nach einem Timeout aus bei der prod.dat.
Also ich denke das mit dem Problem gefunden ist etwas voreilig.
Gruß Bruno
Original geschrieben von PeterH
Ein "offener" UDP-Port bedeutet nur, das der HomeServer dieses Paket nicht beantwortet.
Der HomeServer beantwortet die Pakete normalerweise mit einem ICMP-Error.
Um sich aber vor den Attacken eines Portscanners zu schützen wird die Antwortrate begrenzt. (RFC 1812)
Der Portscanner reduziert wiederum ebenfalls seine Geschwindigkeit.
Je nach Netz und Netzlast werden dann einzelne Scans nicht mit einem ICMP-Error quittiert und vom Scanner als "offener" Port bezeichnet.
Am HomeServer ist aber definitiv kein UDP-Port offen oder mit einem Service verbunden.
Wenn du den HomeServer und deinen Rechner direkt verbindest, dann meldet auch NMAP mit deinen Einstellungen keinen angeblich offenen Port.
Ich habe hier ein geswitchtes Netz vom Allerfeinsten, meine Paketverluste liegen laut meiner Überwachungssoftware (Cisco Works) bei Null - genauso wie die Switchauslastung, irgendwie schaffe ich es nicht den Cisco Catalyst mit meinem Heimnetz auch nur auf fünf Prozent zu bringen.
Trotzdem werde ich die Variante mit dem Crossoverkabel in den nächsten Tagen mal testen.
Deiner Argumentation kann ich so leider nicht folgen. Wenn Du "Recht" hättest müsste ich eine erratische Verteilung der "offenen" UDP-Ports kriegen, was ich aber sehe sind im Grossen und Ganzen immer dieselben offenen Ports?!
Ich werde nächste Woche mal den NAI Sniffer auf den HS loslassen, dann sehe ich ob auf den fraglichen Ports tatsächlich keine Antwort kommt.
Gruss
Markus
Jetzt habe ich auch diese Meldung in der DEBUG Seite.
01.12.2003 09:04:26 (1)
File "/hs/compile/hs_time.py", line 1384, in saveEibMon
IndexError: array assignment index out of range
Das sieht aber sehr nach einem Fehler im HS aus! Der EIBMonitor steht jetzt bei 15000
Gruß Bruno
Hallo Bruno,
du scheinst dich vom HomeServer verfolgt zu fühlen ;-)
Aber deine Paranoia ist unbegründet.
Die Meldung besagt nur, das beim Starten des HomeServers bereits Telegramme eintreffen,
bevor die EibMon-Daten aus dem Flash geladen sind.
Dies wird sauber vom HomeServer gehandelt.
Generell bedeutet "Eception" nicht Fehler, sondern eine Situation auf die ein Programm reagiert.
Also nichts für ungut.
Hallo PeterH,
mein HS generiert seit 2 Wochen folgende Meldung:
04.12.2003 14:56:47 (4)
File "/hs/compile/hs_eib.py", line 1309, in setzeZeit
IndexError: list index out of range
Die Gira-Hotline schickt mir leider keine Antwort hierzu.
Und dankbar bin ich auch wenn mir jemand einen Tipp geben kann was folgender Auszug aus der Debug-Liste bedeuten könnte:
Wait-List
Timestamp 1070558776.48
Anzahl 11
11.6949449778 Logik: 15, BS: 9027
11.6957839727 Logik: 16, BS: 9027
11.696631074 Logik: 17, BS: 9027
11.697527051 Logik: 18, BS: 9027
11.6984570026 Logik: 19, BS: 9027
11.6994390488 Logik: 20, BS: 9027
11.7082248926 Logik: 22, BS: 9027
26.7403589487 Archiv: 1
26.7408200502 Archiv: 2
26.7412559986 Archiv: 3
Konkret interessiert mich auf was Logik 15-22, BS: 9027 hindeuten könnte.
Danke & Grüsse,
Eric
Hallo Eric,
hast Du jetzt auch eine Paranoia?:p
zu der ersten Meldung kann ich nichts sagen. Die Wait-List dürfte nur anzeigen, wie Zeitaufträge ablaufen.
Gruß Bruno
Hallo Eric,
Wait-List
Timestamp 1070558776.48
Anzahl 11
Ist die Warteliste. In diesem Fall warten 11 Aufgaben darauf, abgearbeitet zu werden und zwar in 11,x Sekunden nach dem o.g. Timestamp bzw. 26,x Sekunden nach dem Timestamp.
Logik: xx ist IMHO die fortlaufende Nummer in der Logik des Experten.
BS: 9027 kennzeichnet den Logikbaustein Betriebsstundenzähler. Diese Nummer findest du übrigens in der Hilfe des Experten unter der Beschreibung des jeweiligen Logikbausteins.
Die letzten 3 Tasks sind anstehende Archiveinträge, die von dir irgendwie angestossen werden (z.B. Temperaturüberwachungen etc.).
Was die Fehlermeldung genau besagt, weiss ich leider auch nicht. Es deutet in Verbindung mit den Betriebsstundenzählern darauf hin, daß du vielleicht Daten in ein von dir angelegtes internes Kommunikationsobjekt mit falschem Typ schreiben willst (1 Byte Daten in 1 bit Objekt). Prüf mal deine Logik genau.
Der Timestamp zeigt, daß dein HS schon recht lange läuft. Bei den ganzen Betriebsstundenzählern und Archiven könnte es auch sein, daß deine Objekte für den Betriebsstundenzähler Werte speichern müssen für die der Objekttyp nicht geeignet ist (z.B. BS > 65535). Dann musst du diesen Objekte im Experten einen geeigneten Datentyp (EIS) zuweisen.
Hallo Cygnus,
die Sache mit der Warteliste hat Michel bereits super erklärt.
Das mit der Exception bedeutet, das der Homeserver auf einer Datum/Zeit-Gruppenadresse ein EIB-Telegramm bekommt welches nicht diesem Format entspricht.
Prüfe also mal deine Gruppenadressen auf EIB und/oder HomeServer-Seite.
Hallo Bruno, Michel & PeterH,
danke vielmals für Eure Hilfe!
Das mit der Wait-List ist jetzt klar - dachte zuerst, das dies auf eine Busüberlastung hindeutete....
@PeterH:
---------------------------------------------------------------------------------
"Das mit der Exception bedeutet, das der Homeserver auf einer Datum/Zeit-Gruppenadresse ein EIB-Telegramm bekommt welches nicht diesem Format entspricht.
Prüfe also mal deine Gruppenadressen auf EIB und/oder HomeServer-Seite."
---------------------------------------------------------------------------------
Hab' ich jetzt überprüft. Ich habe bislang das Flag "Beim Starten Abfragen" sowohl bei Datum als auch bei Zeit gesetzt. Wenn ich das Flag lösche verschwindet auch die Fehlermeldung.
Ich habe eine ABB Funk-Jahresschaltuhr mit DCF-77 Antenne. Im HS-Projekt habe ich unter Zeitabgleich entsprechend "...von EIB empfangen" ausgewählt. Nach dem HS-Start empfängt der HS lt. EIBMon jede Minute die Objekte Datum und Uhrzeit. Das scheint zu funktionieren. Auf meinem Gira MT-701 und dem Gira Info-Display 2 werden Datum und Uhrzeit korrekt ausgegeben. Das Datenformat der GAs scheint zu stimmen. Nur der HS - "Scan bei Start" löst wohl diesen Fehler aus? Kann das sein?
Gruss,
Eric
Hallo Cygnus,
wenn die Jahreszeitschaltuhr zyklisch sendet, braucht man nicht "Scan bei Start" einzustellen.
Mit "Scan bei Start" werden Datum/Zeit vom HomeServer aktiv angefordert. Dazu muss das Leseflag bei der Uhr gesetzt sein.
Ansonsten müsste man mal aufzeichnen, was die Uhr bei einer Abfrage auf den Bus sendet.
Aber wir gesagt, eine Abfrage ist in diesem Fall nicht nötig.
Hallo Peter,
Lese-Flags waren entsprechend gesetzt. Ich zeichne mal auf zwecks Überprüfung. Einstweilen vielen Dank für die Hilfe.
Gruss,
Eric
Powered by vBulletin® Version 4.2.4 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.