macdiverone

Zum Thema Chibi / WLAN: Besser den Spatz in der Hand, als die Taube auf dem Dach... Wieviele Wochen bis WLAN? Wieviele Wochen bis Neuauflage unveränderter Chibi? Whatever is faster! Ohne Funkmodule, wie seit vielen Wochen (!), ist ein Systembaukasten, der sich in seinem Anwendungsschwerpunkt massiv auf Funk stützt, schlicht d..f! Ist wie ein Porsche auf Zieglelsteinsäulen statt Rädern. Reichlich unbenutzbar! Just my 2ct! Go TF, go!

Also ich brauch' mindestens 4!

Aber ich!

+1 Bei der strengen Fokussierung auf eine bestehende Steuerrechneranbindung (fehlende Autarkie) ist der Einsatz der Einheiten so ganz ohne Funkmodule doch arg eingeschränkt. Bei mir jedenfalls ist keine der eigentlich geplanten Verwendungen ohne Funkmodule (oder kompensierende "Verrenkungen") machbar. Momentan liegen die ganzen Erwerbungen daher mangels Einsatzmöglichkeiten (und dank äußerstem Widerwillen gegen "kompensierende Verrenkungen" (=Strippenziehen)) friedlich in einer Schachtel. Auch nicht ganz den Vorstellungen entsprechend. Besser ein möglicherweise suboptimal (aber immer noch) funktionierendes Funkmodul als so absolut gar nichts über Monate hinweg. Just my 2 ct. Dietmar PS: Falls einer noch ein paar ungeliebte Chibi's hat... Immer her damit! Gerne auch gegen Geld.

+1

"Any fool can criticize, condemn and complain and most fools do." — Benjamin Franklin

Bingo! Ich habe den durch die Bindings erzeugten TCP/IP-Übergang (für die noch nicht erhältlichen Module) UND den existierenden brickd gemeint! Und fleißig ausschließlich brickd (vermutlich, weil der entsprechend agiert und den Übergang vom brick via TCP/IP an ein System mit angeschlossenen USB-TF-Modulen realisiert) geschrieben... Alle Übergänge müssen an der jeweiligen Mediengrenze zu TCP/IP dieses Verfahren (und einen ggfs. von 0 abweichenden Schlüssel + "the grain of Salt") kennen und beherrschen. Aber eben nur dort. Und: In der Regel dürfte schon der "Default key: 0" ausreichend sein, um Unfug zu erkennen. Damit wäre dann normalerweise weder in der Anwendung, noch sonstwo etwas zu ändern oder einzutragen... Dietmar

Klar, einmal im brickd und einmal im WLAN-Empfangs-Board...

Es reicht, wenn das immer nur die Kommunikationsprozesse machen. Für die Applikation oder das Bricklet ist das völlige Nebensache. Wenn das jeweils in den "Kommunikationsstack" (also an der "Außenkante" der Kommunikationsbeziehung) eingebaut wird, habe ich -als willkommenen Nebeneffekt- keinerlei Aufwände in der Applikation. Ich kann mich dann einfach darauf verlassen, dass Pakete, die ankommen, schon richtig gekennzeichnet waren. Und die nicht richtig gekennzeichneten: Don't care. Hacker oder fehlerhafte Übertragung...

Es würde reichen, wenn diese MAC-Bildung im brickd ("PC") und im WLAN/ETH-Modul stattfinden würde. Somit wäre der gesamte Vorgang völlig transparent für Anwendung und Master. Initial könnte XOR 0 verwendet werden - so lange, bis ein anderer Key hinterlegt (brickd.conf), bzw. via USB auf den Master eingebracht wird. Ist eine gängige Methode und läuft/lief millionenfach selbst mit schwachbrüstigen MPUs/HSM. Woher ich das so sicher weiß: (NDAs) Dietmar

+1 Dietmar PS: Das hätte wesentlich mehr Charme als die Raspberry Lösung, da: gleicher Formfaktor gleiche Stromversorgung kein Systemübergang kein Medienbruch -> deutlichst kleiner! -> deutlichst genügsamer -> bei den derzeitigen Lieferzeiten für den Pi: deutlichst schneller kaufbar

IMHO würde auch eine in der Netzwerktechnik gebräuchliche Absicherungsmethode (nur gegen unbemerkte Manipulation!) genügen: Der MAC-Code (hat nichts mit Hardware MAC zu tun, sondern ist ein "Message Authentication Code", der schlicht aus einem HASH der Nachricht abgeleitet wird. Dazu müssen beide Parteien (Sender und Empfänger) einen z.B. 32 Bit Schlüssel kennen, der z.B. im TF hinterlegt wird und im Programm benutzt wird. Das Programm (der Dämon in diesem Fall) berechnet für jedes gesendete Paket die Prüfsumme und hängt diese als MAC an die Payload an. Der Parser beim Empfänger macht das auch und vergleicht mit dem empfangenen MAC. Passt er, wird gearbeitet, passt er nicht, geht das Paket ohne viel "Federlesens" in die ewigen Jagdgründe... Ist ein symmetrisches Verfahren mit beherrschbaren Aufwänden und verlangt halt nach Einbringen des Schlüssels (für das XOR mit dem Basis-Hash (einer aus AES/MD5/SHA/...)) auf beiden Seiten. Aber auch nicht zwingend, denn viele Nullen sind schon fast ein wenig eine Eins ;-) Wenn der Defaultschlüssel binär 0 (z.B. 32 Bit) beträgt, ergibt ein XOR damit einfach den mit dem vereinbarten Verfahren ermittelten HASH. Und der ist ziemlich eindeutig. Und er reicht als MAC in der Regel schon dicke aus, um gegen Übertragungsprobleme und "Möchtegern Hacker" zu schützen... Dafür gibt es eine zuverlässige Ausscheidung von "Ramsch" und transportiert keine Passwörter im Klartext in der Gegend umeinander. Bei erhöhtem Aufkommen von Paranoia kann auch "a grain of Salt" hinzugefügt werden. Ich denke, dass die Authentifikation der "guten" Pakete in jedem Fall (jedenfalls bei allen mir derzeit einfallenden Anwendungen der TF-Module) ausreichend sein sollte. Damit wäre auch das Port-Forwarding ausreichend und mithin so alles, was sich halbwegs aktuell heute als Router bezeichnet, nutzbar. Einer späteren Ausweitung auf bestimmte Teile der Informationen oder gar der gesamten Nachricht als Verschlüsselungslösung sollte damit auch (außer Speicher und/oder Prozessor) nichts im Wege stehen. Dietmar

Funk ist ein MUSS! Bin mit mehreren Vorbestellungen dabei! Dietmar