CoderDojo Köln vom 23.04.2016

Zum dritten Mal war ich am 23.04. als Mentor dabei beim CoderDojo in Köln. Es war wieder einmal eine wunderbare Erfahrung, und eine Freude zusammen mit den anderen Coaches den Kiddies beim Coden und Experimentieren mit Rat und Tat zur Seite zu stehen.

Aber fangen wir von vorne an, was ist das CoderDojo? Beim CoderDojo haben Kinder und Jugendliche zwischen 7 und 17 die Möglichkeit sich in der Welt der Computertechnik auszuprobieren und programmieren zu lernen. Mentoren helfen ihnen auf ehrenamtlicher Basis bei der Umsetzung ihrer Projekte. Das Schöne ist, dass hier der Kreativität keine Grenzen gesetzt sind 🙂 Ob die Kinder jetzt ihr erstes Spiel programmieren wollen, eine Homepage über ihr Hobby bauen, oder eine erste Smartphone App… Tja, es geht alles was man sich ausdenken kann 🙂
Natürlich haben wir auch ein paar Denkanstöße parat, denn oft erkennen wir zwar eine Begeisterung für Technik bei unseren Padawans, aber bei so vielen Möglichkeiten kann man schon mal wie der Ochs vorm Berg stehen. Kein Problem, Vorschläge haben wir auch reichlich.

Beim Dojo am 23.04. gab es zum Beispiel die Möglichkeit sich mit Elektronik auseinanderzusetzen. Im speziellen Fall mit Mikrokontroller. Also Kleinstrechnern die nur aus einem Chip bestehen, und direkt programmiert werden können. Das Arduino Projekt hat hier wunderbare Vorabeit geleistet und bietet eine Entwicklungsumgebung mit der man sehr einfach erste Erfolge feiern kann. Als Beispiel gibt es hier zwei kleine Videos der Elektronikprojekte, die wir am 23.04. realisiert haben:

Hell & Dunkel

Die Ampel

An dieser Stelle möchte ich mich bei Lucas bedanken, der das CoderDojo in Köln mit Begeisterung und Herzblut organisiert und leitet. Da ist mittlerweile echt eine tolle Sache bei rausgekommen!!

Über das Thema könnte ich vermutlich noch ein wenig länger schreiben, aber vieles lässt sich ja auch noch in den Kommentaren klären 😉

Neues Haustier


Sagt „Hallo!“ zu unserem neuen Haustier Miss Mauerbiene 🙂

Nachtrag: Habe mir gerade erklären lassen, dass das ja eigentlich ganz nette Tiere sind. Mauerbienen leben nicht im Volk, sondern alleine. Sie bauen Wabengruppen aus ca. 6 Waben wo sie ihre Larfen reinlegen, die nach ein paar Tagen schlüpfen und sich vom hinterlegten Blütenstab ernähren. Bis daraus allerdings neue Bienen werden dauert es mehrere Monate. Da die Mauerbiene auch kein Interesse an Süßigkeiten, und den bei uns häufig anzutreffenden Grillerzeugnissen hat, bleibt sie erstmal unser Haus- bzw. Terrassentier 😉

Ende eines schönen Tages, und ein kleiner Test


Ich glaube dieses lange Wochenende hat nun endgültig die Grillsaison für dieses Jahr eröffnet. Man kann sogar jetzt noch im T-Shirt draussen sitzen 🙂
Außerdem wollte ich gerade mal die WordPress für iOS App testen, und damit einen Beitrag schreiben. Das Handling gefällt mir soweit gut, auch die Einbindung der Kamera. Leider wird mir ein Eintrag den ich auf dem Computer angefangen habe zu schreiben hier nicht zum Fortsetzen angezeigt. Da werde ich noch nachforschen müssen 🙂

