Quantasy

Herzlichen Dank!

Hey Equinox Genau dafür stehe ich auch ein! Deshalb habe ich den Thread gestartet... damit der 'Mechanismus' zum Einsatz kommt... und der/die Threat ein Ende hat. "Hast Du gelesen... Tinkerforge: Bring uns 'den Mechanismus'." (Oder drehe ich Dir da die Worte im Munde herum und nutze diese bloss für meine niederen Zwecke? ;-) )

Habe ich beschrieben... lies weiter! Es ist nicht Aufgabe einer Komponente im Netz (ausser dem Access-Point selber), das WLAN-Passwort zu verraten. Nie. Warum mutet sich Tinkerforge zu, diese Aufgabe übernehmen zu müssen? Die Authentisierung ist genau dafür gedacht, dass die WetterApp mit StuxNet Erweiterung nicht an den Parametern der Bricks und Bricklets rumspielt... Und selbst wenn ich einer App erlauben möchte, an den Bricks und Bricklets rumzuhantieren... will ich immer noch nicht, dass diese App mein WLAN-Passwort kennt. Das WLAN-Passwort hat rein gar nichts mit Tinkerforge zu tun. Also warum dieser schreckliche Verrat? ob mit oder ohne Authentisierung Dann wärest Du also auch dabei als Autor der 'anderen Seite' die Meinung zu vertreten, dass Tinkerforge das Passwort preisgeben soll? Ich sehe... meine Seite ist (noch) ziemlich einsam hier ;-) Kein Problem, nehme das nicht persönlich... sondern sportlich :-)

Hallo Equinox Dein Beispiel ist ein Spezialfall (der es auch in sich hat). Hier aber das Grundsatzproblem: Meine Arbeitshypothese: Eine App (sagen wir mal eine WetterApp), welche ich vom AppStore auf mein Smartphone runterlade und in meinem WLAN-Heimnetz betreibe... kennt das WLAN-Passwort nicht. Sind wir uns da einig? Weiter nehme ich folgendes an: Diese App kann zwar im WLAN-Heimnetz Meldungen austauschen oder gar über den AccessPoint und das Gateway ins Internet gehen, lernt aber kein einziges Passwort... weder das vom AccessPoint noch vom Gateway... Siehst Du das auch so? Meine Erkenntnis: Wenn nun im Netz aber eine Tinkerforge WLAN-Extension ihren Dienst tut... Dann kann die WetterApp (der NSA-Teil davon :-) ) sich das WLAN-Passwort ganz leicht holen. Genau das kann man ganz einfach per API-Call (oder per Default gar per Browser (connect auf die WLAN-Extension)) nachvollziehen. Diese Erkenntnis bezeichne ich als Schwäche denn ich kann einen Angriff darauf beschreiben. Ist das nachvollziehbar? Der ganze obere Teil dieses Threads kann ich prima nutzen, um im Paper eine Discussion Section zu erarbeiten (sofern die Autoren einverstanden sind). Als erste Lösung würden natürlich die 'low-hanging fruits' wegnehmen und den Default-Web-Access abstellen. Dann würde die Authentisierung (mit SHA1, aber das ist ein anderes Problem) per Default eingeschalten. Ja? Doch insbesondere der zweite Schritt würde wohl vielen Tinkerern zu viel der 'Security vs. Usabilty' sein, denn jetzt muss sich jede gute Tinkerforge Applikation, welche auf die Stacks verbinden möchte... sich ein Passwort merken… Und dann passiert, was allen dann passiert, das Passwort landet bei GitHub, denn es ist hart in der Applikation des Tinkerers drin ;-) Und das ist schlussendlich wohl ein No-Go. Ja? Solution Und da käme dann meine super geniale noch von niemand anderem (ausser von Mac, Microsoft, Linux, Android und all den anderen) ausgedachten Lösung ins Spiel, bei dem ein Passwort fürs WLAN gesetzt... aber nicht mehr ausgelesen werden kann. Später wäre es dann vielleicht sinnvoll, dass das WLAN-Passwort auch nicht mehr 'einfach so' überschrieben werden kann... aber das ist ein anderes Paper, bei dem es nicht um die Privacy geht. Conclusion Dann müssten all diese 'Not-Patches' überhaupt nicht gemacht werden. Und jeder könnte seine WetterApp mit "NSA-Extension" in seinem Heimnetz betreiben, ohne Angst haben zu müssen, dass Tags darauf die ganze Welt sein WLAN-Passwort kennt. So in etwa würde Projekt "Privacy for Tinkerforge" gestaltet.

