Photos
When uploading photos to my llgal gallery, I resize and sharpen them so they don’t take up quite as much storage and bandwidth. I start by using the EXIF auto-rotation flag to losslessly rotate any upright photos:
jhead -autorot IMG_*.JPGNext, I rename the photos so there are no filename collisions when I throw together photos from different events:
exiftool '-FileName<EVENT_ ${CreateDate}_$filename' -d %Y%m%d IM*.JPG
Finally, if I want to upload the batch, I resize and sharpen the photos using the excellent imagemagick tools. Careful! mogrify will modify images in-place, so be sure to apply it on a copy of your original JPGs:
mogrify -resize "1024x1024>" -unsharp 1x1+1+0 -sampling-factor 2x2 *.JPGAfter that the folder with the photos is a simple scp and llgal call away from making it into my gallery.

Videos
I’ve just recently started shooting video, but I already love the functionality on my EOS 60D. Even though I use the Magic Lantern firmware (you absolutely should too!) to reduce the bitrate of the videos by half, the 1080p25 videos from the EOS are still way too large to be used in any reasonable way, so it’s a good idea to compress them. I start by merging all the videos of an event into one file, using the mkvtools package:
mkvmerge MVI_0001.MOV + MVI_0002.MOV -o MVI_EVENT.MOV
Next, I use ffmpeg to downscale and recompress the video and audio. Depending on your distribution, you might need to install extra packages from special repositories to do this:
ffmpeg -i MVI_EVENT.MOV -s 854x480 -b 2048k -vcodec libx264 -acodec libfaac -ac 2 -ar 48000 -ab 128k MVI_EVENT.mp4
This will give you a nice small file with very good quality, even if it takes a while to render. The adjusting knob is the bitrate behind the -b parameter. Be careful not to change the framerate of the original video using -r, this will degrade quality and take forever because frames will have to be interpolated!

The ffmpeg-call could certainly be optimized, and I’m happy to hear about any suggestions.

Mit dem Xperia Active habe ich jetzt ein Smartphone welches diese Anforderungen erfüllt. Ich kann das Handy bei Schnee und Regen am Rucksack aussen befestigt lassen, GPS bei Wanderungen und Radtouren mitloggen lassen und selbst mit nassen Fingern im Regen Schnappschüsse machen die ich, da es ein Smartphone ist, direkt auf den Internetdienst meiner Wahl übertragen kann. Falls ich mich tatsächlich verlaufe ist auch das Xperia Active nicht zu klein oder zu langsam und kann mit Google Maps und dem Kompass aushelfen. Die sehr sehr praktische Öse kann ich benutzen um das Handy garantiert bombenfest am Rucksack baumelnd zu befestigen, ein sehr wichtiges Feature. Die helle LED hilft Nachts. Beim Radfahren kann ich das mitgelieferte Sportarmband benutzen, falls ich sonst keine Taschen am Rad/Körper hab. Soweit zu meinem Nutzen für ein so ein rugged Smartphone.

Während der Arbeit liegt das Handy nur rum, und im Standby mit GPRS aktiviert (und GPS/WLAN deaktiviert) und Sync an (Google+, Twitter, GMail) hält es locker 48h, wenn nicht sogar länger. Gespräche kommen sauber und zuverlässig rüber, Bedienung ist wie bei Android gewohnt, die Kamera absolut OK. Als jemand der viel mit einer DSLR fotografiert weiss ich es zu schätzen dass man Weissabgleich, Metering Mode und Fokus unabhänging voneinander in mehreren Programmen einstellen kann. Besonders der feste unendlich-Fokus bedeutet dass ich in 90% aller Situationen perfekt fokussierte Fotos mit null Verzögerung machen kann. Das Rauschverhalten bei ISO 1600 ist natürlich nicht mehr schön, dafür geht das Xperia bei gutem Wetter gern auf ISO 64 und Verschlusszeiten von bis zu 1/1250s runter. Brennweite ist fest bei 3.5mm und Blende bei f2.6.