Nachtrag 1: Jetzt drücke ich gerade auf den „veröffentlichen“ Button, und merke, dass der Bildupload nicht funktioniert. Der Balken geht bis zum Ende durch, der Upload wird aber nicht abgeschlossen… Liegt bestimmt daran, dass meine Seite selbst gehostet ist, und die App nur mit dem WordPress eigenen Hosting gescheit klarkommt… Noch ein Punkt den es zu untersuchen gilt 😉

Nachtrag 2: Auch ohne Bild kann ich den Beitrag nicht über die iOS App veröffentlich. Es gibt einen HTTP Fehler 🙁 Logins sind aber alle korrekt eingegeben… Sieht erstmal danach aus als sei die WordPress App unbrauchbar, und die schlechten Bewertungen gerechtfertigt :/

Nachtrag 3: Nachdem ich jetzt meinen Blog aus der App entfernt und wieder hinzugefügt habe, werden mir zumindest meine bisherigen Einträge angezeigt. Der Bildupload schlägt allerdings noch immer mit einem 503er „Service Unavailable“ fehl…

Nachtrag 4: Hier auf dem iPad funktioniert sogar der Bildupload, whoaha ^^

Hacking a RC car

Hi folks,

I guess it’s been a while since I posted something here, so I’m glad there is still someone looking here 🙂

Today I started a project in which I want to equip a RC car with my raspberry pi and a raspy camera. So far I figured how to hook into the internal PCB of the car such that I can gain external control over accelerating and steering the car.

For complete details visit the project pages on GitHub: https://github.com/smashnet/maisto-rock-crawler-raspy-hacking

Hope you find this interesting 🙂

Cheers,
Nico

IM+ Messenger – A jabber privacy report

Good morrow worthy reader,

maybe you’ve been up to investigating the privacy of your communication channels lately. So was I, and the first thing to look at was the comfortable Messenger App IM+ for iOS.

IM+ lets you use several kinds of messenger protocols on your smartphone and tablet. Where the most important one for me is definitely XMPP (Jabber). IM+ is easy to use and even provides functionality to stay „online“ while the app is not opened. This is especially practical for people like me who thought something like „Oh cool, a way to focus my smartphone communication to Jabber. No more iMessages routed over Apples servers, yay!“

I’m operating my own Jabber server which I connect to using IM+. You should think we reduced at least some of the privacy concerns but there is one part forgotten by many users. In order to receive messages while the app is closed, your iPhone receives the messages through Apples push service. Clicking on the push message will then open the app (IM+) again.

The question is: „How can I receive a message if IM+ is closed and I’m not logged into my Jabber account?“ Well, indeed you ARE logged into your Jabber account, but it’s not your smartphone that’s logged in, it’s some server operated by IM+. This server stands in between your Jabber server and your smartphone and routes all messages you write and receive. Finally, this also means your username and password of your Jabber account are transferred to IM+ middle server. Otherwise, this server couldn’t log into your Jabber account.

So, what’s the matter?

At first, your login information are stored at some random server you don’t know. As IM+ must be able to use your login information, they are saved either plain or encrypted, but accessible for IM+ in any way. So you might better use a password for that account you use nowhere else.

My second thought was that messages I write and receive should not be routed outside of my home country (Germany). So I checked which way a message would go between my Jabber server and the IM+ server. Using the tool iftop I figured that there are two IPs connecting to my Jabber server if I connect to my Jabber account using IM+.

184.107.43.156
184.107.43.153

Probably there are more possbile IPs than these two, but these are the ones I discovered. To find out the route a packet would go to this IP I ran a traceroute for each of the IPs with the following results:

