- √ - Bus stürzt ab hängt sich auf

[Loxone]

@Tessi - sehe ich genauso - auch ich würde zuerst hier ansetzen. Ich will auch gar nicht ausschließen, dass der Miniserver daran Schuld hat.

Fehler passieren - sie müssen halt schnell ausgemerzt werden.

Grüße,
Florian

[Tessi]

Man muss dazu noch sagen: Wenn auf einem Bus wie EIB Kollisionen auftreten (zwei Teilnehmer senden gleichzeitig) dann wird ein Verfahren zur Lösung des Problems genutzt: z.B. schweigen die Teilnehmer für eine zufallsbasierte Zeit und wiederholen dann ihr Diagramm.

Das wird bei Ethernet so gemacht, KNX nutzt wie CAN ein Arbitrierungsverfahren (CSMA/Clarification required. siehe: Carrier Sense Multiple Access/Collision Resolution und Europäischer Installationsbus), bei dem im Konkurrenzfall das Telegramm mit der höheren Priorität unbeschadet übertragen wird, während das andere warten muß.

mir wurde gesagt es wird hier teilweise darauf gewartet einen Übeltäter zu finden.

Das ist jetzt bestimmt nicht persönlich gemeint. Es ist nur so, das bei einem offensichtlich überlasteten Bus logischerweise zuerst jene Geräte untersucht werden, die grundsätzlich gut geeignet sind, dies zu bewirken. Das sind dann Kandidaten wie Miniserver, WireGate, EibPC, HomeServer und ähnliche, vor allem, da sie von Endanwendern programmiert werden und dabei leicht Fehler unterlaufen.
Sicher, bei einem Hardware-Defekt kann jedes Gerät den Bus zumüllen, aber wahrscheinlicher sind halt Konfigurationsfehler und die wiederum bei oben genannten Geräten. Mit Übeltäter ist da ganz sicher nicht der Hersteller gemeint, es soll nur einfach erst einmal die Störquelle lokalisiert werden, danach kann man dann untersuchen, warum sie stört, und dann, aber eben erst dann kann man ggf. noch den Verantwortlichen ermitteln. Und bei oben genannten Geräten ist das nur allzuoft der Betreiber selbst.

[Loxone]

Hallo,

Hier mal ein Statement von unserer Seite - mir wurde gesagt es wird hier teilweise darauf gewartet einen Übeltäter zu finden.

In unserem Labor wird schon heftig getestet - leider konnten wir den Fehler noch nicht reproduzieren. Wir sind aber in stetigem Kontakt mit zalva, werden den Fehler finden und wenn das Problem in unserer Sphäre liegt werden natürlich auch rasch beheben.

Grüße,
Florian

[rb84]

so geheim ist die sache nun auch wieder nicht...

http://freebus.org/images/stories/do...rammaufbau.pdf

Ja, das ist der Aufbau des Telegramms.
Das hilft in so einem Fall wenig weiter.

Mehr Sinn macht eine exakte Systembeschreibung. Ok, klar, man kann das schon "rausfinden".
Ich finde es aber bequemer, wenn Diagramme, Formeln usw. zusammengestellt vorliegen, die die Schicht 1 + 2 beschreiben...

so geheim ist die sache nun auch wieder nicht...

http://freebus.org/images/stories/do...rammaufbau.pdf

[rb84]

Eine Drossel oder ein "Wackelkontakt" kann durchaus eine "Datenübertragung" verursachen!

Das kann JEDER Teilnehmer verursachen, sowie JEDE Klemme und es kann auch passieren, wenn das Kabel neben einem anderen Kabel liegt und der Schirm ein Problem hat.

Die Spezifikation ist nicht offen, so kann ich kein Beispiel vorrechnen.
Aus einem anderen Bus-Projekt: Das passierte tatsächlich, durch ein Schirmproblem wurden Signale in den Bus induziert.

Nach Transformation in Binärcode kam dann eben etwas wie "0110 0111" raus, wobei hier (Beispiel) das erste Byte als Adresse und das zweite Byte als Daten zu werden war!