Negativpunkte
Eigentlich kann ich nur die Software von SE etwas kritisieren. Ein praktisches Migrations-App wie bei HTC fehlt leider, Kontakte muss man also per Bluetooth syncen und die alten SMS hab ich letzendlich gelöscht. Auch die HTC Sense UI gefällt mir etwas besser. Falls bei eurem Xperia Active die Handgelenksschlaufe fehlt ruft einfach beim SE-Support an, ist wohl bei ein paar wenigen der ersten Handies ausversehen vergessen worden. Ansonsten sollte man noch eine Rutsche Micro-USB Kabel mitbestellen, ich hatte ausser dem mitgelieferten keins, eine etwas größere Speicherkarte kann auch nicht schaden.

Sample Photos

Sony Ericsson Xperia Active Flickr Group here.

(Sorry, German review this time, use Chrome translate ;)

400plus – Firmware Hack for the Canon EOS 400D
The 400plus project is currently implementing a lot of additional features for the EOS 400D and distributing builds of hacked firmware which can be applied to the camera through a file which is loaded during camera startup, meaning they are easily reversible by simply deleting the firmware from the CF card. Recently, some really killer features where implemented, which even make some hardware additions redundant. This is an incomplete list, representing the most important features for me:

• Intervalometer: The 400D can be used to shoot at regular intervals by itself, without any additional controlling hardware. This is perhaps the coolest feature, and I’ve yet to put it to good use by creating a time-lapse movie.
• Intermediate ISO / Auto-ISO: Found in newer cameras, the 400D now supports intermediate ISO steps (seamlessly between ISO 100 and ISO 3200) as well as providing a basic Auto-ISO function with upper and lower limit. The ISO can also be adjusted while looking through the viewfinder.
• Handwave support: This is a mode where the camera takes a shot each time the proximity sensor above the display is triggered. Useful for macro shots where you don’t want to rock the camera rig.
• Timer: The camera simply fires after a certain amount of seconds has elapsed. It can also start the interval program instead.
• Manual Kelvin: Useful if you don’t want to shoot RAW to get spot-on white balance.
• Spot Metering: Metering light at a very small spot in the center.
• AF patterns: Found in more recent camera, AF patterns are a cool addition. External flash AF assist doesn’t work with it though.

For me, the Intervalometer/Timer/Handwave functions replace using an IR remote for self-portraits or macro shots. The Intervalometer replaces rather expensive external hardware triggers. The current version of the 400plus firmware seems very polished, providing simple menus and settings for its features, without any adverse side-effects. I expect more cool features to follow in the near future.

Tethered shooting using the command line
There are a number of solutions for tethered shooting with Canon DSLRs. Some of them even work on Linux. I wanted something simple to take and download shots from my 400D, so I used gphoto2. gphoto2 provides a lot of other features which I won’t cover here, and supports remote control for a wealth of cameras, so go check the compatibility of your own camera.

I wanted to use my EOS 400D as some sort of webcam, taking shots at intervals and directly transfering those shots to my PC. This is easy enough with gphoto:
gphoto2 --port=usb:005,048 --capture-image-and-download -I 30 --force-overwrite --filename=webcam.jpg --capture-previewThis takes a photo every 30 seconds and writes it to webcam.jpg. The port can be inferred by hooking up your camera and having a look at the output of lsusb. One small problem I encountered with my 2.6.39 kernel: The 400D did not work with ehci_hcd, so I had to disable it. If its modular, you can simply do modprobe -r ehci_hcd, but if, like me, its builtin, you can disable it by following this guide.

Thesis: Implementation and Evaluation of Efficient Cryptographic Algorithms using CUDA and OpenCL
The (rather lengthy) topic of my thesis contains this: Cryptography on GPUs. GPUs have become much more powerful than CPUs in terms of FLOPs/s (floating point operations per second), but using these computational resources requires a new programming model and a problem which can in fact be translated to run on a GPU. I simply transformed a few block ciphers (symmetric encryption systems) to run on the GPU, and analyzed common design paradigms and problems along the way. This has been done before by other teams, but what sets my work apart (in my opinion) is the fact that I analyzed multiple ciphers in one work, used two different systems to test my implementations and provided a detailed description of the test setup, something missing from most of the previous work.

Additionally, I think my thesis makes a comfortable read for anyone interested in GPU programming and cryptography on GPUs. You don’t need a lot of previous knowledge to understand it, and most of the previous work in GPU cryptography (not just for block ciphers) has been cited in the first chapter.

