Loetkolben

Hallo photron, danke fuer den Tip. :-) Kommt aber erst beim naechsten start des brickd zum tragen. Bis dahin warten wir und harren der Dinge die da kommen. Der Loetkolben

Hallo photron. "dmesg" zeigt mir nur die Eintraege an die seit dem letzen Boot reingeschrieben wurden, also kann ich zu dem Haenger nichts sagen. Unter /var/log/dmesg.* finde ich nur alte Files, die durch das automatische Backup gesichert worden sind. Wo sollte das dmesg von VOR dem aktuellen re-boot sein? Das hatte ich bei den letzten Abstuerzen noch nicht an. Also muss man auf den naechsten Absturz warten. BTW: Koenntet ihr bitte das Datum mit ins Logfile schreiben! Anstelle von: "20:53:22 <INFO> <usb_device.py:113> Adding read transfer" Dies bitte daraus machen: "20120620_20:53:22 <INFO> <usb_device.py:113> Adding read transfer" Ich schliesse keine Wette ab woran es liegt. Ich habe schon viele Geister gesucht und ich bin auch gespannt in welchen Verlies wir rauskommen. Der Loetkolben

Hallo photron. Vielen Dank fuer die Unterstuetzung. Der PC wurde mittlerweile faelschlicher Weise ueber den Powerknopf runtergefahren und danach fuhr er sauber wieder hoch. Ich hoffe dass ich nicht wieder 2 Wochen warten muss bis das Problem auftritt. :-) Zu Deinen Fragen: Das System ist ein Debian Suqeeze "aus der Tuete". Es ist auf dem aktuellen Stand. # uname -a Linux PC 2.6.32-5-486 #1 Sun May 6 03:29:22 UTC 2012 i586 GNU/Linux # cat /etc/debian_version 6.0.5 # dpkg -l| grep libusb ii libusb-0.1-4 2:0.1.12-16 userspace USB programming library ii libusb-1.0-0 2:1.0.8-2 userspace USB programming library PC# deborphan -d libusb-0.1-4 libusb-0.1-4 usbutils gnupg udev PC# deborphan -d libusb-1.0-0 libusb-1.0-0 libdc1394-22 brickd Der Masterbrick war immer mit Hub dazwischen dran. Frueher war nur die Cam dran, da brauchte man noch keine Hub. Entweder nehme ich mal einen anderen USB Hub oder haenge Cam+USBBootDevice an Port1 und Masterbrick ohne Hub an Port 2 So, nachdem nun im Moment wieder alles laeuft werde ich mir die Sache weiter ansehen. Auch die Begleitumstaende werde ich genauer beobachten und hoffentlich werden wir schlauer. Die Aenderung in "src/brickd/usb_device.py" habe ich noch nicht gemacht. Ich ueberlege ein weiteres Sytem so aufzusetzen und an einer anderen Location zu plazieren. Da muss es aber problemlos durchlaufen. :Schauder: Weiter Abstuerze werde ich "vermelden" und ueber jeden guten Tipp bin ich dankbar. Der Loetkolben