Der Witz war allerdings noch schlimmer: Nehmen wir noch ein weiteres Bit dazu, welches eine Checksumme darstellen soll.
Statistisch gesehen kann man sagen, dass in JEDEM Fall die Checksumme falsch sein wird. Auf jede Checksumme reagierten die Teilnehmer mit Nachfragen -> Das System "stürzte ab".

Man muss dazu noch sagen: Wenn auf einem Bus wie EIB Kollisionen auftreten (zwei Teilnehmer senden gleichzeitig) dann wird ein Verfahren zur Lösung des Problems genutzt: z.B. schweigen die Teilnehmer für eine zufallsbasierte Zeit und wiederholen dann ihr Diagramm.

Das wird jedoch bei einem Hardwareschaden IMMER fehlschlagen (der "Gestörte" sendet ja permanent)! Der Bus stürzt ab!

[zalva]

ist das Problem gelöst?

Hallo Klaus,

nein gelöst noch nicht. Konnte durch ändern der Pollingwerte die Wahrscheinlichkeit verringern eine Ueberlast zu bekommen.
Kurzum, der Verkehr ist weniger, dadurch habe ich im Moment (nur) noch ein-zwei mal am Tag einen Hänger.

An den Herstellern von Wiregate und Miniserver (loxlive) meinen allerherzlichsten Dank für den schnellen und super Support.

Mit Makkis Hilfe konnten viele potentielle Fehlerquellen ausgeschlossen werden und festgestellt werden, dass bei den Hängern mit einem Schwung (zu)viele? Telegramme in kurzer Zeit auf den Bus kommen.

Florian von Loxone hat sich sofort bei mir gemeldet, habe meine Konfiguration hingeschickt diese wird jetzt auseinandergenommen und ich stehe mit Herrn Nader (Entwickler) in Kontakt.

Sobald die Ursache gefunden wurde und die Lösung kommt werde ich diese hier posten

Gruss
Salvatore

[klaus407]

Hallo,
ist das Problem gelöst?

[Norbe]

eine Drossel hat keine GA...

...

Das ist soweit schon richtig, aber ich hatte tatsächlich schon den Fall, dass eine defekte Sapnnungsversorgung mir den Bus mit irgendwelchem undefinierten Telegrammschrott zugemüllt hat, was ich ohne EIB-Doktor und abklemmen aller Geräte der Linie auch nicht gefunden hätte.
Ich würde die Möglichkeit daher zumindest nicht ausschliessen.

[zalva]

abgemacht.
Bis morgen früh dann.

Gruss
Salvatore

[makki]

Wie kann ich ein Routing loop identifizieren?

Schwer zu erklären aber einfach zu sehen Ich hab einen Verdacht aber:
Lass mich morgen mal per Wartungs-VPN draufschauen, mit tcpdump, busmonitor & Co ist schnell gefunden, wo was herkommt und hingeht.

Makki

[zalva]

Zu früh gebrüllt Löwe

hatte soeben wieder einen Absturz (siehe Anhang) sehe halt kein nak
das hier --> 0.6.128,7.8.152 sind z.B. keine gültigen Adressen (allerdings bin ich in der ganzen Thematik immer noch nicht so fit wie ich gern wäre).

Alles abklemmen,
...

Wenn Du willst, ruf morgen mal an, man kann im WG mit TP-UART (manuell auf der Konsole) auch einen rein passiven - ziemlich rohen - Busmonitor starten.
...
Makki

Edit: ich tippe auf eine Routing-loop. Fritzbox?

a.)
Alles abklemmen nicht gerade so einfach, heisst auch alles aufmachen oder entklemmen im Kasten (wenn nichts anderes mehr hilft)

b.)
nehme das Angebot mit dem Anruf morgen gerne an, thnx.

c.)
Fritzbox, ja, gekappte von der Telekom (SDSL-Router habe Bezeichnung gerade nicht zur Hand)

Wie kann ich ein Routing loop identifizieren?

Gruss
Salvatore

[makki]