Ich kann das bestätigen... Nach dem Update meiner Master-Bricks (2.1) auf 2.4.3 fingen die SK6812 (RGBW) an zu flackern. Bin nun wieder auf 2.4.2 zurück und das Flackern hat aufgehört. Das Ganze ist gut reproduzierbar... Ich habe auch in einem Stack ein Master auf 2.4.3 und einen auf 2.4.2 gebracht. Die LEDStrips am LEDStripBricklet (1.0) 2.0.6 flickern nur dort wo sie am Master mit 2.4.3 hängen.

Das wars? Ruhe bis zum Sturm? Dann würde ich diesen also nun entfachen sollen? Die App und das Paper zum Auslesen der WLAN-Passwörter also schreiben? Das wäre dann soz. ein Tinkerforge-Projekt, bei dem jeder herzlich eingeladen ist zu partizipieren und wenn gewollt als Mitautor des Papers mitzuwirken. Provozierender Working title ist dann: "When IoT gets Too Chatty" A practical example using a explicite design flaw in Tinkerforge's security concept for WLAN-Passwords. Ich würde euch dann bitten... Section 3 und die Conclusion mit zu verfassen, dann können wir die gegensätzlichen Standpunkte dort vertreten. Wer wäre dabei?

Hey Borg, ich sehe es aber genau so, wie Du das beschreibst! Da ergreife ich doch das letzte Szenario also Strohhalm, den wir als Brücke unserer beiden Anschauungen weiter nutzen können... Also formuliere ich meinen Security Request erneut: Ich ersuche Tinkerforge genau das zu tun: Erlaubt den Zugriff auf die WIFI Extension, ohne dass man dabei zwangsläufig Geheimnisträger wird. (im Security-Model Honest but Curious) Dies erhöht die Sicherheit des (Heim-)netzes ohne die Funktionalität der WIFI Extension oder irgend einer Funktionalität von Tinkerforge negativ zu beeinflussen. Dass die WIFI Extension als Merkzettel dienen muss... das will ich nicht gelten lassen... Hey, wenn Du das Passwort vergessen solltest... schau beim Access-Point nach (e.g. FritzBox). Denn genau dies ist eine der Kernfunktionen die ein Access-Point anbieten muss: Das Passwort berechtigten Benutzern vorzuzeigen... Somit gilt natürlich auch: Wenn die WIFI2 im AccessPoint Mode läuft... ja dann ist überhaupt nichts einzuwenden, wenn dann dieses AccessPoint-Passwort ausgegeben werden kann! Toll wäre dann ein Rollenkonzept, welches die Konfiguration und die Nutzung unterscheidet... Aber das ist ein anderer Security-Request. Besser? Zu Loetkolbens Anmerkungen: Dass mit der beschriebenen Option, wäre für mich natürlich auch ein riesen Schritt vorwärts! Wenn das dann noch die 'Default-Option' wäre, dann wäre das spitzenmässig. Zur ersten Anmerkung: Die kann ich so nicht ganz einordnen? Was wäre genau das Szenario mit der Multi-SSID?