Hallo photon. Entschuldigung, das hatte ich mal in einem anderen Beitrag geschrieben und ich wusste nicht, dass du es testen wolltest. @all Debian: -q1 schliesst Verbindung nach dem Absenden (z.b. fuer set_io4_port1) -w1 wartet noch auf Rueckantwort (z.B. fuer get_temperatur) Ubuntu: -q1 wartet auch auf Rueckantwort (z.B. fuer get_temperatur) -w1 wartet nicht ab! Ob es ueberhaupt eine Funktion hat weiss ich nicht. Usb 0,3m, dann 1m zum Temp.Bricklet und 1m zum IO4 Bricklet. Motoren und Gewitter sind es nicht. Bei dem heutigen Absurz gegen 11:20h (siehe Logfile unten) koennte es sein, dass der ArbeitsPC eingeschaltet worden ist. Dort ist eine 10-fach Steckdosenleiste mit 200W PC, 2 Monitoren, 2 Watt Lautsprecher und einer SchreibtischNEONlampe. Phyisch ist dieser Computer ueber einen Ethernetswitch mit dem MiniPC verbunden an dem das MasterBrick haengt. Natuerlich auch uebers Stromnetz verbunden. Das koennte ein Hinweis sein, ABER das kann nicht das Problem sein als sich das Brick mitten in der Nacht verabschiedetet hat. Wird das eine Gleichung mit 3 Unbekannten oder ein Ueberraschungsei mit 3 gleichzeitigen Fehlern? Das mit dem flashen muss ich verschieben, werde ich aber mal machen. Aber kommen wir zur aktuellen Situation: Um 11:27 war es wieder soweit. Anbei das Logfile mit Kommentaren, wobei mir besonders diese Zeile auffaellt: 11:21:48 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect Was hat die zu bedeuten? Wie muss ich das Logfile ab 11:21h interpretieren? # Abruf 10:00h. OK. 10:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99977cc> 10:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 10:00:01 <INFO> <usb_device.py:311> Write to device: 1 10:00:01 <INFO> <usb_device.py:184> Write callback length: 4 10:00:01 <INFO> <usb_device.py:275> Read callback: 1 10:00:01 <INFO> <brick_protocol.py:74> Callback: 1 10:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99977cc> # Abruf 11:00h OK. 11:00:02 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99977ec> 11:00:02 <INFO> <usb_device.py:158> Add callback for message: 1 11:00:02 <INFO> <usb_device.py:311> Write to device: 1 11:00:02 <INFO> <usb_device.py:184> Write callback length: 4 11:00:02 <INFO> <usb_device.py:275> Read callback: 1 11:00:02 <INFO> <brick_protocol.py:74> Callback: 1 11:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99977ec> # Keine Aktion - Keine Abfrage - Logfile ungekuerzt. 11:21:48 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect # Warum sind hier 6 Sekunden Pause? 11:27:13 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <usb_device.py:126> Deleting USB device 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <INFO> <brickd_linux.py:95> Removed USB device 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 11:27:16 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it # Abruf 12:00h nicht moeglich 12:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99946ec> 12:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99946ec> Der Loetkolben

Hallo noop. Interessantes Thema. Lese mal hier weiter: Sanitycheck und Passwort fuer Bricks beim Zugriff "von aussen" Vielleicht nur ein Thread? Der Loetkolben

Noch ein Nachtrag: Da hat jemand den Resetknopf am Masterbrick gedrueckt waehrend der brickd gestartet war und das kommt dabei raus: 20:53:17 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 20:53:17 <INFO> <brickd_linux.py:95> Removed USB device 20:53:17 <INFO> <brickd_linux.py:95> Removed USB device 20:53:22 <INFO> <brickd_linux.py:92> New USB device 20:53:22 <INFO> <usb_device.py:113> Adding read transfer 20:53:22 <INFO> <usb_device.py:113> Adding read transfer 20:53:22 <INFO> <usb_device.py:113> Adding read transfer 20:53:22 <INFO> <usb_device.py:113> Adding read transfer 20:53:22 <INFO> <usb_device.py:113> Adding read transfer 20:53:22 <INFO> <usb_device.py:121> Adding write transfer 20:53:22 <INFO> <usb_device.py:121> Adding write transfer 20:53:22 <INFO> <usb_device.py:121> Adding write transfer 20:53:22 <INFO> <usb_device.py:121> Adding write transfer 20:53:22 <INFO> <usb_device.py:121> Adding write transfer 20:53:22 <INFO> <usb_device.py:331> Calling get_devices on: <usb_device.USBDevice instance at 0x998ddac> 20:53:22 <INFO> <usb_device.py:311> Write to device: 254 20:53:22 <INFO> <brickd_linux.py:92> New USB device 20:53:22 <INFO> <usb_device.py:184> Write callback length: 4 20:53:22 <INFO> <usb_device.py:349> New device Master Brick 1.0 with Stack ID 1 20:53:22 <INFO> <usb_device.py:275> Read callback: 253 20:53:22 <INFO> <usb_device.py:349> New device Temperature Bricklet 1.0 with Stack ID 2 20:53:22 <INFO> <usb_device.py:275> Read callback: 253 20:53:22 <INFO> <usb_device.py:349> New device IO-4 Bricklet 1.0 with Stack ID 3 20:53:22 <INFO> <usb_device.py:275> Read callback: 253 20:53:52 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x999482c> ... Der Loetkolben