Thesis: Implementation
To implement the ciphers examined in my thesis, I needed some kind of foundation. First of all, encryption and decryption has to be invoked in some standard way, and different kinds of benchmarks have to be supported as well. After some search, I settled with using engine-cuda, an engine for the OpenSSL crypto library which uses CUDA to execute the block ciphers. To implement the block ciphers, I used the versions included with OpenSSL to start. Implementing a block cipher using just the original paper which describes it is a really bad idea unless you have extensive experience. I’ve seen other teams implement text-book versions of AES and fail miserably in the process.

My changes to engine-cuda will be released at some point in the near future, right now I am still working on it. Rest assured, when it is released you will hear about it here ;)

Thesis: Acknowledgments
My thesis was written at the Chair for IT Security at RWTH Aachen University, which is a young and really small chair. As a result, the communication with my supervisor and the professor was excellent, and I’d like to thank them both for supporting my topic. While cryptography certainly fits well into a chair for security, GPU-programming is a topic more often attributed to HPC research groups. As usual, Flo proved to be really helpful pointing out spelling mistakes and other errors in my thesis. Last but not least, Paolo Margara, author and maintainer of the engine-cuda project helped me get started with the code and discussed implementation decisions with me during development.

If you have questions or suggestions about the content of my work, feel free to contact me!

Accessoires
In January I decided to get myself an external flash, a Canon EX 430 II. I didn’t regret this decision a single day since then. No matter how fast your ISO and how wide your aperture, at some point you will most certainly need a flash. If used correctly, flash images look more natural to the casual observer, the fact that a flash was used only becomes apparent after studying the image more closely. Off-camera flash is even more fun, which is why I quickly got myself simple and cheap Tetra Phottix remote triggers.The next logical and easy step was to play around with so-called “gels” (color filter for artificial lights), which can shift the 5500K light emitted by the flash to different temperatures. The gel I most commonly use is the Roscosun 1/2 CTO (color-to-orange) which shifts 5500K to 3800K, close to most of the artificial light sources you discover. I only used gels exclusively in the latter half of 2010 and the photos turned out much more balanced than before. A key aspect is to allow enough ambient light, otherwise I won’t matter how you shift your flash since it will be the only visible light source. The ‘Av’ or ‘Tv’ (or even ‘M’) modes can be used for that, while ‘P’ will most certainly overpower any background lighting.Once you get started with off-camera flash photography there is a whole new world of additional gadgets to be bought and tricks to be learned, just have a look at the Strobist website. Needless to say, driving a single flash can get old really fast. A second flash was the logical next step. Since I knew I was only going to use this second flash in setup situations and off-camera (without a TTL-capable remote triggering system), I went for one of the cheapest and yet most reliable solutions and bought a Yongnuo YN-460 II. This flash only does manual (even on-camera), but it can trigger by itself on flash and even TTL-flash, without the need for any additional trigger mechanism. So I can use this with my EX 430 on-camera, with the EX 430 off-camera (using the Tetra trigger), and even with my builtin flash. I’m happy with the build quality and reliability of the Yongnuo and can only recommend it to any aspiring strobist on a budget.
I got myself a pol filter for my 18-200mm but have yet to really use it :(.Lens-wise my repertoire grew by another prime lens: The Sigma EX 30mm 1.4. This lens combined the huge aperture of my 50mm with the standard focal width corresponding to 50mm (1.6 * 30mm = 48mm) on full-frame sensors. So far this lens has not let me down quality-wise. The focus works fast, quiet and reliably, the color reproduction is great and the build quality of this lens is solid. Sharpness (even at f1.4) lags in no way behind my 50mm 1.4. I have shot four events exclusively with this lens and was never restricted by the focal length. The typical shot of a couple across the table now becomes natural, while my 50mm always gave me the feeling of having to single out people in order to shot them. Another nice thing about Sigma lenses is that the lens hood is included for all of their lenses. Obviously this lens can’t be used on full-frame, but given the current lineup of crop SLRs, I don’t feel the need to go there anytime soon.
Finally I took a leap of faith and used an alternative “hacked” firmware on my EOS 400D which unlocks some nice features. For me, the most important features were intermediate ISO steps and manual white balance. While the EOS 400D only presents ISO 100-200-400-800-1600, the hacked firmware allows steps in between, like 400-500-640 etc. While quality at 400 is still OK, it can be a little coarse at 800, so going to 500 and 640 first is a nice option. Manual whitebalance means being able to set the temperature, and not use the WB-shift feature or the white-balance on exisiting photo. This feature has taught me a lot about judging lighting conditions and choosing the right gel for my flash. On a side note, I discovered two EXIF tags I had not noticed before: Remaining flash voltage and camera temperature (only Canon).

What’s next
In the never-ending circle of DSLR-upgrades, the next thing for me will most certainly be a new camera body. While I don’t use the maximal resolution, never photograph in RAW and don’t miss movies this much, the ISO speed of the EOS 400D is a serious limitation. I never shoot at 1600 (except for grainy BW photos), while friends of mine use their 550D on 1600 or 3200 in most indoor situations. Since all the new models possess basically the same superior chip, I might go for the 550D, the 60D or the 7D, depending on how much I use my old 400D in the time until then. A nice distraction before the new body will probably an umbrella and lightstand for one of my flashes.

As usual, complete galleries of my shots can be found on http://photos.heipei.net, while flickr only has a few selected shots.

Have a great 2011 ;)