Alles abklemmen, ausschliessen kann man nichts, ich hatte schonmal einen LV der bei mehr als 3-4 tps ständig NACKs versendet hat.

Wenn Du willst, ruf morgen mal an, man kann im WG mit TP-UART (manuell auf der Konsole) auch einen rein passiven - ziemlich rohen - Busmonitor starten.
Dann geht zwar von der WG-Funktion nichts mehr aber damit kann man es a) ausschliessen und b) sehen was wirklich am Bus los ist.
Der gepostete Screenshot vom "KNX Analyzer" ist heavy-beta, also die Kuchen müssen nicht unbedingt stimmen.

Makki

Edit: ich tippe auf eine Routing-loop. Fritzbox?

[zalva]

Hallo zusammen,

herzlichen Dank für die prompten Antworten.

Komme der Sache etwas näher.

laut EIB-Doktor Datenblatt EIBAnalyzer

50 Telegramme/s (sicher eher maximum) sind das ja 4.320.000/Tag
Ich habe "lediglich" ca. 50.000 ca. gehabt (ist natürlich auch zu viel)

Habe jetzt

a.) loxone separat und wiregate separat abgehängt, ein weilchen laufen lassen
--> wiregate alleine, wenig busverkehr
--> loxone alleine deutlich mehr Busverkehr ca. 400-500 je minute

b.) die Abfragen von loxone von 120s (Temp) auf 300 erhöht
beides wieder in Betrieb genommen (wiregate und loxone)
--> der Bus langweilt sich, ca. 100 Telegramme auf 5 Min -->
das ist quasie nichts

TROTZDEM
---> Absturz (sorry, Busüberlastung, Absturz gibt es ja nicht)
Habe später in der Auswertung gesehen 63 Telegramme in 8 Sec (zumindest laut Zeitstempel)

c.) Habe danach im Wiregate Optionen geändert

Erweiterte Konfigurationsoptionen (eibd Server)

KNXnet/IP Server startenJaNein
KNXnet/IP Tunneling Server aktiviertJaNein
KNXnet/IP Routing Server aktiviert ACHTUNG - Nur aktivieren falls kein anderer KNXnet/IP Router im selben Segment!JaNein
Caching von Gruppenadressen aktivierenJaNein

mal alles ausgeschaltet und werde sukzessive wieder einschalten
Vermute nach swiss-Beitrag, dsas das Caching oder das Tunneling das Problem machen (IP-Rouuting hatte ich deaktiviert, IP-Server weiss ich nicht mehr)

habe danach den eibd-Prozess restartet
--->
Das war das erste mal, dass ich nach einem "Absturz" ohne Reset wieder normalen Zugriff hatte

Wenn hier wirklich viel auf einmal kommt und nicht quittiert wird, schaukelt es sich auf und müllt den Bus zu --> nichts geht mehr.

Jetzt lasse ich mal laufen und schaue ob ich morgen früh wieder keinen Buszugriff habe (das war die letzten Tage so).


Gruss
Salvatore

[swiss]

Es könnte doch auch sein, dass ein gestörtes Gerät dass auf die Adresse 0.6.128 oder 7.14.0 höhrt dauernd ein NACK sendet!? Ich sehe aus den Protokollen keine Paritat. Wie stellt sich das im ETS Gruppenmonitor dar? Wird auf jedes Telegramm mit ACK geantwortet? KNX hat ja die angewohnheit, dass alle Telegramme die nicht Quitiert werden immer widerhohlt werden, bis eine Bestätigung erfolgt.

Die Adresse 7.14.0 klingt anch einem Linienkoppler. Hast du einen IP Router oder Linienkopler mit falscher Adresse? Was geschiet, wenn du mit der ETS das Gerät ausliest? Wenn da eine brauchbare Antwort zurückkommt, weist du wehnigstens, um was für ein Gerät es sich handelt.

Auch sehr interessant ist, dass die Daten mit hoher Priorität übertragen werden. Standart wäre ja nidrige Priorität ausser bei z.B. Windalarm einer Wetterstation. Könnte das gestörte Gerät eine Wetterstation sein?