Hallo photron, danke fuer die Unterstuetzung. Ich lese die mit netcat aus. Ungefaehr so: echo -n -e "\x$STACKID\x01\x04\00" | nc -w1 $HOST 4223 Deshalb kommt wahrscheinlich immer eine neue IP Connection zu stande. Diese Abfrage erfolgt im Normalfall 1 mal pro Stunde. (Im obingen Logfile waren es Testaufrufe) Nach dem Umstecken sieht der USB Port seit 2 Wochen so aus: USB1.1_Port -- USB2.0_Hub +-- Masterbrick_mit_0,3m_Kabel +--Webcam_mit_1m_Kabel Die Webcam laeuft problemlos weiter. Der Rambedarf hat sich vor den Abstuerzen nicht veraendert, so dann man annehmen kann, dass es kritische Stelle ueberschritten wurden. Aber mal weitergedacht: Da sich die Abstuerze/Disconnects immer schneller ereignen scheint evtl eine andere Resource zur Neige zu gehen. Welche koennte das sein? Ich will beim besten Willen weder dem brickd noch dem Masterbrick die Schuld an den Problemen geben, aber egal wo das Problem ist, wenn es Auftritt kann man sie nicht mehr absprechen. Ich bin mir auch bewusst, dass der Rechner schmal bemessen ist, aber nach meiner Einschaetzung ist er ausreichend dimensioniert um diese beiden Aufgaben zu erledigen. Die durchschnittliche CPU nutzung der 200Mhz CPU liegt bei 15%. Wie kann ich helfen um das Problem zu finden? Edit: Nachtrag. Der Masterbrick muss aber noch ansprechbar sein! Masterbrick wird noch gelistet. Zur Zeit ist der brickd "stoped". lsusb Bus 001 Device 017: ID 16d0:063d GrauTec (2. USB Port) Bus 001 Device 016: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader (2. USB Port) Bus 001 Device 014: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 (2. USB Port) Bus 001 Device 005: ID 058f:6254 Alcor Micro Corp. USB Hub (2. USB Port) Bus 001 Device 003: ID 14cd:125a Super Top (1. USB Port) Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub (System) Ich gehe davon aus, dass wenn ich den Masterbrick vom USB abziehe, dass lsusb ihn auch nicht mehr anzeigt. Dementsprechend muss noch eine Kommunikation moeglich sein. Der Loetkolben.

Thanks for information, but keep in mind that this is a USB 1.1 Extender! If you use USB 2.0 Devices on both sides, errors may occur. Maybe you can switch down your PC USB Port to USB 1.1 or better try this: PC_with_USB20 --- old_USB1.1_aktive_Hub --- Extender ~~CAT~~ Extender --- Masterbrick. This should give USB1.1 signals onto Extenderconnection! If you use an 4 Port USB 1.1 active Hub, you can connect 4 Extender to it. Der Loetkolben

