Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[ctx]

Das tönt gut ... die Geschwindigkeit begrenzen.
Aber keine Ahnung wie ich das einbauen solll. Ich weiss wo der Quelltext ist ... aber mehr Ahnung habe ich davon nicht.

[saegefisch]

Ich nutze den LBS selber (noch) nicht, aber ein Blick in das Coding zeigt ja: cURL wird verwendet. Müsste man da dem LBS nicht einen weiteren Eingang spendieren und darüber die maximale Bandbreite begrenzen können über die cURL-Option "CURLOPT_MAX_SEND_SPEED_LARGE"?

Habe die Option selber noch nie benutzt, aber laut PHP-Hilfe, sollte das helfen können. Vielleicht mit einem Default-Wert für 70% eines 1GBit-LAN - damit sollte für alles andere im LAN genug Reserve sein. Wenn ich mich nicht total verrechnet habe (Angabe in Bytes/sec) wäre z.B. "85000000" für ~85MByte/s bei ~115MByte/s max passend

benji : Was denkst Du dazu?

[ctx]

Ja ich habe ihn mehr als eine Stunde verzögert.
ca.00:53 war das Backup und der Transfer.

[Sonnengruesser]

Aber ich werde wohl keine Lösung finden mit dem Backup Baustein, es scheint wirklich das dieser das Problem verursacht.

passiert das auch, wenn du das Backup ein paar Minuten später machst?
Ich triggere den LBS erst um 10min nach Mitternacht, damit genau das nicht passiert.

[ctx]

Mein Netzwerk sieht so aus:

Hauptnetzwerk 192.168.1.xxx / dort ist der NAS und das restliche angeschlossen
Nebennetzwerk 192.168.2.xxx / Edomi auf Hardware, nicht virtuell / Eigener Port direkt an pFsense
Nebennetzwerk 192.168.3.xxx / IP - KNX Gatway / Eigener Port direkt an pFsense

Ich konnte das genau zurückverfolgen das die Verbindung beim Backup auf den NAS (per FTP) dann irgendwann mal die Verbindung unterbrach oder wie auch immer genau.

Bis jetzt hatte ich heute Nacht keine Fehler.

Wenn das jemand genauer wissen möchte kann ich hier noch weitere Tests machen und das alles hier rapportieren.
Aber ich werde wohl keine Lösung finden mit dem Backup Baustein, es scheint wirklich das dieser das Problem verursacht.
In den 40 Sekunden wo er 2Gb Backup an das NAS sendet. Verliert wohl mein Edomi die Verbindung zum KNX Gateway und das ergibt das Problem.
Edomi läuft bei mir auf einem APU 1 Rechner.

[Marino]

@ enertegus Wie hoch in etwa dürfte denn die Latenz sein? KNX ist ja auch nicht rasend schnell.

[coliflower]

Seit meine IP-Schnittstelle + Edomi (APU3) direkt am Switch in einem eigenen VLAN "gekapselt" ist, habe ich absolut NULL solche Fehler ... bei 100% CPU um Mitternacht ... nur so als Hint ...

[enertegus]

die LAN-Schnittstelle ist zwar die gleiche, aber da sollte kein Problem sein, neben dem Backup noch ein paar Telegramme auszuführen.

Vermutlich entsteht dabei eine zu hohe Latenz bei den Antworten.

[Marino]

Das nutzt ja zwar den LAN-Anschluss, aber das Gateway hat damit doch nichts zu tun, es wird ja nicht auf einem KNX-Gerät gesichert. das wird für das Backup nicht benötigt.

die LAN-Schnittstelle ist zwar die gleiche, aber da sollte kein Problem sein, neben dem Backup noch ein paar Telegramme auszuführen.

[ctx]

Wie es scheint habe ich das Problem gefunden. Mit dem LBS 169 habe ich jede nacht das Backup auf den NAS gebracht. ca. 2 GB das hat dan jeweils 40 sec. gedauert und den IP Gateway natürlich ausgelastet.
Ich deaktivere das jetzt mal und schaue ob das die Lösung ist.

[ctx]

Ich habe mal eben ein Stresstest für mein System gemacht.
KNX Send Rate ist an das Limit gekommen.
Das verursacht kein System absturz wie ich in immer um Mitternacht habe.

enertegus
Ich habe Powersupply 960 V2 und ein IP Interface von euch im Einsatz. Bestellnummer 1147.

Also eine KNX Bus Überlast kann ich defintiv aussschliessen.

Ich denke das Problem kommt auf der IP/Ethernet Seite daher.