Ich sehe, dass Du (Borg) nicht zwischen Konfigurieren und Nutzen unterscheidest. Ist das richtig? Es ist für mich verblüffend zu lesen wie sehr unsere Positionen sogar bei Metaphern divergieren! Wenn 'ich' das Authentifizierungspasswort (für die Konfiguration der FritzBox) kenne, heisst das überhaupt nicht, dass die 0815-App dies kennt!? Wenn 'ich' das WLAN-Passwort (für die Nutzung der FritzBox) kenne, heisst das überhaupt nicht, dass die 0815-App dies kennt!? Woher soll sie es denn nehmen? Von der FritzBox kriegt die App diese Angaben auf keinen Fall. Aber egal, wie ich das hier zu beschreiben versuche, es scheint als hätten wir hier nicht die gleiche Sprache? Ich habe mir das mit der authentisierung enablen per Default auch noch einmal angeschaut und muss genau noch einmal darauf hinweisen, dass wir da ganz klar andere Meinungen haben: Wenn die spezialisierte (aber dennoch böse) Tinkerforge-App gezwungenermassen das Authentisierungspasswort erhält, dann kann sie als Beiprodukt auch noch gleich das WLAN-Passwort des Netzes weitergeben. Das könnte sie nicht, wenn sie es gar nicht lesen könnte. Ist das denn so missverständlich? Für mich ist der Angriff so sonnenklar, so deutlich vor Augen... Wo ist mein Fehler, dass meine Beschreibung das Ziel nicht erreicht?

Freut mich, dass sich auch andere darüber Gedanken machen! 1. Zu EAP: Stimmt, Die WLAN-Extension kann das tatsächlich nicht! Nun verstehe ich auch, warum die Studenten sich immer einen eigenen Access-Point aufspannen, den sie ins Netz bridgen. (Darf man laut der internen IT nicht... macht man aber :-| ) Zurück zum Problem: Für mich ist dieser Vergleich ganz klar nicht zulässig! Denn aus meiner Sicht ist das Nutzen eines Gerätes nicht das selbe wie das Konfigurieren eines Gerätes. So darf eine 0815-App auf meinem Smartphone die Fritz-Box (die muss nochmals zum Vergleich herhalten) zwar nutzen, aber sie darf sie nicht konfigurieren.. (und schon gar nicht das Passwort kennen.) Das zielt genau auf den berechtigten Aufschrei von Equinox: Es darf doch nicht sein, dass jemand das Passwort einfach so neu setzen darf, ohne dass er dazu berechtigt ist. Das sehe ich zwar genau so, aber das ist (noch) nicht Teil des Security-Features, welches ich in diesem Thread anstrebe. Es geht hier erst mal 'nur' um die Geheimhaltung eines Geheimnisses. Ach ja, und da bin ich an der Uni doch tatsächlich fündig geworden: In einem fremden Netz (per WPA gesichert), welches der hiesigen Abteilung für Medizininformatik gehört, habe ich eine Tinkerforge-Lösung gefunden, welche via Port-Weiterleitung in das Informatiker Netz zeigt. (Ob das so legitim sei oder nicht... sei nun mal dahingestellt; ich bin fast froh, diesen echten Case gefunden zu haben.) Da hab ich also glatt mal aus dem Informatiker-Netz heraus den brickv auf die Weiterleitung zeigen lassen... und nun bin ich Mitwisser eines Geheimnisses geworden, welches nie für mich bestimmt war. Das ist schlecht. Hier also der practical Proof, dass es mindestens einen Fall gibt, bei dem dank Tinkerforge ein Passwort über die Netzgrenzen hinweg auslesbar ist. Ich frage mich gerade, ob es Leute gibt, welche ihre Tinkerforge-Anlage per NAT/Portforwarding dem Internet zur Verfügung stellen... (So z.B. eine Wetterstation o.ä. ;-) ) Siehe oben... es ist sogar noch schlimmer. Die Beantwortung der Frage nach dem 'warum ist das Passwort einsehbar' durch Borg ergibt 'spitz gesagt', dass die WLAN-Extension einen Merkzettel für (alle) vergesslichen und unwissenden darstellt. Ist das die (?heroische?) Aufgabe der WLAN-Extension... Gibt's dafür nicht 'Merkzettel'? Die insecurity-News in Sachen IoT sprudeln ja momentan nur so! Meistens geht es dabei um das hinausposaunen des WLAN-Passwortes. Ich sehe hier, dass Tinkerforge genau auf Linie fährt; also beim heiteren Rausgeben gut dabei ist. Wie soll also eurer Meinung nach der User eines Smartphones das Problem angehen, dass nun jede App das WLAN-Passwort frei Haus bekommt, sofern sich im Netz eine Tinkerforge-WLAN-Extension tummelt? Denn eigentlich erhält keine App das Passwort, weder durch die Public API von Android noch von iOS. Sie muss das normalerweise über den Benutzer (Social) oder 'dirty-hacks' machen (Rooten). Mit Hilfe von Tinkerforge wird das ganze aber ein legitimer Prozess, der von Tinkerforge ja sogar unterstützt wird und so die Sicherheitsvorkehrungen der anderen Hersteller komplett unterwandert. Lasst doch einfach die Klaranzeige des Passworts weg, dann hat dieser insecurity Thread und Threat ein gutes Ende. Für Vergessliche gibts einen Zettel, auf den diese das Passwort schreiben (und von mir aus hinten auf die WLAN-Extension kleben).