traceroute to 184.107.43.156 (184.107.43.156), 30 hops max, 60 byte packets
 1  80-244-241-33.nbg.goekal-it.de (80.244.241.33)  3.925 ms  3.979 ms  3.961 ms
 2  209.83.rev.synaix.de (5.61.83.209)  2.013 ms  2.096 ms  2.137 ms
 3  89.1.26.241 (89.1.26.241)  2.160 ms  2.267 ms  2.343 ms
 4  core-sto1-po1.netcologne.de (87.79.16.53)  32.751 ms  32.740 ms  32.720 ms
 5  rtint4-t14.netcologne.de (81.173.192.2)  82.541 ms  82.635 ms  82.683 ms
 6  80.157.131.217 (80.157.131.217)  2.501 ms  2.516 ms  2.488 ms
 7  f-ed5-i.F.DE.NET.DTAG.DE (217.5.95.18)  6.118 ms  6.181 ms f-ed5-i.F.DE.NET.DTAG.DE (217.5.95.38)  6.440 ms
 8  80.157.130.78 (80.157.130.78)  16.945 ms  16.606 ms  14.038 ms
 9  if-3-2.tcore1.PVU-Paris.as6453.net (80.231.153.53)  96.995 ms  96.617 ms if-9-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.42)  96.914 ms
10  if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13)  92.572 ms if-12-2.tcore1.PYE-Paris.as6453.net (80.231.154.69)  95.711 ms if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13)  92.490 ms
11  if-3-6.tcore1.L78-London.as6453.net (80.231.130.85)  95.411 ms  95.779 ms if-13-2.tcore2.AV2-Amsterdam.as6453.net (80.231.152.22)  92.155 ms
12  if-1-2.tcore2.L78-London.as6453.net (80.231.130.122)  100.962 ms if-8-2.tcore2.L78-London.as6453.net (80.231.131.5)  94.190 ms if-2-2.tcore2.L78-London.as6453.net (80.231.131.1)  97.183 ms
13  if-20-2.tcore2.NYY-NewYork.as6453.net (216.6.99.13)  95.407 ms  92.088 ms  117.070 ms
14  if-2-2.tcore2.MTT-Montreal.as6453.net (64.86.226.13)  93.536 ms  91.723 ms  90.585 ms
15  if-0-2.tcore1.MTT-Montreal.as6453.net (216.6.115.89)  96.113 ms  100.088 ms  94.267 ms
16  64.86.31.42 (64.86.31.42)  92.818 ms  95.089 ms  94.756 ms
17  te8-3.dr2.mtl.iweb.com (67.205.127.234)  92.534 ms  96.588 ms  91.171 ms
18  184.107.43.156 (184.107.43.156)  94.161 ms  95.094 ms  96.093 ms

and

traceroute to 184.107.43.153 (184.107.43.153), 30 hops max, 60 byte packets
 1  80-244-241-33.nbg.goekal-it.de (80.244.241.33)  3.667 ms  3.715 ms  3.704 ms
 2  209.83.rev.synaix.de (5.61.83.209)  0.416 ms  0.523 ms  0.555 ms
 3  89.1.26.241 (89.1.26.241)  2.082 ms  2.173 ms  2.264 ms
 4  core-sto2-po2.netcologne.de (87.79.16.57)  1.908 ms  1.992 ms  2.034 ms
 5  rtint4-t61.netcologne.de (81.173.192.10)  2.068 ms  2.151 ms  2.233 ms
 6  80.157.131.217 (80.157.131.217)  2.458 ms  2.437 ms  2.534 ms
 7  f-ed5-i.F.DE.NET.DTAG.DE (217.5.95.58)  6.133 ms  6.081 ms f-ed5-i.F.DE.NET.DTAG.DE (217.5.95.22)  6.557 ms
 8  80.157.130.78 (80.157.130.78)  9.570 ms 62.157.249.234 (62.157.249.234)  8.573 ms  8.212 ms
 9  if-9-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.42)  96.855 ms if-5-2.tcore1.PVU-Paris.as6453.net (80.231.153.121)  97.844 ms if-7-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.2)  92.907 ms