Edit: 00:16 / Eben habe ich beobachtet was um Mitternacht passiert.
CPU Last von Edomi geht Massiv hoch.
Dann nach ca. 1.30 Min. nach Mitternacht, fällt der EDOMI Status aus. Es kommt der Kreis von Edomi welcher dreht und lädt.
Das könnte das Problem sein also das System ist um Mitternacht mit zuvielen Aktionen beschäftigt. Was zu verzögerungen führt.
Ich habe nun mal das AutoBackup deaktivert.
Mal schauen die nächsten Tage was passiert.

[ctx]

Ok auf en ersten Blick ist mir das auch zu hoch. Aber dein Spannungsgeber sendet ein KNX Telegramm an das IP Interface und dann hast du ein Kommunikationsausfall zwischen edomi und dem IP interface welches ja per RJ 45 kommuniziert.... Interessant.

[Ja hn A]

So genau kenne ich mich im KNX-Format nicht aus, aber hier sind die Botschaften von der Spannungsversorgung 1.0.253 zur Schnittstelle 1.0.255, nach denen die Schnittstelle ausgestiegen sind:

bild1.png
bild2.png

[ctx]

Also wie hat er das angepingt ? .. über den KNX Bus die Spannungsversorung hat ja kein RJ45 ..
Restlos weg ist das Problem bei mir auch nicht.. hatte wieder an einigen Tagen einmal den Ausfall, immer um MItternacht.

[Ja hn A]

KNX-Verbindung abgebrochen zu MDT Interface SCN-IP000.03 bei Geräteüberwachung durch MDT STR-0640.01 Spannungsversorgung

Ich hatte ein Problem, dass die KNX-Verbindung von Edomi zur MDT Schnittstelle mehrfach am Tag zusammenbrach, und folgende Fehlermeldung im Log-File anzeigte:

2020-03-05 11:19:36 369385 KNX 4269 DE < | TUNNELING_REQUEST:L_Data.ind / Typ: Read / ErrMsg: Unbekannte GA / SeqCounter: 140 (140) / PA: 1.0.222 / GA: 2/0/255 / Raw: 061004200014044e8c002900b06010de10ff0080 ERROR 2020-03-05 11:19:36 508785 KNX 4269 DE < | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 061004200015044e8d002900b06010de10ff014300 ERROR 2020-03-05 11:19:37 458619 KNX 4269 DE < | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 061004200015044e8d002900b06010de10ff014300 ERROR

Schreiben auf den Bus war danach noch möglich, aber das Weiterleiten von KNX-Botschaften über die Schnittstelle kam nicht mehr (auch nicht nach expliziten READs). Das KNX-Errorlog zeigte, dass die Verbindung und die Tunnels aktiv waren.

2020-03-05 14:25:27	612582	9943	OK	CE > | CONNECT_REQUEST an 192.168.178.102:3671 / Raw: 06100205001A0801c0a8b274c3500801c0a8b274c351040402 00
2020-03-05 14:25:27	633299	9943	OK	CE < | CONNECT_RESPONSE / CE: 192.168.178.116:50000 - 192.168.178.102:3671 / DE: 192.168.178.116:50001 - 192.168.178.102:3671 / Tunnel-PA: 1.0.255 / ChannelID: 118 / Raw: 06100206001476000801c0a8b2660e57040410ff
2020-03-05 14:25:27	653623	9943	OK	CE > | CONNECTIONSTATE_REQUEST / Raw: 06100207001076000801c0a8b274c350
2020-03-05 14:25:27	655329	9943	OK	CE < | CONNECTIONSTATE_RESPONSE / Raw: 0610020800087600
2020-03-05 14:25:29	727920	9943	OK	DE > | TUNNELING_REQUEST:L_Data.req / Typ: Read / SeqCounter: 0 / PA: 1.0.255 / GA: 0/7/54 / Prio: 0 / Raw: 061004200015047600001100BCE010ff0736010000
2020-03-05 14:25:29	730348	9943	OK	DE < | TUNNELING_ACK / SeqCounter: 0 (0) / Raw: 06100421000a04760000

Durch Zufalls find ich dann im Wireshark-Trace, dass jedesmal vor dem Problem die MDT-Diagnose von der Spannungsversorgung MDT STR-0640.01 die Schnittstelle SCN-IP000.03 angepingt hat. Nachdem ich diese Überwachung der Schnittstelle abgestellt habe, hatte ich seitdem keine Probleme mehr.

Sicher ein sehr spezieller Fall, aber vielleicht hilft es irgendeinem anderen, wenn ich das hier dokumentiere.