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

[lio123]

Hallo Zusammen,

ich komm selbst nicht weiter und weis auch nicht so recht, wo ich das Problem am Besten posten soll:

Nach gewisser Zeit hängt sich bei mir wohl die Hardware-Schnittstelle (IP-Controller Siemens N350E) auf.
Das macht sich wie folgt bemerkbar:
In der Visu werden keine Schaltvorgänge ausgeführt,
KNX-Daten werden nicht mehr dargestellt,
Plugins werden nicht mehr effektiv ausgegeben.
1-Wire Infos (Temps) werden aber richtig angezeigt

Wenn ich den N350E stromlos mache und nach kurzer ZEit wieder anschliesse, werden alle Kommandos die während der Abwesenheit (also bevor der Strom weggenommen wurde) stattgefunden haben, ausgeführt.

Eine Regelmäßigkeit konnte ich bisher nicht feststellen.
WG-Logeinträge sind für mich auch nicht auffällig.

Am N350E habe ich schon lange nichts mehr verändert und er arbeitete bisher immer zuverlässig.

Ich könnte aus dem Bauch meinen, dass die Ausfälle nun häufiger, in kürzeren Abschnitten auftreten.

Ich habe folgendes:
KNX zu IP übernimmt ein Siemens N350E Siemens Industry Online Support - Automation Service, Automation Support, Simatic Service, Simatic Support, Technical Support, Technical Consulting Controller

Die IP-Adresse des N350e ist im Wiregate eingetragen im Buszugriff mit IP-Tunneling eingetragen.
Die ETS ist auf den EIBD-Wiregate eingestellt und funktioniert.
Ein Rasp.Pi ist ebenfalls auf den EIBD-Wiregate eingestellt und funktioniert.

Liegt das Problem, evtl an dieser Konstellation?
Kann es sein, dass sich die Systeme gegenseitig abschießen?
Ein Hardwaredefekt des N350E würde ich eher ausschließen.
Was meint Ihr?

Danke und Grüße,
Lio

[swiss]

Auf die gefahr hin das sich Stefan gleich wieder angegriffen fühlt -> Die folgende Aussage basiert auf persönlichen Beobachtungen und stellt keine Wertung dar. Es sollen also nicht als Abwertung des Wiregate empfunden werden!

Ich habe vor einiger Zeit mal ein Problem mit Telegramm verdopplungen versucht nachzuvollziehen. Dazu habe ich eine miniatur Testanlage mit 2 Linien auf dem Esstisch aufgebaut. Damals war auf Linie 1 der Enertex KNX/IP-Router und auf Linie 2 das Wiregate als Routingserver und über TPUART an die Linie 2 angebunden...

Das Problem war, dass die Telegrammverdopplungen nach kurzer Zeit den IP-Router von Enertex lahmgelegt haben. Da ging bis zum Reset (strom trennen) nix mehr. Mit dem Weinzirl IP-Router ging es dann aber. Scheinbar verursachen wirklich gewisse Konstellationen Probleme. Ich konnte das hauptsächlich im Zusammenspiel mit IP-Routing feststellen. Bei dir scheint aber Tunneling probleme zu machen?

[StefanW]

Patrick,

Auf die gefahr hin das sich Stefan gleich wieder angegriffen fühlt

was hast Du denn für ein Bild von mir?

Ich persönlich fühle mich nie angegriffen, höchstens fühle ich das in Bezug auf die Produkte meines Unternehmens. Und ich stelle nur dort richtig oder beschwere mich, wenn unsachliche, unbewiesene Behauptungen, in drastischer Form zum Schaden unseres Hauses verbreitet werden.

Weil Behauptungen können schnell den Ruf ruinieren, wie wir alle noch von dem Debakel mit "selbst beschleunigenden Autos" bei Toyota 2009 bis 2011 wissen. Am Ende stellte sich heraus, das Toyota gar keine Schuld traf, die Mehrheit der betroffenen hatte schlicht Gas und Bremse verwechselt (nur in einem Fall war vermutlich eine verrutschte Fußmatte, in einem anderen ein klemmendes Gaspedal ungünstig, in beiden Fällen hätte gebremst und auf N geschaltet werden können). Ich will das für uns einfach nur vermeiden, zerredet zu werden.

Ich habe selbstverständlich überhaupt nichts gegen Fakten und klare echte Fehlerbeschreibungen. Dann können wir die Ursache suchen und lösen.


Zum Thema:
Patrick, ich bin Dir wirklich sehr dankbar für Deine immerwährende Unterstützung für die WG-Anwender hier und Dein großes Engagement.

Die Thematik mit Telegrammwiederholungen in bestimmten Konstellationen habe ich schon ein paar mal mitgelesen hier, aber irgendwie hat sich das nie richtig auf eine Konstellation bestimmte Anordnung eingrenzen lassen. Nach meiner Auffassung waren jeweils andere IP-Router / Tunnel beteiligt?

lg

Stefan

[swiss]

Hallo Stefan

Es freut mich, dass du mir den Post nicht übel nimmst. Das Problem mit den Telegrammverdopplungen konnte ich bei tofele zuhause das erste mal beobachen. Da wir uns nicht sicher waren ob das Phänomen mit seiner umfangreichen Installation zusammen hängt, habe ich eines meiner WG's hergenommen und auf dem Esstisch 2 TP Linien aufgebaut. auf der einen Linie (1.1) eine Spannungsversorgung, ein KNX Taster und ein IP-Router auf der anderen Linie (1.2) eine Spannungsversorgung, ein Schaltaktor und das Wiregate mit USB-TPUART. Die Telegrammverdopplungen konnten problemlos reproduziert werden. Aber dies ist nicht so problematisch. Der Weinzirl IP-Router steckte die Verdoppelungenproblemlos weg. Der Enertex IP-Router ging nach kurzer Zeit in die Knie.

Wird das Wiregate nicht als IP-Router eingesetzt sondern verbindet sich lediglich über IP-Routing ohne Linie dahinter funktioniert alles absolut problemlos und ohne Telegrammverdoppelungen (so habe ich es im produktiven Einsatz) Trotz der Telegrammverdoppelungen funktioniert aber das WG zuverlässig als IP-Router an einer TP Linie. Die Verdoppelungen machten sich erst beim Programmieren der Linie 1.1 direkt über den IP-Router (1.1.0) oder Multicasting bemerkbar.

[lio123]

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

[swiss]

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

[StefanW]

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

[swiss]

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?

[StefanW]

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

[lio123]

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

[lio123]

das hier steht im daemon log:

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:

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?

[swiss]

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!)

[swiss]

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.

[lio123]

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

[swiss]

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...

[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