10  if-6-3.tcore1.AV2-Amsterdam.as6453.net (195.219.194.77)  92.547 ms if-12-2.tcore1.PYE-Paris.as6453.net (80.231.154.69)  95.989 ms if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13)  92.573 ms
11  if-3-6.tcore1.L78-London.as6453.net (80.231.130.85)  95.384 ms if-2-2.tcore2.AV2-Amsterdam.as6453.net (195.219.194.6)  112.014 ms if-13-2.tcore2.AV2-Amsterdam.as6453.net (80.231.152.22)  107.096 ms
12  if-2-2.tcore2.L78-London.as6453.net (80.231.131.1)  97.267 ms  96.532 ms if-7-2.tcore2.L78-London.as6453.net (80.231.152.14)  93.665 ms
13  if-20-2.tcore2.NYY-NewYork.as6453.net (216.6.99.13)  95.217 ms  94.775 ms  97.143 ms
14  if-5-2.tcore2.MTT-Montreal.as6453.net (216.6.99.30)  97.240 ms if-2-2.tcore2.MTT-Montreal.as6453.net (64.86.226.13)  90.724 ms if-5-2.tcore2.MTT-Montreal.as6453.net (216.6.99.30)  92.596 ms
15  if-0-2.tcore1.MTT-Montreal.as6453.net (216.6.115.89)  99.712 ms  94.021 ms  98.951 ms
16  64.86.31.42 (64.86.31.42)  90.230 ms  93.883 ms  90.559 ms
17  te8-3.dr2.mtl.iweb.com (67.205.127.234)  95.352 ms  91.947 ms  91.094 ms
18  184.107.43.153 (184.107.43.153)  94.776 ms  90.730 ms  91.858 ms

Of course this is only a snapshot of how packets travel between my Jabber server and IM+‘ middle server. Reasoned by the design of IP this route might change. But what does this output tell us? At first, looking at the line

17  te8-3.dr2.mtl.iweb.com (67.205.127.234)  95.352 ms  91.947 ms  91.094 ms

we can guess from the „mtl“ and hops 14 and 15 that our responsible IM+ server is located in Montreal, Canada. Looking at the previous hops also tells us that packets from my Jabber server located in Aachen, Germany, to the IM+ server pass Cologne, Frankfurt, Amsterdam, London and New York until they finally arrive in Montreal. Pretty complicated, but ok, IP decides where packets go.

The essence of this experiment is that although I’m in Germany, my Jabber server is in Germany, and most of my contacts are in Germany, all messages I write and receive via IM+ are routed through half of the world to Montreal and back to Germany. This should get you thinking especially after Snowdens publications.

Maybe some of you (that have tried IM+ yet) have discovered that IM+ provides a paid Off-the-Record-Messaging (OTR) Plugin. I haven’t played for longer time with that plugin yet, but my first experience is rather intermingled (you say that, or is this Denglisch?). Establishing an OTR session while using the IM+ app works quite well, but as soon as the app vanishes in the background, and your next message will be received via push message, you will just receive

 <encrypted text>

and need to re-establish the OTR session inside IM+. The purpose of hiding messages from middle servers may be fulfilled but it’s very inconvenient to re-establish OTR and then to ask „What did you write again?“

We can conclude that IM+ is (in my opinion) not yet a feasible way for sensitive jabber communication. And as staying connected and using apple push notification requires the use of middle servers, convenient smartphone and tablet messenger probably won’t be feasible for such cases in the next time. In such cases you might have a look at „Monal“.

OK, if you’re still with me here’s a big „Hurray! Yay!“ and thanks for reading 😉

Nico

Project Swarm: A basic Minion circuit

Here’s a first draft of an electrical circuit for Minion devices. I’m happy about any comments ‚cause this is the first time I came in touch with EAGLE 🙂

Basic Minion EAGLE Circuit v0.1

If you are more interested in this project, follow our repository on GitHub:

https://github.com/swarmworx/swarm

Cheers,
Nico

Making a CP2102 USB UART Bridge compatible to FTDI Friend

Back from my vacation I started with a small „compatibility improvement“ for my cheap CP2102 based USB to UART Bridge. As many people use an FTDI Friend to flash their Arduino compatible devices (like Boarduino, etc.), all these devices share the same pinout wiring for the USB connection.

Unfortunately my cheap china device has a different pinout, so I started to „correct“ that 🙂

CP2102_connected

