C++Guns – RoboBlog blogging the bot

Part 1.1 Build a chassis with two motors, caster, battery, and some space for sensors and electronics

Ich möchte hier ein paar Fotos von Amee zeigen, wie sie noch mehr oder weniger im frühen Aufbau war.

Das Chassis besteht aus einem Rechtwinkligen Rahmen aus Aluminium Vierkantrohre. Vorne sind zwei Motoren mit jeweils 27W angebracht. Hinten befindet sich ein frei drehendes Stützrad

Die Getriebe mit einer Untersetzung von 60:1 sind selbst gebaut. Die einzelnen Wellen sind mit Kugellager versehen.

An der Radwelle befindet sich die selbst gefräste Encoderscheibe mit Lichtschranke.

Als Räder dienen Inlinescater Rollen mit selbst gefrästen Muttern. Ein Dank hier an Lötmichel.

Zwischenzeitlich wurde Amee um zwei weitere Ebenen nach oben hin erweitert. Auf der mittleren Ebene ist Raum für weitere Elektronik, wo hingegen ganz oben das Netbook seinen Platz hat.

Hab heute morgen mal schnell ein kleines c++ Progrämmchen geschrieben welches magische Quadrate [1] mit einer ungerade Seitenlänge erzeugt. Viel Spass damit.

magischesquadratcpp.gz

[1] http://de.wikipedia.org/wiki/Magisches_Quadrat

chroot [1] ist sozusagen der Sandkasten für nicht vertrauenswürdige Programme. Der Browser ist höchstgradig nicht vertrauenerweckend. Er steht immer im Mittelpunkt wenn mal wieder Lücken gefunden werden. Natürlich, es ist das Programm, welches am meisten Kontakt mit dem Internet hat. Und noch dazu wird durch ihn völlig fremden Code und Programme ausgeführt. Ich rede von Javascript, Java, ajax oder wie sie heutzutage alle heißen. Niemand gibt mir die Garantie, dass die zu-geladenen Programme nicht irgendetwas tun, was ich nicht will. Mir Löcher in meine Firewall schießen (UDP Hole punching) oder meine Daten durchstöbern (Bundestrojaner), oder mir mit Java und upnp auf dem Router eine Portweiterleitung einrichten.

Nun, gegen Keylogger schützt es nicht, aber ich kann die chroot Umgebung innerhalb von Minuten neu aufsetzen und so ungewollte Programme schnell loswerden.

Eigentlich alle Anleitungen für chroot waren mir zu kompliziert. Ich bevorzuge die faule Methode. Ein schlankes Debian wird in einer VM installiert, das so erzeugte Image gemountet und als chroot Umgebung verwendet. Sicher gibt es noch andere Wege, aber mir gefiel die Idee irgendwie.

Für die VM habe ich QEMU verwendet. Dazu schreibe ich jetzt keine Anleitung, es gibt sie genügend im Internet. Wichtig ist nur, dass das Image im RAW Format vorliegt, damit man es mounten kann. Und ihr solltet das Image nicht zu groß wählen. 2gb langen dicke. Das ist auch der Nachteil an meiner Methode. Sie verbraucht viel Platz. Aber ist das im Terabyte Zeitalter ein Thema?

Mit fidsk kann man sich die Partionen des Images ansehen.
#fdisk -lu browser_raw.img

Wichtig ist die Angabe für die Größe eines Sektores (512 Byte) und der Startzahl der Partion (63). 512 * 63 ergibt dann den Offset von 32256.

Als nächstes wird das Image gemountet.
# mount -o loop,offset=32256 browser_raw.img chroot/

Dann braucht es noch ein paar andere Kleinigkeiten

# mount -o bind /proc chroot/proc/
# mount -o bind /dev/ chroot/dev/
# mount -o bind /dev/pts chroot/dev/pts
# mount -o bind /tmp/ mnt/tmp/

Nun kann man die chroot betreten
# chroot chroot/ /bin/bash

Nun sollte man zum User werden und z.b. arora starten.

[1] http://de.wikipedia.org/wiki/Chroot

Der Staat möchte uns überwachen, zur unserer eigenen Sicherheit natürlich. Für alle, die selbst für ihre Sicherheit sorgen wollen (traue niemanden), hier eine kurze Anleitung, wie man seine Daten verschlüsselt am Provider vorbei bringen kann. Dazu braucht es einen externen Rechner mit ssh Zugang. Mit folgenden Befehl erzeugt lokal ein Socks Proxy auf Port 7070

ssh -2 -N -l username -D7070 IP

Jetzt braucht man im Firefox unter den Proxy Einstellungen beim Socks Proxy nur noch localhost 7070 eintragen und schon wird der gesamte Verkehr via ssh verschlüsselt an den ext. Rechner übertragen.