Die Antwort auf das 'gekürzte' Zitat von Borg in Bezug auf meinen Security-Request ist: Setzen 'immer', auslesen 'nie'. Das Setzen bzw. Überschreiben eines Passwortes ist ein Akt der momentan noch nicht geregelt ist (ausser durch die ultimative Autentisierung). Falls auch dieser Akt geregelt werden soll, müsste tatsächlich ein Rollenkonzept eingeführt werden. So z.B durch ein Admin-Passwort (siehe Fritz-Box). Dieses könnte dann nur noch per Hard-Reset zurückgesetzt werden, wobei sämtliche Geheimnisse verloren gehen müssten. Aber so weit sind wir ja bei Tinkerforge noch nicht.... Eins nach dem anderen ;-) Das Wesen meines konkreten Security-Requests gilt aber einzig dem Schutz des Geheimnisses in Bezug auf 'Wissen'. Also, dass kein Geheimnis ausgeplappert wird, dass kein Dritter (über die API) Kenntnis über das Geheimnis erlangen kann. Ob es überschrieben werden darf und von wem, das ist nicht Teil dieses Requests. Die API sollte also um folgende Fähigkeit erweitert werden: Niemand drittes soll Kenntnis erlangen können, welches Passwort gesetzt wurde. Übrigens: Es ist bemerkenswert, dass die grundsätzliche Frage bei dieser Diskussion nicht berührt wurde. Ich will sie somit erneut in den Raum stellen: Diese 'triezende' Frage sollte doch bloss eine Hilfestellung bei der API-Definition sein! Falls es keinen Grund dafür gibt, soll das API dies auch nicht tun. (Hier ist es ein Konjunktiv) Falls es im Gegenzug aber einen Grund gibt, das Passwort nicht preiszugeben... dann darf das API dies auch nicht tun. (Hier wird es zum Imperativ)

