[wiregate] - √ - Mögliche schlechte Netzwerk-Performance des Wiregate => Ursache PC-Firewall

[germershausen]

Hallo,

Habe seit einigen Wochen mit schlechter Verbindung zu meinem wiregate zu kämpfen. Bemerkt habe ichs über die cometvisu und dann über die weboberfläche, die immer wieder unendlich auf responses warteten. Ob eine Änderung meinerseits zu der Verschlechterung geführt hat kann ich nicht mehr sagen. Ich bin gerade dabei bei meinem Haus KNX- und 1wire-seitig viel einzurichten und da kommt jede Woche was neues dazu.

Heute bin ich mal auf Fehlersuche gegangen. Den WLAN-Router habe ich ausschließen können. Ping requests von meinem Laptop zum wiregate schauen allerdings nicht gut aus:

Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=2ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=5ms TTL=64
Request timed out.
Request timed out.
Reply from 10.0.0.2: bytes=32 time=1988ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=2ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=2ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 10.0.0.2: bytes=32 time=7ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=2ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 10.0.0.2: bytes=32 time=7ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64

Eine Besserung tritt sofort ein, wenn ich eines der folgenden Dinge am Wiregate verändere:
- den eibd dienst deaktivieren
- den tp-uart (seriell) herausnehmen
- das buskabel aus dem tp-uart entfernen

dann gibt es zwar auch noch längere responsezeiten, aber zumindest keine abbrüche mehr
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=2ms TTL=64
Reply from 10.0.0.2: bytes=32 time=14ms TTL=64
Reply from 10.0.0.2: bytes=32 time=23ms TTL=64
Reply from 10.0.0.2: bytes=32 time=23ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=21ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=19ms TTL=64
Reply from 10.0.0.2: bytes=32 time=17ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=15ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64

Auf dem wiregate sind die neuesten updates drauf. Sonst habe ich eigentlich außer den Logikprozessor von Fry und ein paar 1wire-sensoren nichts am wiregate laufen.
eibd aufruf (über wiregate-weboberfläche nachgelesen):
/usr/bin/eibd -e 1.1.254 -S -D -i -T -R --tpuarts-disch-reset --tpuarts-ack-all-group -d -u --pid-file=/var/run/eibd.pid -c tpuarts:/dev/ttyS0

Hat jemand einen Tipp für mich worans liegen könnte?

danke!

[JNK]

Ich habe kein -R, ich vermute mal, das ist Routing. Brauchst Du das wirklich? Sonst mal ausmachen.

[StefanW]

Bitte etwas mehr Info:

- Welche WG-Nummer?

- Welcher genaue Releasestand? (Die Angabe "neueste" reicht nicht, weil das missverständlich ist)

- JNK hat es schon gesagt, Tunneling anstatt Routing sollte reichen

- Load Average?

lg

Stefan

[germershausen]

Hi!

Wow! Danke für die schnellen Antworten! Hab das Routing jetzt mal deaktiviert (keine Ahnung wo ich das gelesen hab dass ich das brauche ...) und die Zeiten schauen wirklich besser aus. Programmierung über ETS geht auch noch. Jippie :-)

Manchmal gibt es aber doch noch Ausreißer nach oben.
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=16ms TTL=64
Reply from 10.0.0.2: bytes=32 time=13ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=12ms TTL=64
Reply from 10.0.0.2: bytes=32 time=2ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=5ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=33ms TTL=64
Reply from 10.0.0.2: bytes=32 time=263ms TTL=64
Reply from 10.0.0.2: bytes=32 time=180ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=4ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64
Reply from 10.0.0.2: bytes=32 time=3ms TTL=64

Ist das normal? Damit kann ich jetzt jedenfalls mal gut leben.

@StefanW: Sorry für die fehlenden Infos. Bin selber SW-Entwickler und reg' mich bei den Testern auf wenn sie mir das nicht mitliefern :-)

wiregate650
Version 1.2
CPU 17%
load average 0.81
(siehe auch screenshot im Anhang)

Gibts eigentlich irgendwo ein wiki mit Infos und FAQs zu solchen Einstellungen für das wiregate? Würde da gern auch etwas beitragen (zB Dummy-Anleitung für Download und Aktivierung des Logikprozessors ohne vorher das halbe Forum durchzuwühlen ...)

lg und danke nochmals!
stefan

[JNK]