Damit auch DNS Anfragen über ssh übertragen werden, muss man im Firefox in about:config nur den Eintrag network.proxy.socks_remote_dns auf true setzten.

Falls jetzt der Stop Filter anspricht, bekommt erstmal jemand anderes die Probleme.

PS. Möchte nicht jemand einen ausländichen Server dafür anmieten?

In diesem Post möchte ich nicht erklären wie UDP Hole Punching funktioniert, sondern mir nur schnell die Befehle notieren.

Client starten. -u = UDP; -l = listen;
local/1# nc -u -l -p 14141

Ein Paket an den remote Rechner senden. -c = count; -2 UDP Mode; -s source port, -p = dest port
local/2# hping2 -c 1 -2 -s 14141 -p 5353 remote

Oder ohne root
nc -p 14141 -u remote 5353

Nun kennt NAT eine gültige IP+Port und leitet eingehende Pakete weiter

remote# echo "hello" | nc -p 5353 -u local-fw 14141

Das ganze ist mehr oder weniger geklaut [1] . Weitere Informationen gibts unter dem Suchwort STUN und [2]

[1] http://www.heise.de/security/Wie-Skype-Co-Firewalls-umgehen--/artikel/82054/1
[2] http://www.ietf.org/rfc/rfc3489.txt

50MHz Oszilloskop bei Ebay für 116Eur gekauft. Und ich freue mich wie ein Osterhase

Der Hintergrund ist folgender:
seit einem Jahr bin ich auf der Suche nach einem Oszilloskope. Ein gebrauchtes, altes, analoges mit 20MHZ ohne Qualitätsname würde mich schon langen. Jeder sagt mir, 50Eur, aber nicht mehr ausgeben. Nur gibt es keinen der seins für 50Eur verkauft, selbst bei Ebay gehen die alten Dinger für 150Eur weg. Und dann kam da dieses eine Angebot in Ebay. Ein 50MHz Oszi, gebraucht mit allen möglichen Kabeln. Die Kabel allein hatten neu 200Eur gekostet. Die Reaktion der Leute war vorraus zusehen. 150Eur? Nie im Leben geht das Ding für so wenig weg. Man muss allerdings auch erwähnen, dass 25Eur versicherten Versand anfallen. Das hat bestimmt die meisten Leute abgeschreckt. Also hab ich mal bis 125Eur mitgeboten. Ich war mir so sicher, dass ich überboten werden. Klick, 3, 2,1 meins. Für 91Eur + Verstand. *staun*

Von wegen 150Eur. Jetzt hab ich ein besserers für weniger

Nun, ganz so einfach war es dann doch nicht. Musste zwei mal den Weg zur Bank antreten, da es für eine Überweisung nach Österreich die IBAN Nummer und die Europäische Überweisung braucht. Wieder etwas gelernt... Nu warte ich bis Ostern vorbei ist. Warum müssen auch so viele Feiertage zwischen mir und meinem Oszi liegen.

Es sollte eigentlich nicht vorkommen, aber dennoch passiert es, dass sich TCP Verbindungen nicht abbauen, wenn die Verbindung eigentlich beendet wurde. Das passiert z.B. wenn man den Drucker ausschaltet, wenn er gerade Daten empfängt. Diese tote TCP Verbindung kann man sich mit netstat -ntpa anzeigen lassen

tcp 0 0 192.168.0.103:33419 192.168.0.200:631 VERBUNDEN -

Im letzten Feld steht normal die PID und der Name des Programmes. Die Verbindung würde sich beenden, wenn Daten durch sie geschickt werden. Da der Remote Rechner aber nicht läuft, würde kein Antwortpaket zurück kommen welches die Verbindung beendet.

Nun möchte man die Verbindung aber beenden, ohne neu zu starten. Unter BSD gibt es das Programm tcpdrop, welches Verbindungen ganz einfach beendet. Aber anscheinend hat es niemand nach Linux portiert. Also behelfen wir uns anders. Mit netstat -nptae kann man sich die inode der Verbindung anzeigen lassen

tcp 0 0 192.168.0.103:33419 192.168.0.200:ipp VERBUNDEN root 252919 -

Die inode ist im vorletzten Feld gelistet. Ein einfaches lsof | grep 252919 liefert auch endlich die passende PID

ipp 27904 root 6u IPv4 252919 0t0 TCP 192.168.0.103:33419->192.168.0.200:ipp (ESTABLISHED)

Die PID steht an zweiter Stelle. Nun kann man den Process auch mit kill 27904 beenden. netstat bestätigt dies mit einem FIN_WAIT1

tcp 0 1 192.168.0.103:33419 192.168.0.200:631 FIN_WAIT1 0 0 -

Und nach ein paar Minuten ist sie dann auch ganz weg.