CP2102_nearHere is the wiring my CP2102 board came with:
Caution: RX of the USB UART Bridge is wired to RX of the microcontroller, and the same for TX

  • GND
  • RX (connect with RX of microcontroller)
  • TX (connect with TX of microcontroller)
  • 5V
  • 3,3V
  • RST

And this is what the FTDI Friend proposes:
Caution: Here it’s the other way ‚round, wire RX of the FTDI Friend with TX of the microcontroller

  • GND
  • CTS (connected with GND)
  • VCC
  • TX (connect with RX of microcontroller)
  • RX (connect with TX of microcontroller)
  • RTS (RTS – 100nF – uC-RESET-Pin (with 10k pull-up to VCC))

As my CP2102 USB UART bridge has no direct RTS pin, I needed to get the RTS signal from a pinout next to the chip (blue wire).

 

Project Swarm: A Short Introduction

Sensor networks are a fascinating way to peek into the worlds of microcontroller programming and algorithms for wireless communication. With Swarm we start a little experiment of creating our own Arduino compatible sensor nodes. Both hardware and software will be available open-source.

Here is already a picture of a breadboard hack where we tested the functionality of the RFM12 radio module:

Arduino RFM12

Swarm will cover the following devices:

  1. A Raspberry Pi shield containing a RFM12 radio module
  2. An Arduino Uno shield containing: RFM12 radio module, LEDs (Red, Yellow, Green), DS18B20 Temperature Sensor, Light Sensor, (we are still thinking what else we could put on it)
  3. An independent sensor node (Minion) with the functionalities of the Arduino shield (3x AA Battery driven, or USB)
  4. An independent node with RFM12 connectivity and output capabilities like LED matrices or a graphical LCD

The list may change during our experiments 😉 Your feedback is also highly appreciated!

The Raspberry should basically server as a central point where the data of the nodes is collected and presented on a web-interface. Thus, the RPi only needs a RFM12 module to receive the messages from the nodes.

We produce a shield for Arduino Uno with all sensor node capabilities in order to have a quickly available experimentation board. If the hardware functions as expected, we will create independent sensor nodes, we call them Minions, which consist of an AtMega328p chip, the mentioned sensors and a RFM12 module.

In some cases you may want to display data from the sensor network at a certain place. Therefor, we will also create an independent „output node“ without sensing capabilities, but with functionality to display received sensor network data.

This was a first peek at the hardware parts of our new experiment, the software side and many soldering and experimenting pictures will follow 🙂

Yeah, ok, I will put the first soldering picture directly here 😉

Soldering RFM12

Access your IPv6 homeserver from a IPv4 network

The process is quite slow, but with the time ISPs tend to give their customers IPv6 internet links. Which is of course great because of the new technology, but also brings some unexpected pitfalls. Many users want to access their homeserver or whatever device at home from a remote place, and unfortunately, most remote networks, be it a free WiFi hotspot or your company network, have no support for IPv6 yet. So your devices at home COULD be reachable via IPv6, but not from your remote spot which only supports IPv4.

In my special case I host a Minecraft server on my homeserver, and as most of my friends still have IPv4 internet links they cannot connect to my server anymore. In this article I’ll describe how I use OpenVPN, my vServer and some sophisticated iptables rules to „extend“ my Minecraft server listening on the IPv4 address of my vServer while still running on my homeserver. You can use the same method to e.g. ssh into your IPv6 homeserver via the IPv4 address of your vServer, you just need to use the correct port in the iptables section.

This tutorial has been tested on Debian GNU/Linux, but should work with most Linux distributions.

What you need:

  1. A vServer from your favourite provider (MUST have an IPv4 AND an IPv6 address, MUST support TUN interfaces)
  2. OpenVPN 2.3 (or newer) installed on your homeserver and the vServer (MUST be 2.3 or newer, because older versions have no support for IPv6 on tun devices)
  3. root access on both machines