For some reason I delved into the topic again about a month ago. I realized that my tiny and cheap Acer Aspire One 110L, with its Atheros NIC (AR242x, 802.11abg) does in fact possess the ability to inject packets. Out of curiosity I had to try it for myself. This is not meant as a tutorial for cracking WEP (there is a comprehensive guide for aircrack), but rather as an encouragement to try it yourself, or at least to think very hard if you’re still using WEP.

The most shocking thing I discovered was that the number of necessary packets to crack WEP had dramatically decreased with new attack methods. The aircrack-team talks about 20k / 40k packets (with the new PTW attack, origin and paper here) for cracking 64bit/128bit WEP, which is well below the 1000k packets I read about in the past. At a rate of 500 packets/s this amounts to less than 5 minutes of time needed. This is still a lot if you have to depend on legitimate network traffic and don’t have a few days of time. To speed things up, packet re-injection is the way to go today. It works like this: You wait and try to record an ARP-request (which should be no problem if someone is on the network), and then replay this request back to the network, meaning you simply re-inject the same packet you captured. For every ARP-request, the AP/router should respond with an ARP-reply, which in turn is a new data packet and the kind of packet you want to capture in order to get to 20k/40k unique IVs (initialization vectors). Now imagine doing this re-injection at a rate of 500 packets/s and you get the point.

A few caveats:

• If nobody’s on the network you won’t be able to capture an ARP-request. Tough luck ;)
• If someone is on the network but you missed their initial ARP you can try disassociating them
• I wasn’t able to do fake auth with the AP, which is why I had to replay the ARPs as long as the original client was still associated
• If you wan’t to make extra sure you capture all the interesting replies you can keep Kismac running along airodump-ng
• I suppose this is illegal in Germany. Oh well, I did it while on vacation ;)

The nice thing about this attack:

• Really fast (think ‘car’ and ‘battery slowly discharging’)
• Not much storage needed to capture packets
• Cracking efficiently possible, even on a laptop
• If used for malicious purposes, the kind of people still using WEP will be the last to notice a few thousands extra 802.11 packets over a 5-minute span

• I didn’t choose the Geode GL/GX last time, doh!
• The kernel is no longer tickless (performs better)
• Threw out some modular crypto-stuff (which I missed the last time)

There are three front-LEDs on the ALIX board, so nothing fancy. The interesting is that there are predefined triggers for these LEDs in /sys/class/leds/ which will make the LEDs display one of the following: heartbeat = load average (blinking speed), ide-disk (write access to the cf-card), timer, etc. Just try cat trigger to see the possible values. There is also the possibility to trigger on matches from iptables (think: traffic on port 22 ;). However my iptables userland seems to be outdated, so I will have to report about this another time.

Furthermore I tried using lighttpd instead of gatling on my fat external drive, and it performed even better, using slightly less CPU. In the kernel I activated the deadline IO-scheduler as default (while keeping CFQ and NOOP as an option), let’s see how that plays out. I’m still not getting more than 9MB/s using Samba, while the CPU is mostly idle and lighty completely saturates the 100MBit link, really annoying.

lm_sensors on the ALIX are no problem either. Just try my kernel-config or make sure to activate the basic I2C-stuff and CONFIG_SCx200_ACB. My ALIX runs at comfy 42°C when not under load.