Heute hab ich mich nur diesem Wasserradprojekt gewindmet. Am Morgen noch schnell die Platine zusammen gelötet und das erste Testprogramm aufgespielt. Natürlich funktionierte erst einmal garnichts. Am meisten Probleme hatte ich mit dem USART. Die Werkseinstellung des Mikrocontrollers ist ein 8MHz int. RC OSzi mit einem Teiler von 8, ergibt 1MHz. So hatte ich es eingestellt, es kamen dennoch nur wilde Zeichen in der Konsole an.

Die Fusebits konnte ich auch nicht umstellen. Irgendwann kam ich dann mal auf die Idee, ein Update für meinem Programmer zu besorgen. Danach konnt ich die Fusebits auch einstellen. Und schon funktionierte USART.

Das zweite Problem war, dass ich vergessen hatte den Pin "Test" des FD232 Chips an Minus anzulöten. Ist er nämlich unbeschaltet, reagiert der Chip kein Stück. Wie schnell man doch solche Kleinigkeiten übersieht. :(

Im Museum gibt es derzeit eine Sonderausstellung über meinen Ur-Opa zu bewundern. Gestern, bei der Eröffnung habe ich versucht alles zu filmen. Zugegeben, ich habe etwas gebraucht um alle Knöpfe an der Kamera zu finden und wie man was wo tun muss, damit auch das ext. Micro funktioniert, aber letztendlich ist wohl die neue Kasette kaputt. Beim Abspielen kommen dicke Streifen in das Bild und sie gehen auch nicht wieder weg. Auch wenn ich es auf den PC per Firewire überspiele, sind sie noch da. Nehme ich hingehen direkt von Kamera auf PC auf, sind sie nicht da.

Das wäre nur halb so schlimm, wenn der Sound da wäre. Aber kaum hält mein Vater seine Rede, ist die Klimaanlage an und man versteht garnichts mehr. Noch dazu ist der Sound total abgehackt. Nun, daran kann man leider nichts mehr ändern.

Aber ich wolte in diesem Aktikel wieder etwas über Windows lästern. Letzte Nacht bin ich auf die Idee gekommen, dass der DV Ausgang an der Kamera gleich der Firewire Eingang am PC ist. Und nachdem ich es auch nach ein paar Minuten geschafft hatte, dieses doofe Kabel in die Buchse zu stecken, viel mir auf, dass irgendwie der Treiber für die Kamera nicht im Kernel ist. Nun, das ist bei einer abgespecken Kernel auch zu erwarten. Ich hab mir gedacht, es ist Mitternacht, ich habe keine Lust auf Bastelleien, bootest doch mal schnell in Windows und ziehst das Video rüber.

Mit dem Moviemaker kann man ja Videos von einer Kamera überspielen. Aber da ich keine Lus auf dieses WMV Format hatte, speicherte ich alle im RAW Format ab. Platz ist auf der ext. Festplatte ja genug. Leider überspielt er das Video in Realzeit. Das heisst eine Stunde Film, eine Stunde Überspielzeit.

Als die ersten zwei GB überspielt waren, viel mir ein, dass FAT32 ja doch irgendwie eine Dategrößenbeschränkung hat. (Warum nehm ich nicht NTFS? Weils stinkt. Basta!). Und beim vierten GB brach er auch ab. Ok halb so wild. Speichere ich es eben komprimiert ab. Nach weitern 15min war auf einmal der Akku leer. DANACH hab ich auch herausgefunden, dass man die Kamera an das Ladegerät anschliessen kann, so dass sie auch gleichzeitig im Betrieb ist.

Der dritte Versuch gestartet. Und mir war soooo langweilig. Da zockt man doch gerne mal ein kleines Spielchen. Spiel gestartet, bam Fehler. Die Aufnahme brach ab, weil die Bildschirmauflösung geändert wurde. Ich habe zwar keine Ahung was Firewire mit der Auflösung zu tun hat, aber bitte.

Der vierte Versuch. Nach einer elend langen Stunde war das Video endlich auf der Platte. Im Movie Maker sah die Vorschau des Bildes gut aus, spielte ich es aber im Mediaplayer ab, stimmen die Farben nicht mehr. Autsch ich geh pennen.

Am nächsten Morgen das Video nochmal irgendwie mit einem anderen Format codiert und sieht da, nach 40min geht es auch endlich. Mal ehrlich, ich wäre lieber meinen Linux treu geblieben und hätte die Zeit investiert den Treiber zu installieren. Dann hätte ich das komplette Video einmal im RAW Format rüber gezogen. Hätte keine Probleme mit Dateigrößenbeschränkungen gehabt, hatte keinen leeren Akku gehabt. Auch das ändern der Auflösung hätte keinen Fehler verursacht. Ich hätte kein beschränktes Windows Media Format gehabt und auch keine falschen Farben im Film.

Hätte, hätte, hätte...