Da muss ich in mehrerlei Hinsicht widersprechen. Zuerst vielleicht nochmals die konkrete Frage: Welchen Grund dafür gibt es, das Passwort preiszugeben? Die Fritz-Box, welche ja als Beispiel von Borg aufgeführt wurde, die schreit das auch nicht einfach so raus. Da muss man schon die Fritz-Box selbst administrieren (ein Admin-Passwort kennen), um das WLAN-Passwort in Klartext zu sehen!? Die Authentisierung von Tinkerforge aber ist nicht gleichzusetzen mit dem Admin-Passwort der Fritz-Box. Denn die Fritz-Box bietet ihre Dienste auch Teilnehmern an, welche das Admin-Passwort nicht kennen. Hier zwei Beispiele, bei denen das 'Sicherheitskonzept' Tinkerforge ins leere geht: 1. Einfacheres und gegebenes Szenario (Jedes Semester wieder): Ein WLAN-Netzwerk an der Uni, bei dem jeder Student und Dozent sich mit seinem persönlichen Passwort anmelden muss. (802.1x EAP) Wenn nun ein Student/Dozent mit Tinkerforge und einer WLAN-Extension etwas demonstrieren soll... (simples Beispiel: Ein Dual-Button-Sensor, der von jedem beliebigen Teilnehmer im Netz ausgelesen werden können soll) und dazu sein persönliches Passwort dafür benutzt (etwas anderes gibt es nicht an der Uni)... wie soll er das Passwort denn 'schützen'? Mit der Tinkerforge Authentisierung geht das nicht, da wird sichergestellt, dass fremde im gleichen Netz überhaupt nicht an die Komponente kommen. Die Authentication ist also genau dann hilfreich, wenn jemand Tinkerforge-Komponenten betreibt und nicht will, dass andere 'mitmachen'; was das Gegenteil von dem ist, was das erste Beispiel aufzeigen soll. 2. Beispiel (Das ist ein wüster Hack) Ein Gerät (z.B. ein Android oder iPhone) ist im Netz eingebucht. Die Apps kennen aber das WLAN-Passwort nicht. Nun möchte eine App einer dritten Partei das WLAN-Passwort zukommen lassen... (Vielleicht über Twitter ) Ganz einfach (und ganz ohne Social-Engineering und sogar App-Store-tauglich): Schreibe eine App, welche nach Tinkerforge-Komponenten scanned. Ist auch nur eine einzige Tinkerforge-Komponente im Netz, welche darauf antwortet... bedankt sich das Internet für einen 'easy-Access'. Wenn dann noch mehr an diesem Passwort hängt... um so besser! Kostenlose 'anonyme' E-Mail, oh, das Intranet mit allen Diensten der Uni... herrlich! (Ich werde diese App schreiben und als Tinkerforge-Projekt jedem zur Verfügung stellen... ;-) ) Wo genau wäre denn das Problem, wenn die öffentliche API für IP und USB einfach nur zurückgibt ob das Passwort gesetzt ist, das Passwort aber zurückhält? Ist das aus Design-Gründen nicht möglich? Wo ist der Show-Stopper für diesen Security-Request? Zur Frage, ob die Authentisierung per Default aktiviert sein soll: Hier kommt dann aber sofort das Schlüssel-Verteil-Problem zum Tragen. Wie soll denn dieser Schlüssel bekanntgegeben werden? Per Default aktiv mit: '123456' oder 'changeOnInstall'? Oder klebt dann an jeder Extension ein Zettel? Nein, das erzeugt nur unnötigen Aufwand auf der Benutzerseite, den es nicht geben würde, wenn das WLAN-Passwort zurückgehalten würde.

Danke!

Ich finde es auch nach vielen Jahren Tinkerforge Fan-Boy immer noch absolut unverantwortlich, dass die WLAN-Extensions das WLAN-Passwort freimütig herausgeben. Natürlich kann das Passwort dann (mit ein bisschen mehr Aufwand) ausgelesen werden, wenn man in den physikalischen Besitz der WLAN-Extension kommt. Aber eben... es sollte halt nur dann gelingen. Ansonsten plärrt diese das Passwort sowohl per USB als auch per IP und in der Default Einstellung sogar per Web einfach raus. Warum gebt Ihr das Passwort preis? Gibt es einen echten Grund, dies zu tun? Es gibt auf jeden Fall einen Grund es nicht zu tun: Security! Bitte, überlegt euch die öffentliche API diesbzgl. nochmals! Die öffentliche API (USB/TCP/Web) sollte anzeigen ob ein Passwort gesetzt ist oder nicht, aber nicht... welches! Momentan können die Stacks an Schulen (bei denen die Studenten ihre persönlichen WLAN-Passworte in die WLAN-Extension schreiben) nicht benutzt werden, ohne dass die Studenten ihre Zugangsdaten für E-Mail / und Eduroam / ... auch gleich vollständig kompromittieren. Die Möglichkeit, die Verbindung zu authentisieren (welche ja per Default nicht eingestellt ist), nutzt in diesem Fall ja auch nichts. Wenn die Studenten die verschiedenen Projekte übers Netz zur Verfügung stellen möchten, kann man zwar nur drauf, wenn man die Authentisierung kennt... aber dann hat man wieder vollen Zugriff auf das eingegeben Passwort. Ich bitte euch, schaltet das ab! Die WLAN-Extension ist kein Passwort-Recovery IoT-Unit (wie so viele leider andere auch).