Mache ich einen neuen Thread auf oder geht es hier weiter? Nachdem nun 2 Wochen ruhe war ist es wieder soweit. Man kann vom brickd keine Daten mehr bekommen. Vor 3 Tagen brickd neu gestartet. OK Vor 2 Tagen musste brickd neu gestartet werden und Reset am Masterbrick. OK. Heute 15:00h brickd neu starten. Reicht aus. OK. Heute 18:00h brickd neu starten reicht nicht. (Resetdruecker im Moment nicht verfuegbar. Daraufhin habe ich den Loglevel mal auf "Debug" gestellt. Die Temperaturabfragen bleiben unbeantwortet. Frage: Was soll mir das Logfile sagen? Was muesste drinstehen? Kommuniziert der Brickd noch mit dem Masterbrick? Kann ich den Masterbrick remote resetten? ... Die Speicherauslastung sieht immer noch aehnlich aus. Wo ist das Problem? Vielleicht kommen wir ein wenig weiter. Viele Gruesse Der Loetkolben

Ja ich gebe euch ja allen Recht bis auf eine Ausnahe: Wo koennte man ein Humidity Bricklet sinnvoll ohne Temperatur Bricklet einsetzen? Der Loetkolben

Jein. Nur eine Frage: Wer hat ein Humidity Bricklet gekauft OHNE auch ein Temperatur Bricklet gekauft zu haben? Mein Vorschlag: Temperatur einzeln (wie bisher, wegen dem guenstigen Preis) Humidity+Temperatur (Anstelle von Humidity einzeln) Ambient (wie bisher, wegen dem guenstigen Preis) Luftdruck+Ambient (Anstelle von Luftdruck einzeln) Wie schon mal angesprochen faende ich "universal" Bricklets gut. Seriell (RS232 zum steuern), I2C (Nur Platine mit EEPROM), LCD ohne Display, ... Der Loetkolben

Will man das? Du lieferst gerade das beste Argument GEGEN eine automatische/integrierte Updatefunktion: Bugs. Auch wenn die Tinkerforge Hard- und Software einen sehr ausgereiften Eindruck macht, moechte ich es nicht ausschliessen, dass bei der Kontrolle mal eine Verison durchrutscht die Probleme macht. Dann waeren produktive Systeme betroffen. Ein Versionsmanagement (Check der installierten gegen verfuegbare Versionen) hingegen, faende ich recht gut. Der Loetkolben

Hallo photon, danke fuer die Unterstuetzung. Die gruene Linie muesste der "commited" memory sein (Vergleiche Farben), wobei ich nicht verstanden habe was dieser Wert bedeutet. Die Scalierung muesste ebenfalls links sein, also MB. ICH denke/dachte: Es ist der Speicher der angefordert wird?? Was das bedeutet und warum die Swapspeicherauslastung nicht ansteigt weiss ich nicht. Die Maschine hat 96MB Ram (80 System + 16 Shared Graphics) + 32 MB Swap auf SD Card. Wie kommst du auf die Aussage, dass das anschliessen eines Bricks 15MB kostet? Meinst du den Uebergang von Punkt 6 auf Punkt 7? Seit einer Woche ist ruhe. Kein Reboot, kein Absturz. Siehe Grafik. Da es keine Fehler gibt, obwohl die Grafik "unschoen" aussieht, habe ich das Thema erstmal nicht weiter verfolgt. Was soll ich denn machen? Brickd mal stoppen oder hast du andere Vorschlaege? Viele Gruesse Der Loetkolben

Hallo Wumpus, anscheinend kann ich im Fehlerfall auch den Masterbrick nicht abfragen. Ich habe kein "master_get_chibi_signal_strength", sondern habe eine Enumerationsanfrage geschickt. Da kam dann nichts zurueck. Ich muesste mal versuchen eine Abfrage zu machen die nur den Masterbrick betrifft, wie z.B. Firmwareversion abzufragen. Den brickv habe ich im Fehlerfall nie so lange arbeiten lassen, werde es aber mal machen. Im Moment laeuft alles stabil. @Tinkerforge: Bei dieser Kaffesatzleserei waere es total super, wenn der brickd ein Logfile schreiben wuerde (Z.B Jeder Zugriff von aussen protokolliert) und man so festellen kann, ob der brickd oder die Kummunikation zum Masterbrick haengt. Weiterhin waere eine Abfrage, z.B. der Versionsnummer vom brickd super. Damit koennte man im Fehlerfall auch festellen wo das Problem ist und es haette noch einen gewissen nutzen! :-) Der Loetkolben