I already talked about using tmpfs for some of the directories written to frequently (/tmp, /var/tmp, /var/run, /var/log, /var/lock). I don’t care about logs right now, so I don’t mind losing them on reboot. Some daemons however complain or won’t start if their log-directories aren’t set up, so you should do that with an init-script. I uploaded my script here, which will work with Debian and also sets up two LEDs and the deadline scheduler in case it isn’t the default.

Specs
PCEngines has an overview over the ALIX-line as well as the specs of the ALIX 2D13, so this is just a short rundown:

• 500 MHz AMD Geode LX800 (x86)
• 256 MB DDR DRAM
• 3 Ethernet NICs (Via VT6105M 10/100)
• Furthermore: 2x USB ports, MiniPCI-slot, CF-slot, serial port

I chose the 2D13 model since I wanted 3 ethernet NICs and the added battery (for keeping system time after a reboot) seemed like a good idea. The ALIX boards can be bought in many variations, some even providing VGA/sound to be used as a thin client. I ordered my ALIX at the Varia-Store, where they offer a complete bundle of ALIX-2D13-board, enclosure, power supply and CF-card for a mere €145 including shipping in Germany. I ordered on Tuesday at noon and the package arrived Thursday afternoon.

Operating system / prerequisites
You probably want to run Linux on these babies, otherwise you can stop reading ahead. There are some things you really need before you get started:

• CF-card reader on your computer (for installing the OS to the CF-card)
• Serial connection (think USB-to-Serial converter, pl2303) to access the ALIX

I chose to install Debian on the ALIX, since I’m familiar with it and it has little overhead. I found these guides to be helpful, even if not completely up to date or correct: Guide 1, Guide 2. But careful! Don’t mount the ALIX board in its enclosure until you’re sure that your ALIX boots, since removing the CF-card requires taking the board out again ;).
The next thing I did was to build a custom kernel, since Debian only includes 2.6.26 and has everything you’ll never need compiled as modules. I built a next-to-minimal kernel on my workstation (this site helped a lot) and it seems to work just fine so far. The config is here. An important thing if you compile somewhere else is to make sure you useARCH=i386 make menuconfig
ARCH=i386 make -j3 when configuring and compiling your kernel for the ALIX.
People already using CF-cards or small embedded devices probably know to use noatime where possible and mount /tmp, /var/tmp, /var/run, /var/log, /var/lock as tmpfs to go easy on the CF-cards limited write cycles.

Performance / Applications
I bought the ALIX to play around with it but also to evaluate its possible use as a Samba-fileserver and CUPS printserver for my flat, and maybe even a small shellserver in case I’m away from home and my workstation isn’t running. With an energy-consumption of about 5-6W you can have it running 24/7, the fact that it doesn’t have any moving parts only adds to that. Booting takes a few seconds by the way, not that it matters.

The first measurements I did were with scp from the ALIX to my WS, which maxed out at 3.5MB/s because OpenSSH used up the CPU on the ALIX. Next I tried using Samba (to and from) and got a mere 6.5MB/s throughput reading from the ALIX and an attached USB-drive. This was with the stock kernel however, and using my own 2.6.34-kernel I was able to transmit more than 9MB/s using Samba. I had a stupid line in my smb.conf which might explain the 6.5MB/s I got before. Make sure to remove this line!:socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384I then did another test using fefes gatling web/ftp/samba-server on the ALIX and my USB-drive in HTTP-mode with wget and was able to completely saturate the 100MBit-link, which is why I suspect to be able to do the same thing with Samba as well.
For customers of Aachens Uni-DSL it should be interesting to know that I managed to max out my 8Mbit-DSL-line (about 700kB/s) using vpnc on the ALIX with enough idle CPU left. Using vpnc and doing a git pull on the ALIX resulted in only a slight slowdown since git was busy saving/packing objects it received. Performance using git daemon on the ALIX and pulling from there were acceptable as well.

All of these measurements are highly unscientific and side-effects or misconfigurations could have had negative effects, so one should read these rates as minimal assurances.

Conclusion
After the first full day of using the ALIX I’m impressed. The CPU is powerful enough for most tasks and with a little custom configuration some things can be sped up considerably. I don’t see any problems for the intended use as a file-server, by whichever way the files are served. The next step will be hooking up my printer.

If you intend to use encrypted filesystems on the ALIX you should do some research first. While the AMD Geode does have hardware support for AES, OpenSSL does not seem to use it and I’m not quite sure about any cryptofs. Another common thing the ALIX might be used for is wireless LAN. The MiniPCI-slot can take a variety of wireless NICs, but I don’t need yet another AP at the moment.

