Ankündigung

Einklappen
Keine Ankündigung bisher.

- √ - Problem: Die Verbindung zwischen IP und KNX hängt sich auf

Einklappen
Dieses Thema ist geschlossen.
X
X
Einklappen
 
  • Seite von 2
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
Vorherige 1 2 template Weiter
  • lio123
    antwortet
    Hallo Zusammen,

    habe nun den Rasp.pi mit dem Smarthome.image ganz neu gemacht.
    Seither läuft's.
    Da muss seitens des Rasp was reingefunkt haben?!?

    Grüße,
    Lio

    Einen Kommentar schreiben:

  • lio123
    antwortet
    Hallo,
    kurzer Stand:

    Habe auf dem N350E die programme nur noch mal drüber gespielt,
    also 2-3 Logikfunktionen, 5-6 Zeitschaltuhren-mehr nicht.
    Auch habe ich den Rasp.pi vom Netz genommen.
    Das Ganze läuft nun seit über 24h wie es sein sollte.
    Werde es mal bis morgen noch so laufen lassen und als nächstes den Rasp. wieder in Betrieb nehmen.

    Grüße,
    Lio

    Einen Kommentar schreiben:

  • lio123
    antwortet
    so, seither keine Angriffe mehr im Log.

    Im IP-Router ist Multicast IP: 224.0.23.12 eingestellt-was bedeutet das?

    Was auch seltsam ist:
    Ich bekomme in der ETS3 nur eine Busverbindung, wenn ich unter Optionen den Kommunikationstest durchführe, der immer Erfolgreich ist?

    Gruß,
    Lio

    Einen Kommentar schreiben:

  • do13
    antwortet
    Zitat von swiss Beitrag anzeigen
    Aber dazu mache ich mal noch ein paar eingehende Tests und protokolliere den genauen Testaufbau
    Hallo,

    mit welchen Parametern hast du den eibd gestartet?

    Kannst du ein Log vom eibd generieren? Also den eibd auf der Kommandozeile mit "-t 1023" (ohne Daemon mode) starten und den Output in ein File schreiben.

    Dirk

    Einen Kommentar schreiben:

  • swiss
    antwortet
    Hallo Lio

    Wiso da unterschiedliche Ports auftauchen weissich auch nicht. Aber der Dienst ist hier scheinbar immer SSH.

    Hier habe ich einen interessanten Beitrag dazu gefunden: Defend Against SSH Attacks & Increase SSH Security | Ubuntu Server GUI

    Da steht auch was man tun kann um sich etwas besser gegen solche Attaken schützen zu können. Vor allem der Tipp mit der IP Tabellen Regel finde ich sehr interessant...

    Code:
    [COLOR=#660033]-I[/COLOR] INPUT [COLOR=#660033]-p[/COLOR] tcp [COLOR=#660033]--dport[/COLOR] [COLOR=#000000]22[/COLOR] [COLOR=#660033]-i[/COLOR] eth0 [COLOR=#660033]-m[/COLOR] state [COLOR=#660033]--state[/COLOR] NEW [COLOR=#660033]-m[/COLOR] recent [COLOR=#660033]--set[/COLOR]
[COLOR=#660033]-I[/COLOR] INPUT [COLOR=#660033]-p[/COLOR] tcp [COLOR=#660033]--dport[/COLOR] [COLOR=#000000]22[/COLOR] [COLOR=#660033]-i[/COLOR] eth0 [COLOR=#660033]-m[/COLOR] state [COLOR=#660033]--state[/COLOR] NEW [COLOR=#660033]-m[/COLOR] recent [COLOR=#660033]--update[/COLOR] [COLOR=#660033]--seconds[/COLOR] [COLOR=#000000]90[/COLOR] [COLOR=#660033]--hitcount[/COLOR] [COLOR=#000000]4[/COLOR] [COLOR=#660033]-j[/COLOR] DROP

    Einen Kommentar schreiben:

  • lio123
    antwortet
    Ok Patrick,

    vielen dank- der Port war noch offen, weil ich Hilfe brauchte...
    Werde das mal weiterbeobachten.

    Kann ich mich da noch weiter schützen.
    Mit Deinen Infos werden doch da nach und nach die Ports gescannt?

    Grüße,
    Lio

    Einen Kommentar schreiben:

  • swiss
    antwortet
    Wegen den Einträgen im auth log...

    Das halte ich für sehr bedenklich. Da versucht scheinbar ein Rechner der in Argentienen steht (kann auch ein BOT sein) sich in dein WG zu hacken.

    Allerdings halte ich es auch für sehr bedenklich dass scheinbar dein WG aus dem Internet direkt ansprechbar ist. Vor allem die Ports für SSH usw. Der einzige Port des WG der gegen das Internet offen sein solle/dürfte wäre der für OpenVPN.

    Einen Kommentar schreiben:

  • swiss
    antwortet
    Hallo Lio

    Die Telegrammverdopplungen hängen weder mit der Visu noch irgend welchen Plugins zusammen. Die gesammte Kommunikation der diversen Wiregatefunktionen (plugins, visu, temperatur an KNX usw...) mit dem BUS wird über den eibd (programm dass die Daten für KNX übersetzt und die Telegramme verarbeitet) abgewikelt.

    Dabei scheint der eibd einen fehler zu machen wenn er als IP Roter (Routingserver) konfiguriert und über TP-UART mit einer Linie verbunden ist. Dann treten bei mir und tofele die Verdoppelungen auf der IP Seite (KNX Net/IP Routing) auf sobald ein Telegramm über IP (KNX Net/IP Routing) an die Linie des wiregate gesendet wird.

    Schematisch also so:

    Telegramm -> IP-Routing -> eibd (wiregate) -> TP Linie

    und gleich darauf

    eibd (wiregate -> IP-Routing

    Wenn ich also über IP einen Befehl z.B. schalte GA 1/1/1 aus an einen Aktorsende der an der Linie des Wiregate hängt, bekomme ich direkt im anschluss das gleiche Telegramm schalte GA 1/1/1 aus aber mit um 2 reduziertem Routingzähler wieder auf der IP Linie.

    Topologie:

    TPLinie 1.1.x -> KNX IP Router 1.1.0 -> Netzwerk -> Wiregate (als IP Router) 1.2.0 -> TP Linie 1.2.x

    Jedes mal wenn ein Telegramm einen Router passiert wird der Routingzähler um 1 reduziert. Ist der Routingzähler = 0 wird das Telegramm von den Kopplern verworfen!

    Interessant ist dass die doppelten Telegramme scheinbar 2 mal den eibd passieren weil auch der Routingzähler 2 mal um 1 reduziert wird. Also bei IP -> Wiregate und bei Wiregate -> IP.

    Auf der TP Linie hinter dem wiregate sind aber keine doppelten Telegramme zu erkennen was dafür sprechen würde dass der eibd die Telegramme selber zurück an die IP Linie sendet.

    Aber dazu mache ich mal noch ein paar eingehende Tests und protokolliere den genauen Testaufbau

    Ist ja nicht so als wäre es ein Beinbruch denn 99% der Usern ist das scheinbar noch nicht aufgefalen und hat meistens auch keine weiteren auswirkungen weil die meisten IP Router die Telegramme einfach ausfiltern (ausser man hat die Filter auf durchzug!)

    Einen Kommentar schreiben:

  • lio123
    antwortet
    das hier steht im daemon log:
    Code:
    Dec 10 23:06:04 wiregate534 monit[2636]: 'localhost' loadavg(5min) of 5.2 matches resource limit [loadavg(5min)>2.0]
Dec 10 23:06:04 wiregate534 monit[2636]: 'localhost' loadavg(1min) of 5.8 matches resource limit [loadavg(1min)>4.0]
Dec 10 23:06:21 wiregate534 collectd[2232]: processes plugin: Failed to open `/proc/4621/cmdline': No such file or directory.
Dec 10 23:07:04 wiregate534 monit[2636]: 'localhost' loadavg(5min) of 5.0 matches resource limit [loadavg(5min)>2.0]
Dec 10 23:07:04 wiregate534 monit[2636]: 'localhost' loadavg(1min) of 4.9 matches resource limit [loadavg(1min)>4.0]
Dec 10 23:08:05 wiregate534 monit[2636]: 'localhost' loadavg(5min) of 5.2 matches resource limit [loadavg(5min)>2.0]
Dec 10 23:08:05 wiregate534 monit[2636]: 'localhost' loadavg(1min) of 5.5 matches resource limit [loadavg(1min)>4.0]
Dec 10 23:09:05 wiregate534 monit[2636]: 'localhost' loadavg(5min) of 5.4 matches resource limit [loadavg(5min)>2.0]
Dec 10 23:09:05 wiregate534 monit[2636]: 'localhost' loadavg(1min) of 5.8 matches resource limit [loadavg(1min)>4.0]
Dec 10 23:10:05 wiregate534 monit[2636]: 'localhost' loadavg(5min) of 5.3 matches resource limit [loadavg(5min)>2.0]
Dec 10 23:10:05 wiregate534 monit[2636]: 'localhost' loadavg(1min) of 5.5 matches resource limit [loadavg(1min)>4.0]
Dec 10 23:11:05 wiregate534 monit[2636]: 'localhost' loadavg(5min) of 5.4 matches resource limit [loadavg(5min)>2.0]
Dec 10 23:11:05 wiregate534 monit[2636]: 'localhost' loadavg(1min) of 5.6 matches resource limit [loadavg(1min)>4.0]
Dec 10 23:12:05 wiregate534 monit[2636]: 'localhost' loadavg(5min) of 5.3 matches resource limit [loadavg(5min)>2.0]
Dec 10 23:12:05 wiregate534 monit[2636]: 'localhost' loadavg(1min) of 5.2 matches resource limit [loadavg(1min)>4.0]
    geht schon den ganzen Tag durch

    ???



    Und das hier gerade im auth.log:
    Code:
    Dec  9 18:25:04 wiregate534 sshd[27336]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246 
Dec  9 18:25:07 wiregate534 sshd[27336]: Failed password for invalid user teamspeak from 64.76.17.246 port 41536 ssh2
Dec  9 18:25:11 wiregate534 sshd[27453]: Invalid user cyrus from 64.76.17.246
Dec  9 18:25:11 wiregate534 sshd[27453]: pam_unix(sshd:auth): check pass; user unknown
Dec  9 18:25:11 wiregate534 sshd[27453]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246 
Dec  9 18:25:12 wiregate534 sshd[27453]: Failed password for invalid user cyrus from 64.76.17.246 port 41691 ssh2
Dec  9 18:25:17 wiregate534 sshd[27578]: Invalid user mythtv from 64.76.17.246
Dec  9 18:25:17 wiregate534 sshd[27578]: pam_unix(sshd:auth): check pass; user unknown
Dec  9 18:25:17 wiregate534 sshd[27578]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246 
Dec  9 18:25:19 wiregate534 sshd[27578]: Failed password for invalid user mythtv from 64.76.17.246 port 41834 ssh2
Dec  9 18:25:23 wiregate534 sshd[27917]: Invalid user students from 64.76.17.246
Dec  9 18:25:23 wiregate534 sshd[27917]: pam_unix(sshd:auth): check pass; user unknown
Dec  9 18:25:23 wiregate534 sshd[27917]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246 
Dec  9 18:25:25 wiregate534 sshd[27917]: Failed password for invalid user students from 64.76.17.246 port 42044 ssh2
Dec  9 18:25:28 wiregate534 sshd[28141]: Invalid user monitor from 64.76.17.246
Dec  9 18:25:28 wiregate534 sshd[28141]: pam_unix(sshd:auth): check pass; user unknown
Dec  9 18:25:28 wiregate534 sshd[28141]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246 
Dec  9 18:25:31 wiregate534 sshd[28141]: Failed password for invalid user monitor from 64.76.17.246 port 42200 ssh2
Dec  9 18:25:34 wiregate534 sshd[28385]: Invalid user camera from 64.76.17.246
Dec  9 18:25:34 wiregate534 sshd[28385]: pam_unix(sshd:auth): check pass; user unknown
Dec  9 18:25:34 wiregate534 sshd[28385]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246 
Dec  9 18:25:36 wiregate534 sshd[28385]: Failed password for invalid user camera from 64.76.17.246 port 42462 ssh2
Dec  9 18:25:40 wiregate534 sshd[28498]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=bin
Dec  9 18:25:42 wiregate534 sshd[28498]: Failed password for bin from 64.76.17.246 port 43832 ssh2
Dec  9 18:25:46 wiregate534 sshd[28677]: Invalid user cvsuser from 64.76.17.246
Dec  9 18:25:46 wiregate534 sshd[28677]: pam_unix(sshd:auth): check pass; user unknown
Dec  9 18:25:46 wiregate534 sshd[28677]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246 
Dec  9 18:25:48 wiregate534 sshd[28677]: Failed password for invalid user cvsuser from 64.76.17.246 port 44598 ssh2
Dec  9 18:25:53 wiregate534 sshd[28816]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:25:55 wiregate534 sshd[28816]: Failed password for root from 64.76.17.246 port 45364 ssh2
Dec  9 18:25:58 wiregate534 sshd[28935]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:00 wiregate534 sshd[28935]: Failed password for root from 64.76.17.246 port 46134 ssh2
Dec  9 18:26:04 wiregate534 sshd[29051]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:07 wiregate534 sshd[29051]: Failed password for root from 64.76.17.246 port 46882 ssh2
Dec  9 18:26:10 wiregate534 sshd[29175]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:12 wiregate534 sshd[29175]: Failed password for root from 64.76.17.246 port 48263 ssh2
Dec  9 18:26:16 wiregate534 sshd[29285]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:18 wiregate534 sshd[29285]: Failed password for root from 64.76.17.246 port 49013 ssh2
Dec  9 18:26:22 wiregate534 sshd[29416]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:24 wiregate534 sshd[29416]: Failed password for root from 64.76.17.246 port 49772 ssh2
Dec  9 18:26:28 wiregate534 sshd[29539]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:30 wiregate534 sshd[29539]: Failed password for root from 64.76.17.246 port 50528 ssh2
Dec  9 18:26:33 wiregate534 sshd[29741]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:35 wiregate534 sshd[29741]: Failed password for root from 64.76.17.246 port 51281 ssh2
Dec  9 18:26:39 wiregate534 sshd[29992]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
Dec  9 18:26:41 wiregate534 sshd[29992]: Failed password for root from 64.76.17.246 port 52119 ssh2
Dec  9 18:26:44 wiregate534 sshd[30259]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.76.17.246  user=root
    will hier jemand mir was böses?

    Einen Kommentar schreiben:

  • lio123
    antwortet
    Hallo,

    bedeutet das, dass die doppelten Telegramme dann von der Visu, bzw. von Plugins, zb. auf dem WG kommen?

    Ich habe die ETS3 nun so eingestellt, dass nur die doppelten Telegramme gesendet werden, allerdings kann ich das bis jetzt nicht nachvollziehen.


    Grüße,
    Lio

    Einen Kommentar schreiben:

  • StefanW
    antwortet
    Zitat von swiss Beitrag anzeigen
    Ich habe ab übernächster Woche Ferien. Wenn du willst kann ich dann nochmal ein grösseres Testing durchführen und dabei möglichst alles protokollieren.
    Das wäre sicher ganz toll. Wenn Du dafür Hardware benötigst, melde Dich einfach, für so was gibt es immer Unterstützung von unserer Seite. Du musst nicht Deine eigenen WG / Interfaces verwenden. Ich kann Dir auch beide TP-UARTs mitgeben (seriell wie auch USB).

    Schreib mit einfach zusammen was Du benötigst.

    lg

    Stefan

    Einen Kommentar schreiben:

  • swiss
    antwortet
    Hallo Stefan

    Ich habe ab übernächster Woche Ferien. Wenn du willst kann ich dann nochmal ein grösseres Testing durchführen und dabei möglichst alles protokollieren. Ich bin mir auch ziemlich sicher dass es am eibd liegt. Denn die verdoppelten Telegramme haben immer einen um 2 reduzierten Routingzähler. Das Telegramm scheint also von der IP Seite her den "Software-Router" des eibd zu passieren wobei der Routingzähler um 1 reduziert wird.

    Irgend wo nach diesem Schritt (softwaremässig) wird das Telegramm wieder von der "TP Seite des eibd Routers" zurück durch den "Software-Router" des eibd an die IP Seite geleitet wobei der Routingzähler erneut reduziert wird. Somit habe die Doppelten Telegramme immer einen um 2 reduzierten Routingzähler (beobachtet auf dem Multicasting).

    Schaut man aber direkt auf der TP Linie des WG ist immer nur 1 Telegramm mit Routingzähler -1 (was ja korrekt ist) zu sehen.

    Aber ich kann das ja mal noch sauber versuchen zu beschreiben und mit Versuchsaufbauten zu dokumentieren

    Der nächste Schritt wenn das noch jemand unabhängig verifizieren kann wäre dann ein BUG Report bei den eibd Entwiklern oder?

    Einen Kommentar schreiben:

  • StefanW
    antwortet
    Hallo Patrick,

    das müsste man mal mit genauer Beschreibung, Parametern usw. in der Devel Liste einstellen. Denn dieses Verhalten betrifft ja dann nicht nur das Wiregate sondern alle Installationen mit dem eibd.

    Für alle Mitleser: Der eibd ist keine vollständige Implementierung des KNX Standards. Ua. fehlt es am Filter und dessen Einstellbarkeit via ETS (so wie es ein richtiger KNXnet/IP Router kann). Auf der anderen Seite werden solche Filter im kleinen Umfeld wie Wohnhäusern eher nicht benötigt. Bei großen Geschäftshäusern mit sehr vielen TP-Linien - die übergreifend über KNXnet/IP zusammengefasst werden - sind solche Filter dagegen notwendig um die einzelnen TP-Linien nicht zu überlasten.

    Das Thema "Upgrade des eibd auf vollen Standard" war schon öfters Diskussionsthema bei uns. Wegen der finanziellen Aufwendungen und der mangelnden Einnahmeaussichten bei OpenSource haben wir das bisher nicht umgesetzt.

    lg

    Stefan

    Einen Kommentar schreiben:

  • swiss
    antwortet
    Hallo Lio

    Die Verdoppelungen konnte ich im ETS Gruppenmonitor auf der KNX IP-Linie über Multicasting so wie in der Linie 1.1 über IP-Tunneling erkennen. Die Telegramme werden scheinbar vom eibd verdoppelt wenn ein Telegramm über IP in die WG-TP Linie gesendet wird. Dann wird das gleiche Telegramm vom WG über IP zurück gesendet. Das ist auch bei Tunneling zu beobachten solange das WG als IP Router (Routingserver) konfiguriert ist.

    Im Anhang mal eines der Fotos die ich damals gemacht habe. Die ETS habe ich so eingestellt, dass die doppelten Telegramme (mit reduziertem Routingzähler) gelb markiert werden. Das weiss gelbe Muster ist ziemlich konstant

    weiss = original Telegramm
    gelb = verdoppelung des vorherigen Originaltelegramms
    Angehängte Dateien

    Einen Kommentar schreiben:

  • lio123
    antwortet
    Hallo Patrik,

    danke für Deinen Beitrag.
    Telegrammverdoppelung: Wie kann ich das verstehen, wer verdoppelt da welche Telegramme?
    Trifft das bei meiner Konstellation auch zu? Dein Versuch ist ja eher eine spreizung in zwei KNX-Linien, oder?
    Wie könnte ich das verifizieren, bzw eingrenzen.

    Extra dafür einen fähigen router, bzw gateway kaufen, wollte ich nicht.

    Aber ich denke auch, dass meine Konstellation, doch oft, wenn auch mit anderer Hardeware, sehr oft vertreten sein mus???

    Danke und Gruß,
    Lio

    Einen Kommentar schreiben:

Vorherige 1 2 template Weiter
Lädt...
X

Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.

Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.

Ich stimme zu