Hallo borg, leider nicht wirklich. Es dauert ein paar Stunden oder etwas mehr und dann kann man keine Werte mehr abfragen. Geb mir bitte mal einen Tipp: Situaltion: Masterbrick nicht abfragbar. Dann habe ich folgens gemacht: brickd neu installiert mit Version 1.0.7 - Weiterhin keine Datenabfrage moeglich Warum bekomme ich bei lsusb eine Rueckmeldung? Was heisst das? Hat sich der Masterbrick aufgehangen oder nicht? Kann ich den brickd irgendwie zu Debuginformation ueberreden? Kann man irgendwie eingrenzen wer nicht mehr redet und warum? Kann es mit dem hohen Speicherverbrauch vom brickd zu tun? Einen Reset am Masterbrick selbst kann ich erst spaeter durchfuehren lassen. Ein funktionsfaehiges "usbreset" Tool gibt es wohl nicht. Der Loetkolben. Nachtrag 23:09h: Resetknopf gedrueckt am Masterbrick. Sonst nichts. Sofort konnten wieder Werte abgefragt werden. Lasse nun den Masterbrick mal mit dem neu installierten brickd 1.0.7 laufen. Die obigen Fragen bleiben aber noch offen.

Hallo ThomasKl, danke fuer die Idee! Die Frage bleibt: Was hat sich aufgehaengt? Brick oder brickd? Muss da etwa ein Hardwarewatchdog her? Hat die CPU einen an Board? Der Loetkolben

Ich antworte mal mir selbst. 0:1 Verloren! Der 1.0.7 brickd melde nichts zurueck! Wenn ich mich mit dem brickv auf den brickd verbinde kommt die Verbindung ohne Fehlermeldung zustande, aber es wir kein Brick oder Bricklet angezeigt. Die einzige Aktion die ich machen kann ist ein "Disconnect". Eine Enumerateanfrage per TCP Paket bekommt keine Anwort. Aus meiner Sicht kann man doch mit dem brickd kommunizieren. Kann man den nicht fragen wo denn das Problem ist?? Edit: Ich war auf den kilometerlangen Arm der den Masterbrick resetten kann. Masterbrick hat aktuelle FW 1.1.7 Der Loetkolben

Das ist die Frage. Was haengt und was geht noch? Hat sich der Masterbrick oder der brickd aufgehangen? Wenn der brickd noch ansprechbar ist, kann er dann via USB noch einen Reset am Masterbrick ausloesen? Kann man das mit einem USB Kommando (Debian) erreichen? Die Errormessage stammt NICHT vom letzten Aufhaengen. Das konnte ich am Timestamp des Logfiles (war ca. 2 Tage alt) sehen. Einen Grund fuer die letzten Haenger kenne ich nicht. Welche brickd Version habe denn am laufen?? Nehme mal den neuen brickd. Danke fuer den Hinweis! Bisher: root@PC:~# dpkg -l | grep brickd ii brickd 1.0 Brick Daemon Neu: root@PC:~# dpkg -l | grep brickd ii brickd 1.0.7 Brick Daemon Wie sagt Franz? Schauen wir mal. ... Der Loetkolben

Hallo macdiverone, kann es sein, dass du den Tinkerforgesoftwareweg nicht so genau kennst? Das WLAN-Board ersetzt den sonst benoetigten zusaetzlichen brickd. Ein Wlan-Board wird nie mit einem brickd kommunizieren. Ich unterstelle mal die meinst mit brickd die Bindings?! [Application-->Binding] --->TCP/IP---> [brickd-->Masterbrick] [Application-->Binding] --->TCP/IP---> [ETHERNETextension-->Masterbrick] [Application-->Binding] --->TCP/IP--->WLAN---> [WLANextension-->Masterbrick] Der Loetkolben