Here we go:

  • Enable IP forwarding (only on vServer). With default settings linux would not forward IP packets from one network interface to the other, so we need to enable this function by adding/uncommenting the following line in your vServers /etc/sysctl.conf
    net.ipv4.ip_forward = 1

    To make the machine recognize the change, run:

    sysctl -p /etc/sysctl.conf
  • Create secret key and config file for OpenVPN. Both homeserver, and vServer need a OpenVPN config file that specifies the parameters for the VPN connection. Create the file /etc/openvpn/tun0.conf on both machines (needs root). Here are two minimal expamples:
    remote IPv6_ADDRESS_OF_YOUR_VSERVER 1194 udp6
    dev tun0
    ifconfig 10.9.8.2 10.9.8.1
    keepalive 10 120
    secret /etc/openvpn/static.key
    proto udp6
    dev tun0
    ifconfig 10.9.8.1 10.9.8.2
    keepalive 10 120
    secret /etc/openvpn/static.key

    The first one is for your homeserver, the second one for your vServerYou still have to fill in the correct IPv6 address of your vServer in the first config file! As you can see in the configs, you also need a secret key for your connection. You can create it with the following line:

    openvpn --genkey --secret static.key

    Then, copy the static.key to /etc/openvpn/ on both servers. Remember: You only need to generate the file once, and copy it over to the folder on your homeserver and the folder on the vServer, meaning: static.key must be the same (same hash) file on both machines. Now, first start OpenVPN on your vServer, and then on your homeserver. If everything worked it should show something like this

    Fri May 17 09:53:47 2013 Initialization Sequence Completed

    on both machines. However, it could take some seconds until the initialization sequence is completed.

  • Now you created a point-to-point VPN between your homeserver and your vServer. Your homeserver has the IP 10.9.8.2 and the vServer 10.9.8.1
  • Setup iptables to allow the needed connections (only on vServer). In this part I assume we start with an empty iptables, meaning that all connections are ALLOWED. It is up to you to protect your vServer, in this tutorial I will only show what entries are definitely needed to forward the Minecraft port 25565 from the vServers IPv4 address to your homeserver. Therefor, we need to tell iptables to forward incoming packets on port 25565 to the same port of your homeservers VPN IP address with the following line:
    iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 25565 -j DNAT --to-destination 10.9.8.2:25565

    In Words: „For all incoming TCP packets via eth0 on port 25565, set their destination to 10.9.8.2:25565“. At this point I assume, that your vServers IPv4 address is bound to the eth0 interface. Now, IP packets are forwarded from you vServers IPv4 address port 25565 to your homeservers VPN IP port 25565. Unfortunately, your homeserver does not know how to send packets directly back to the original sender (the Minecraft player who connected), but your vServer knows! Simple solution: Make your homeserver believe the packet came from the vServer. This process is called MASQUERADING, where the vServer replaces the source IP header information in each IP packet to his own IP address. This is done by the following line:

    iptables -t nat -A POSTROUTING -p tcp -o tun0 --dport 25565 -j MASQUERADE

    In words: „For all TCP packets passing through tun0 going to port 25565, replace in the IP packet header the source_IP with your own IP“, where tun0 is your VPNs network interface.

  • You’re done! 😀 It is possible that you need to restart your OpenVPN connection after you applied the iptables rules, but then you’re good to go 🙂

Here you can download an sample initialization file for iptables that only allows incoming connections for SSH (IPv4 and 6), Minecraft (only IPv4) and OpenVPN (only IPv6). You’re free to use and modify this to your own needs.

Download

Just remove the „txt“ ending, make it executable with

chmod +x iptables_init

and execute it.

Attention: This example assumes your SSH connection to work on port 22, if you use another port, this will lock you out from your vServer! Please change the port in the file beforehands!

Now, this was a lot of work! I hope you learned something, and had a little fun with this tutorial 🙂

If this was useful for you, I would greatly appreciate a small donation via Bitcoin 🙂

Address: 1NFysGRKm4CsPXFLVoGhMjEq6gTT2kE9a1

[ni]