Photography
You accidentally selected “Delete All” on your digital cameras and now your photos are gone? You even fear they might have been overwritten by photos taken after the accident? Fear not, the same thing happened to me, and I was able to restore all the photos from the event plus photos going back as far as three months from my CF card in my 400d using the PhotoRec software.

Cameras today often have an orientation sensor, so pictures taken in portrait mode will automatically be rotated. But this usually happens in the viewer, while the orientation is simply an EXIF tag. Of course this takes up precious computing time and not every viewer supports it. jhead can not only display EXIF information in a consistent manner but can also rotate pictures lossless and clear the orientation-tag afterwards. The call is jhead -autorot *.JPG
If you want to rename your images using EXIF-information, exiftool is the way to go. The command exiftool '-FileName<Party_ ${CreateDate}_${filename}' -d %Y%m%d *.jpg would prefix all the photos with “Party” and the create-date, while keeping the original filename as the suffix. exiftool can shift dates too, if you ever forget to adjust for daylight saving.

When uploading the images you’ll often want to resize them. The ImageMagick collection can do just that, and many other things (like sharpening etc.). If you mogrify -resize 1600x1600 your photos will be resized to 1600px maximum edge length, while keeping the ratio. But be careful, mogrify overwrites the pictures in place!

Music
Thanks to services like video2mp3.net/ you can download a lot of music from YouTube. But sometimes there is silence at the end or the beginning of a song, and a whole collection of songs might have differing levels of volume. To cut an mp3 you can use mp3splt like this to cut everything after 03:30 minutes:mp3splt file.mp3 00.00 03.30The sound levels can be normalized, losslessly, using mp3gain:mp3gain -rk *

Misc
When pretty-printing flat text files I use a2ps to format them nicely and get a PostScript-document. a2ps however does not support UTF-8, while the only characters I care about (German Umlauts) can be represented using Latin1 just fine. So, one can use iconv to convert them on the fly like this:iconv --from-code=UTF-8 --to-code=LATIN1 textfile.txt|a2ps --font 9 -E -B -r --column=1 > out.ps

To export images from a PDF-file I discovered pdfImages, which is part of the xpdf-suite. Use it like this:pdfimages -j foo.pdf bar

Reusing a connection
Anyway, today I wanted to present another advanced feature, one I only stumbled upon while learning for an upcoming exam. The slides mentioned the possibility to share connections on one SSH-channel (to the same destination, obviously). Now, why do you need more than one connection in the first place? Well, sometimes you just need the space, and using screen just doesn’t cut it. Or you use git or scp to the same host you’re logged in already interactively. In that case, you just have to establish one connection and any further connection will use the first one. The benefit? Login is way faster, almost instantly, because the whole handshake and authentication doesn’t have to take place again. The caveat: You’ll have to close your master-connection last, otherwise the other connections will drop too. For me that’s no problem, since the host I use most of the time is also the host I’ve got a session open with 24/7 (IRC).

I’m just gonna show the fully automated version here, though you can use it manually as well, just when you need it. A better description can be found here. To automate it, put this in your ~/.ssh/config (you don’t have a config yet? shocking!):
ControlMaster auto
ControlPath /tmp/%r@%h:%pAs usual, you can put it at the very top to apply for all hosts or you can activate it for specific hosts by putting below a Host declaration. Now all you have to do is use ssh host as usual. You’ll see it’s working when you terminate the connection:
Shared connection to host.de closed.

Reverse tunnel
Yes, you can tunnel with OpenSSH. You can even have it act as a SOCKS proxy, which is really neat when combined with Firefox-plugins like FoxyProxy. But you can also reverse-tunnel your way out of a closed network (or NATed network for that matter) when you don’t have access to any intermediate host (like the router/firewall). It’s easy:
ssh -NR 12345:localhost:22 home.deThis assumes you’re issuing the command from the machine that you want to access (from home) later on. It will bind the port 12345 on home.de so that it is forwarded to port 22 (SSH) on the local host. Yeah, it requires some reverse thinking too to get it right ;) The -N-switch prevents a login, by the way. Obviously it is of little use if your home.de has a flaky dialup connection, so you might want to reverse-tunnel to a stable endpoint (or use something like autossh).