Hallo macdiverone, das verstehe ich, aber es muss doch auf beiden Seiten des Uebertragungsweges passieren nicht auf beiden Ebenen einer Seite oder? Also: Zum einem auf dem PC, der die Paket verschickt und zum anderen Auf dem brickd/Ethernet/Wlanbrick wenn er Pakete verschickt. Dass das nicht in den Applikationen gemacht werden muss ist mir schon klar. Wenn ich selbst IP Pakete erzeuge muss ich natuerlich selbst die Aufgabe des Stacks uebernhemen. Der Loetkolben

Ich habe nicht verstanden warum es aussreicht es nur dort stattfinden zu lassen. Meinst du das berechnen und verschicken oder das entrechnen und verarbeiten? Der Loetkolben.

Hallo zusammen, ab und zu haengt sich der Masterbrick anscheinend auf und man kann keine Werte abfragen. Ein stop und start des brickd auf dem Debian hilft auch nichts. Es reicht aber aus einmal den Resetknopf zu druecken. Mein Arm ist aber nicht kilometerlang! Kann man das auch mit einem Tool machen? Wie sieht es eigentlich mit dem Logfile des brickd aus? Im letzten Fehlerfall wurde nichts reingeschrieben (Zeitstempel des Logfiles selbst) und auch ansonsten sieht es recht duerftig aus. Ohne richtige Zeitstempel wird das nix. /var/log/brickd Waere wenigstens super wenn der brickd schreiben wuerde, dass er das Masterbrick nicht erreichen kann. Das der brickd selbst erreichbar ist kann man daher sehen, dass ein MasterbrickHardwareReset reicht ohne den brickd neu zu starten. Der Loetkolben

Hallo Dietmar, danke fuer die Info, aber ich moechte das nochmals fuer mich zusammenfassen: Deiner Meinung nach soll an jedes Paket (in beide Richtungen) ein Checksumme angehaengt werden, die aus dem Paketinhalt und einem geheimen Key gebildet wird. Der Key steckt auf der einen Seite im Ethernetbrick/Wlanbrick/brickd und auf der einen Seite im PC Programm. Damit kann ein empfangenes Paket geprueft und bei gueltiger Pruefsumme weiterverarbeitet werden. Der Inhalt selbst wird weiterhim im Klartext uebertragen. Wenn dem so ist, dann erfuellt das zu 120% meine Wuensche und kann ggf. auch noch Tinkerforge ueberzeugen. Danke. Der Loetkolben

Hallo SierraX. :WARNUNG: Mach es nicht! Diesen Fehler habe ich bei Enumerierungsabfrage gemacht, wobei ich das der Feld der UID nur so weit genutzt habe wie die UID lang ist. Das hat unschoene Seiteneffekte gehabt. Die eigentliche Abfrage mit der UID im kurzen Feld hat funktioniert, aber die naechsten Abfragen von anderen Bricklets haben dann gehangen. Als ich dann das UID Feld mit \x00 auf 8 Bytes aufgefuellt habe, hat die eigentliche Abfrage weiterhin und auch die anderen Anfragen reibungs funktioniert! Genaues im ersten und letzten Post von mir hier: [geloest] [TCP] Master Brick "Resolve UID" behindert Bricklet Auch deshalb will Tinkerforge einen Sanitycheck einbauen! S.o. Der Loetkolben.

Eine "Fritz!Box Fon Wlan" eben. Da gab es noch keine Nummern. Steht nicht bei mir, sondern an einem anderen Standort. Diese Boxen haben noch nie was von VPN gehoert und man muss viel fummeln um da ein VPN anzuflicken. Wie gesagt: Portforwarding koennen die Fritzboxen schon ewig. Der Loetkolben