Mhm. Jetzt müsste man schon mehr wissen, wie Dein Netzwerk aufgebaut ist. Bei mir ist z.B. bei 100 Ping über den Weg Notebook->AccessPoint->Switch->Router->Switch->Wiregate max. 56ms, Mittel 3ms, min. 1ms. Das gleiche vom Router aus hat alles <1ms. Es ist also bei mir klar nicht das WG, sondern jemand anders.

Abgesehen davon denke ich, ist das nicht so kritisch.

[germershausen]

Naja, mein Router ist ein Standardgerät von meinem Internetprovider (A1) und gleichzeitig mein WLan-Accesspoint. Und der läuft bei weitem nicht stabil - deshalb hatte ich ja den anfangs in Verdacht, konnte ihn aber als Übeltäter ausschließen...
Von dem Router gehe ich zu einem gigabit-switch, auf den ich meine LAN-Dosen gepatched habe.
Ich werde morgen mal den ping per direktverbindung Laptop<->Wiregate probieren, das sollte dann aussagekräftiger sein. Aber wie gesagt, solange ich keine package verluste habe kann ich gut mit der angebotenen Problemlösung leben.
Bevor ich das Routing am wiregate ausgeschalten habe waren jedenfalls sogar terminal-verbindungen mit putty mühselig, weil die Tastatureingaben nicht ankamen - auch mit Kabelverbindung Laptop->Gigabit-Switch->wiregate

[StefanW]

Guten Morgen,

Ist das normal? Damit kann ich jetzt jedenfalls mal gut leben.

Nun, hinsichtlich der geringen Load Average sollten die Zeiten eigentlich gleichmäßiger zu erwarten sein. Auf der anderen Seite werden kurze Lastspitzen nicht angezeigt, können sich aber auf die Reaktionszeit beim Echo zum Ping auswirken.

Ich glaube auch, wenn es sonst keine Auswirkungen gibt, dann kann damit leben.

Gibts eigentlich irgendwo ein wiki mit Infos und FAQs zu solchen Einstellungen für das wiregate?

Nein, leider noch nicht. Eigentlich wollten wir seit Anfang letztem Jahres einen Confluence-Server dafür installieren (haben wir auch gemacht) und in Betrieb nehmen mit entsprechendem Inhalt (habenwir nicht geschafft). Es haben sich sogar freiwillige Admins aus der Community gemeldet zum helfen.

Wir hatten letztes Jahr zunächst Pech mit Softwareentwicklern, so dass wir zwar dieses Problem am Ende fixen konnten, aber der Wiki-Server zeitlich auf der Strecke blieb. Wir machen dieses Jahr einen neuen Anlauf.

Würde da gern auch etwas beitragen (zB Dummy-Anleitung für Download und Aktivierung des Logikprozessors ohne vorher das halbe Forum durchzuwühlen ...)

Das wäre ganz toll und auch sehr hilfreich für die meisten.

Bevor ich das Routing am wiregate ausgeschalten habe waren jedenfalls sogar terminal-verbindungen mit putty mühselig, weil die Tastatureingaben nicht ankamen - auch mit Kabelverbindung Laptop->Gigabit-Switch->wiregate

Das sollte so nicht sein. Es würde mich schon interessieren, ob noch jemand solche Beobachtungen mit der aktuellen Version V 1.2 gemacht hat?

[Dirk42]

Hallo,

also ich denke das WireGate ist nicht dran schuld - damit wärs gut den "gelöst" Haken zu setzen.