Ist euch schon aufgefallen, dass Tinkerforge die Foren-Passworte unverschlüsselt übers Netz schickt?! Firefox weist doch nun sogar deutlich darauf hin! Oder sollten wir dazu halt einfach Wegwerf-Passworte verwenden? Liebe® WebMaster(in): Es wäre wirklich nett, wenn Du uns entweder Sicherheit geben könntest (=https), oder aber die lästige Passwortabfrage fürs Einloggen im Forum entfernen könntest. Das hindert nur die Guten daran, sich einzuloggen... für die Bösen lässt Du die Tür ja Sperrangel weit offen. Es gibt keine Entschuldigung für nicht https. Ihr habt ja ansonsten bereits ein Zertifikat... und sonst gibts immer noch https://letsencrypt.org/

Hab da glaub ich ein Thread-Alloc no De-Alloc Problem gefunden: Folgender Testcase: while (true){ try{ IPConnection ipConnection = new IPConnection(); ipConnection.connect("host_den_es_nicht_gibt",4223); }catch(Exception ex){ //Hier wirds immer wieder rein kommen, da UnknownHostException } } Das wird ziemlich schnell zu einem MemoryError führen. Grund ist hier: // NOTE: Assumes that socket is null and socketMutex is locked void connectUnlocked(boolean isAutoReconnect) throws java.net.UnknownHostException, java.io.IOException { if(callbackThread == null) { callbackQueue = new LinkedBlockingQueue<CallbackQueueObject>(); callbackThread = new CallbackThread(this, callbackQueue); callbackThread.start(); } Socket tmpSocket = new Socket(host, port); ... Nachdem der callbackThread gestartet wurde, wird ein Socket erstellt und der wirft eine Exception und die Methode wird verlassen... Der Thread aber... der läuft !jeweils! weiter. Vorschlag auf die Schnelle: // NOTE: Assumes that socket is null and socketMutex is locked void connectUnlocked(boolean isAutoReconnect) throws java.net.UnknownHostException, java.io.IOException { try{ if(callbackThread == null) { callbackQueue = new LinkedBlockingQueue<CallbackQueueObject>(); callbackThread = new CallbackThread(this, callbackQueue); callbackThread.start(); } Socket tmpSocket = new Socket(host, port); ... }catch(Exception ex){ callbackQueue.put(new CallbackQueueObject(QUEUE_EXIT, (byte)0,(short)0,0, null)); throw ex; }

Misst... nun muss ich mir merken, zu welchem Relay denn diese Monoflop-Parameter gehören... Naja, ist eure Design-Entscheidung... muss ich akzeptieren.

Ich glaube, Ihr habt in der getMonoflop Methode vergessen, dem Rückgabewert (Monoflop) das Relay anzugeben: Hier Euer code: public Monoflop getMonoflop(short relay) throws TimeoutException, NotConnectedException { ByteBuffer bb = ipcon.createRequestPacket((byte)9, FUNCTION_GET_MONOFLOP, this); bb.put((byte)relay); byte[] response = sendRequest(bb.array()); bb = ByteBuffer.wrap(response, 8, response.length - ; bb.order(ByteOrder.LITTLE_ENDIAN); Monoflop obj = new Monoflop(); obj.state = (bb.get()) != 0; obj.time = IPConnection.unsignedInt(bb.getInt()); obj.timeRemaining = IPConnection.unsignedInt(bb.getInt()); return obj; } Heissen sollte er aber: public Monoflop getMonoflop(short relay) throws TimeoutException, NotConnectedException { ByteBuffer bb = ipcon.createRequestPacket((byte)9, FUNCTION_GET_MONOFLOP, this); bb.put((byte)relay); byte[] response = sendRequest(bb.array()); bb = ByteBuffer.wrap(response, 8, response.length - ; bb.order(ByteOrder.LITTLE_ENDIAN); Monoflop obj = new Monoflop(); obj.relay = relay; obj.state = (bb.get()) != 0; obj.time = IPConnection.unsignedInt(bb.getInt()); obj.timeRemaining = IPConnection.unsignedInt(bb.getInt()); return obj; } Wäre es möglich, dass Ihr das Relay auch noch dort einfüllt... sonst ist das immer 0 und im weiteren Verlauf eines Programs verliert sich die Information... welches Monoflop da gemeint war.

Habe meine ersten Servos vom Typ Towerpro sg90 (http://www.micropik.com/PDF/SG90Servo.pdf) an das Servo-Brick getan. In brickv musste ich nichts ändern, da dieser Servo genau den Default-Werten entspricht. Wenn ich nun die Velocity auf 0 belasse, aber die Position ändere... Dann läuft der gewählte Servo langsam in Richtung Position, bis diese nach ca. 30Sekunden erreicht ist. Warum? Laut Tinkerforge Doku sollte keine Geschwindigkeit anliegen? Mach ich einen Denkfehler? Ist der Servo halt einfach ... billig? Oder ist da noch was zu beachten?

Positives Feedback: Durch das Ersetzen der WiFi-Ext1.0 mit WiFi-Ext2.0 Firmware (2.0.3) funktioniert diese Konstellation nun robust. Beschrieben im Reply 81 von http://www.tinkerunity.org/forum/index.php/topic,3809.msg23395.html#msg23395

YES, WiFi2.0 Firmware 2.0.3 Nachdem ich die Möglichkeit erhalten habe, die neue WiFi2.0 mit Firmware 2.0.3 einzusetzen laufen sämtliche Stapel seit mehreren Tagen ununterbrochen! Rock-Solid! Folgende Tests über mehr als 48h gemacht: Weihnachtsbeleuchtung als zufälliges 'Kerzenflackern' mit Frameduration 100ms. (Temperatur -4°C) 1x WiFi2.0 (2.0.3) 1x Master2.1 (2.4.1) -> LEDStripBricklet1.0 (2.0.6) -> 200xWS2801 Läuft stets! mit kleine Stotterer zwischendurch aber keine Timeouts! Grosses LED-Panel im brickv (Moving Color Dot / Moving Color Gradient) 1x Master2.1(2.4.1) -> LEDStripBricklet1.0(2.0.6) -> 240x SK6812RGBW 1x WiFi2.0 (2.0.3) 1x Master2.1(2.4.1) -> LEDStripBricklet1.0(2.0.6) -> 235x SK6812RGBW 1x Stepdown 1.1 Läuft stets! mit kleine Stotterer zwischendurch und ca. 1-2 Timeouts pro Stunde! und natürlich auch der Test aus dem Posting vom November 16, 2016, 16:34:22: Läuft stets, wie erwartet. Nun bin ich wieder begeistert von Tinkerforge! Danke. (Es wäre nun toll, wenn dies bei der WiFi 1 auch gelingen würde, oder aber diese mit einem Warnhinweis versehen würde. Schöne Festtage und Happy Tinkering!

Nein. Nach ca 34h Online war's dann doch wieder so weit. Der Stack hat sich 'aufgehängt'. Der Motion-Detector leuchtet dann ständig (als hätte er einen MotionDetectCycle am laufen), die blaue LED des Masters flackert zwar noch, aber der Stack ist nicht mehr zu erreichen. Ich habe extra darauf geachtet, ob die FritzBox vielleicht einen Kanalwechsel im bgn-Netz vorgenommen hätte. Nein. War stets auf Kanal 11.

Langsam glaube ich an Sonnenflecke! Motiviert von den neusten Tests habe ich erneut einen Aufbau gemacht: brickv2.3.6 steuert folgendes an (von unten nach oben): StepDown (5V kommt rein... ist ein wenig knapp!) Master2.0 B -> LEDBricklet -> 120xWS2811 D -> LEDBricklet -> 120xWS2811 WiFiExt 1.0 Master 2.1 A -> RotaryEncoder D -> MotionDetector 10ms Frame Duration. Eine LED-Leiste mit 'Moving Color Dot', die andere mit 'Moving Color Gradient' Das läuft seit mehr als 5 Stunden super... habe zwar über 3000 Timeouts aber läuft. Ich verwende eine WiFi-Extension, welche ich auch beim anderen Stack benutzt hatte und welche dort garantiert den Dienst nach wenigen Minuten versagte. Das benutzte Netz ist das selbe wie beim Stapel, der 'zusammenbricht'. Unterschiede zu meinem anderen Aufbau, der fast sofort zusammenbricht: -LEDBricklets sind nun an einem einzigen Master Brick. -LEDs sind von der selben Art. -Andere 'Instanzen' der Master Bricks. (Habe beide Stapel parallel aufgebaut). Warum läuft der? (Sollte ja eigentlich glücklich sein... aber irgendwie ist das ganze spooky) Problem am Rande: Durch den BrickV weiss ich nicht, ob die Events des Rotary bzw. des MotionDetectors noch durchkommen... BrickV polled ja.

Ahaaaa! Herzlichen Dank für die Aufklärung! Nun sehe ich gerade, dass diese Frage bereits einmal beantwortet wurde; danke Photron für die erneute Erklärung. http://www.tinkerunity.org/forum/index.php/topic,2457.msg16090.html#msg16090

Hey Reinweb, danke für die erste Aufklärung. LAN kann bei mir aber nicht in Frage kommen, da ich an dieser Stelle keine Datenleitung habe und der WAF (der durch die häufigen 'Hänger' sowieso schon im <0.xx Bereich) in Richtung 1/unendlich zeigen würde. Wenn das mit den Events, welche zu kurz hintereinander kommen schon die ausgemachte Ursache ist, dann müsste der Master-Brick die WLAN-Extension doch einfach davor schützen... Lieber stottert die Sache 'kurz', als dass sie abstürzt?! Oder aber das verwendete (TCP) Protokoll von TF erlaubt ein Zusammenfassen von Callbacks, aber das wäre sehr tief unten angesetzt... Die WLAN Extension V2 funktioniert denn die? Nach Deiner Aussage vom 02. November scheint ja auch die das nicht zu packen und der 'Watchdog' mit dem Disconnect/Connect Trick muss immer mal wieder ran?!

Ich glaube, an der gleichen Stelle zu scheitern! Wenn ich den brickv benutze und über eine WLAN-Extension 1 einen Stack (StepDown, Master(2)->LEDBricklet, WLAN, Master(2.1)->LEDBricklet, Master(2)->LEDBricklet) anspreche, und 40LEDs, 160LEDs, 192LEDs mit 100ms ansteuere dann bricht !irgendwann! (manchmal nach ein paar Sekunden, manchmal nach so ca. 120') die Kommunikation zusammen... Ich weiss nicht wann und warum; ein Muster konnte ich nicht erkennen. Im brickv sehe ich dann noch die Volt-Angabe sich ändern, aber die LEDs können nicht mehr angesprochen werden. Ich denke, der frameRendered-callback kommt einfach nicht mehr. Dann plötzlich wird die Sache dramatischer, denn brickv versucht einen 'Autoreconnect' o.ä. zu machen, was aber kläglich scheitert... der Stack ist nicht mehr erreichbar. Ich nutze extra brickv, damit dies vom TF-Team auch nachgestellt werden kann! Kann das TF-Team dieses Verhalten bestätigen, oder läuft bei euch... bei irgend jemandem in der TF-Welt ein ähnliches Setting seit Tagen stabil? Da ist doch irgend so ein fieser Race-Condition-Bug im Spiel?! Das muss sich doch finden und eliminieren lassen! Noch ein Hint zu diesem Problem: Habe ein eigenes Programm geschrieben, welches die LEDs (Framerate 200ms) anschaltet, sobald ein MotionDetection-Bricklet (im gleichen Stack wie die LEDs) 'jemanden sieht'. Das läuft dann aber auch nach ein paar Stunden nicht mehr, weil das Event vom MotionDetection-Bricklet nicht mehr ankommt. ABER: Wenn ich dann mit dem brickv auch noch auf diesen Stack zugreife... dann sehe ich die Wechselnden Zustände vom MotionDetector im brickv. Mein ursprüngliches Programm aber, wartet bis auf den St. Nimmerleinstag auf einen Event vom MotionDetection-Bricklet. Ich denke, die FrameRendered-Callbacks 'abzuschalten' würden das Problem mindern, aber es löst es nicht. Aber der Trick mit dem Disconnect/Connect kann doch nicht die offizielle Lösung sein?! So ein 'Watchdog', der immer mal wieder resettet, ist wohl eher ein 'Bill Gate-scher' Ansatz. Bitte guckt euch die Sache nochmal an, da muss eine dreckige Race-Condition im Spiel sein!