Grade bei mir getestet, ich sehe für das WireGate die gleichen Zeiten wie für einen Sat-Receiver (xpeed lx2) der genau gleich angeschlossen ist: fast alle Antworten kommen in 1ms, manchmal gibt es Ausreißer nach oben (normal maximal 10ms, grade ist einmal ein 1121ms bei der xpeed durchgekommen.

Gemessen vom Notebook per WLAN an TP-Link Router, der per LAN an Fritzbox hängt, daran an deren LAN-Anschluss das WireGate und die xpeed.

Viele Grüße

Dirk

[tanzbaer]

Probiers mal revers.

Auf wiregate einloggen und laptop anpingen. Siehts dann genauso aus?

Und wie hast Du denn (vermeintlich) ausgeschlossen, dass es am Router liegt?

[StefanW]

Vielen Dank Dirk.

Ein kleiner Hinweis, bei solchen Messungen sollten niemals WLAN, PowerLAN, VPN oder das Internet in der Funktionskette sein, weil es dort technisch bedingt zu Ausreißern kommt.

Messung daher bitte nur nativ via leitungsgebundenem Ethernet via Switch.

lg

Stefan

[Dirk42]

Ein kleiner Hinweis, bei solchen Messungen sollten niemals WLAN, PowerLAN, VPN oder das Internet in der Funktionskette sein, weil es dort technisch bedingt zu Ausreißern kommt.

Messung daher bitte nur nativ via leitungsgebundenem Ethernet via Switch.

Logisch. Mir ging es darum zu zeigen, dass 1ms auch mit WLAN bei meinem Haus und Standardtechnik gut drin sind. Wenn stabil deutlich höhere Antwortzeiten vorkommen, klemmt da vermutlich etwas anderes oder das Netzwerk ist nicht ganz so trivial...

[germershausen]

Logisch. Mir ging es darum zu zeigen, dass 1ms auch mit WLAN bei meinem Haus und Standardtechnik gut drin sind.

Kann ich mittlerweile auch bestätigen. Habe jetzt meinen Standrechner statt dem Laptop zum pingen benutzt und hatte gleich Zeiten <1ms.
Schlussendlich habe ich die Firewall am Laptop (Symantec Endpoint Protection) als Verursacher der Verzögerungen entlarvt (>20ms statt 0,2ms - auch über Netzwerkkabel).
Ursprünglich muss aber doch auch etwas mit dem aktivierten IP/Routing server ghakt haben. Die Verbindungsprobleme waren ja quer durch meine Geräte zu spüren (iPhone, Android phones, Laptop, ...). Ich habe ihn testweise aktiviert und überraschenderweise keinen Impact mehr auf die Antwortzeiten gemerkt. Vielleicht hatte ich da noch einen anderen Fisch bei mir im Netzwerk. Egal, ich lasse ihn jetzt jedenfalls deaktiviert.

Conclusio:
- Das wiregate funktioniert ausgezeichnet (wie konnte ich das nur anzweifeln :-) )

Danke für eure Hilfe!

lg
stefan

[StefanW]

Wunderbar dass wir das geklärt haben.

Ich habe mir erlaubt, die beiden wichtigsten Sätze in Deinem Post fett darzustellen, damit unsere "Reinwaschung" auch sichtbar wird.


Bei dieser Gelegenheit: Bitte immer daran denken: Bei allem Verständnis für das Diskutieren von Problemen und unklaren Fehlerbildern, bei uns hängen Arbeitsplätze von der Darstellung im Forum ab, da wir - um unsere Produkte günstig zu halten - keine andere Werbung machen (von unserer Webseite abgesehen und die gehörte auch intensiver gepflegt).

Daher bitte zum einen um Fehlerdarstellung mit sachlichem gemäßigten Tonfall ohne krasse Wortwahl (was hier auch vorbildlich erfolgte, weil der Titel "Mögliche" beinhaltete) und ggfls. auch mal mit einem Lob oder mit Herausstellen einer besonders gelungen empfundenen (neuen) Funktion revanchieren.

Warum sag ich das? Weil wir mit Version 1.2 fast hundert kleine und große Fixes, Verbesserungen, Features und eine Teilüberarbeitung der Oberfläche vorgestellt haben, diese Verbesserungen ca. 40.000 EUR SW-Entwicklungskosten verursacht haben und zwar von der Mehrzahl der Kunden installiert wurde, aber die öffentliche Begeisterung die dann auch Werbewirksam ist, war sehr zurückhaltend (die vielen "toll gemacht" eMails gefallen uns schon, aber wir müssen das Geld auch wieder einnehmen und das klappt nur wenn wir dann auch mehr WG verkaufen).

Es ist wirklich nicht schlimm auch einen Thread mit Lob und / oder Vorstellung des eigenen Projektes zu veröffentlichen, es müssen nicht immer Fehler oder deren Vermutungen sein - auch wenn die Motivationslage für letzteres gut zehnmal höher ist.

Ich bitte um Eure Unterstützung


lg

Stefan

[BadSmiley]

Was spricht eigentlich gerne kostenpflichtige Software Updates ab einem gewissen Level an Änderungen? Wäre jetzt nicht so ungewöhnlich....