VPN mit iPhone oder iPod Touch an der Freien Universität Berlin funktioniert

Die Profile für eduroam und VPN sind jetzt auf den entsprechenden Webseiten abrufbar:

http://www.zedat.fu-berlin.de/Eduroam-iPhone

http://www.zedat.fu-berlin.de/VPNclient-iPhone

iPhone und 802.1X (eduroam) an der FU Berlin (Tutorial)

UPDATE 02.08.2008: VPN geht auch, einfach ne Mail an die ZEDAT und ihr bekommt das entsprechende Profil an eure FU-Mail-Adresse gesandt.

UPDATE 09.09.2008: Eine Mail ist nicht mehr erforderlich. Die Profile für eduroam und VPN sind jetzt auf den entsprechenden Webseiten abrufbar: http://www.zedat.fu-berlin.de/Eduroam-iPhone und http://www.zedat.fu-berlin.de/VPNclient-iPhone


Zutaten:

• Deutsche-Telekom.cer
• FU-CA.cer
• Apple iPhone Configuration Utility

Hinweis: Diese Anleitung wurde mithilfe der von der FU ZEDAT bereitgestellten Parameter für 802.1X eduroam erstellt.

Für FUler auf dem ganzen FU-Campus und dank eduroam auch an der FHTW Berlin und an der TU sowie sämtlichen sonst teilnehmenden Universitäten (Liste scheint nicht besonders aktuell zu sein) gibts schnellen WLAN Zugang fürs iPhone und iPod Touch mit 2.0 Firmware.

Leider funktioniert die Einrichtung nicht direkt über das Gerät. Stattdessen ist der Umweg über das iPhone Configuration Utility (im folgenden ICU) zu nehmen (Download von Apple), welches eine Konfigurationsdatei erstellt, die man sich anschließend zumailen kann oder auf einen webserver stellen kann. Dann wird die Datei mit dem iPhone aufgerufen und der Rest erklärt sich von selbst.

Das iCU installiert auf Windows PCs einen lokalen Webserver, der unter http://localhost:3000 (oder eben http://127.0.0.1:3000) erreichbar ist.
Benutzername und Passwort lauten jeweils admin.

Ist man im iCU eingeloggt, ist das erforderliche Profil schnell erstellt. Wir beschränken uns zunächst auf 802.1X (eduroam).


1. General

Unter General füllt man zunächst die Felder aus, was man genau einträgt ist egal, wichtig ist jedoch, dass alle required-Felder ausgefüllt werden. Anschließend zwischenspeichern mit save.

2. Credentials
Unter credentials ladet ihr die Stammzertifikatsdatei der Deutschen Telekom hoch, die ihr bei der Zedat bekommt (Link auf Deutsche-Telekom.cer).
Ob es tatsächlich erforderlich ist, auch das FU-CA Zertifikat hochzuladen, weiß ich nicht, es schadet aber nicht. Dieses heißt FU-CA.cer und ist ebenfalls auf den Servern der ZEDAT erhältlich.

3. Wi-Fi

Anschließend wechselt Ihr zur Registerkarte "Wi-Fi".


Dort tragt ihr als SSID eduroam ein, stellt den Security Type auf WPA/WPA2 Enterprise

Bei Enterprise settings stellt ihr Protocols auf TTLS.

Dann wechselt ihr auf "Authentication".













Bei Authentication tragt Ihr bei Username euren Zedat-Namen gefolgt von @zedat.fu-berlin.de ein. Also zedatname@zedat.fu-berlin.de (siehe auch Bild). Inner Authentication sollte auf "PAP" eingestellt sein. Das war's schon für hier, als nächstes geht's zu Trust.

















Bei Trust setzt Ihr ein Häkchen vor das im Schritt 2 importierte Telekom Zertifikat:
"Deutsche Telekom Root CA 2".
Anschließend wird mit Save gespeichert.



4. Profil speichern

Zuletzt wechselt ihr wieder zurück zu "General" und speichert das ganze als Datei ab, indem ihr auf "Export Profile" klickt. Am einfachsten funktionierte bei mir der Profil-Import, indem ich es mir selbst als Anhang einer Mail zugeschickt und die Mail im iPhone abgerufen habe.

Das iPhone fragt dann noch euer Zedat Passwort ab. Ab sofort sollte es möglich sein, sich im WLAN "eduroam" einzuwählen.

Beachtet hierbei, dass ihr nicht zugleich mit dem VPN Client oder mit einem anderen PC per 802.1X eingewählt sein dürft. Zwar bucht sich das iPhone bei eduroam ein, ihr kommt aber nicht ins Netz.

Das wars!

iPhone, Voicemail und T-Mobile

Als T-Mobile Neukunde war ich zunächst gehörig verwirrt: Ohne mein Zutun verschwanden Voicemail-Nachrichten nach einiger Zeit. Hatte ich dies zunächst noch den nicht unüblichen Abstürzen des iPhone 3G zugeschrieben, bin ich heute klüger geworden.

Entgegen geschätzten Gepflogenheiten anderer Mobilfunkanbieter in Deutschland werden bei T-Mobile Nachrichten ungefragt gelöscht. Abgehörte Nachrichten bereits nach sieben Tagen, nicht abgehörte Nachrichten nach 21 Tagen. Wichtige Nummern, die auf die Voicebox gesprochen werden, sollten also schleunigst notiert werden.

iTunes erkennt nicht iPhone / iPod Touch remote

Seitdem es im Apple-Appstore das tolle Programm remote gibt, verzweifle ich daran. iTunes wollte partout nicht mein iPhone remote erkennen, ich konnte nicht einmal das Passwort eingeben.

Neben den üblichen Fehlerquellen (googlen. Z.B.: Routereinstellungen (Kommunikation erlauben)), habe ich mich dann mal mit Wireshark rangesetzt und nachgeschaut, ob denn überhaupt Pakete vom iPhone ankommen.

Bei mir war der Schuldige jedenfalls AVM. Ich habe vor einiger Zeit Fritz Fernzugang installiert, um per VPN von außerhalb auf mein Netzwerk zugreifen können. AVMs VPN-Lösung verbockt aber offenbar die Erkennung des iPhones übers (W)-LAN.

Rettung für alle Verzweifelten; dem Problem ist ganz schnell beizukommen:

Systemsteuerung --> Netzwerkverbindungen. Dort die Netzwerkkarte anwählen, über die die Netzwerkverbindung zum Router (Fritzbox) besteht, also im Zweifel "Drahtlose Netzwerkverbindung", wenn der iTunes-Rechner per WLAN im LAN hängt. Rechtsklick, dann auf Eigenschaften und dort in der Liste das Häkchen vor "AVM VPN Driver" entfernen. Dann auf OK und voilá, das war's. Bei mir tauchte im iTunes direkt nach dem OK-Klick das iPhone auf.



Ich fand die AVM VPN-Lösung ohnehin nicht so dolle. :)

rtorrent finally running stably on Debian NSLU2

I am currently downloading the actual ubuntu-distro with 1400 KB/s along with to other small test torrents to make sure it really works. And it does.

After all it can be said the solution to the crash issue was almost too simple:

Responsible for rtorrents crash behaviour was the oom-killer (cf. earlier posts) that is shipped with debian etch.
However, uprading to lenny solves this issue.

That can be done by simply typing:

apt-get update
apt-get dist-upgrade

Before Upgrading, make sure you have a backup at hand:

sudo cat /dev/mtdblock* > backup.img

...and store it to a safe location. With this precaution you can always switch back to a working system by putting the NSLU2 into upgrade mode and flashing the backup.img to it with upslug2.

The upgrade may take a considerable time.

Note that I crashed my Debian NSLU2 by doing this because the "new initramfs-tools in testing (version 0.92) generates a ramdisk that does not boot correctly on the NSLU2 - it makes your system unbootable (see bug #478236)."
As mentioned, the upgrade is currently not safe.

As I crashed my NSLU2 and had no backups but also no important data on it, I snapped at the chance and reinstalled my system with the debian 5.0 beta 1 (unoffical), see here.

If you have any questions, leave a comment!

UPDATE July 28: Upgrading via apt-get dist-upgrade should be safe now.

Almost weekly DS-Line quality report

No resyncs so far but a considerable number of "Forward Error Corrections". Regarding the speed I got no faster downloads than 1,3 Mbit/s, but I hadn't it tested yet.

UPDATE: Sooo, with a cable connection to my router (rather than wireless) I hit 1,75 Mbit/s.

the rtorrent-on-debian-NSLU2-crash-issue

I'm still having problems with rtorrent on my NSLU2. It keeps crashing after two hours or so no matter what I do ([1], [2]) with .rtorrenct.rc.

However, yesterday it came across my mind, the actual problem (which is resources) could be connected to the user with whom I start rtorrent. rtorrent does not run as root but as a user with limited privileges on my NSLU2. My thinking was that Linux allocates more resources to root than to inferior users.

So I tried running rtorrent with screen and root. But still, not really a change.

I'm still wondering about the positive reports on rtorrent with the NSLU2 that e.g. google brings forward. When I asked once a forum user about how was running rtorrent, he basically replied:

"Well, it never crashed, but I've never downloaded anything with it".

So, do the positive reports only come from users who do not actually use their rtorrent?

Anyways, I'm running out of ideas on how to get rtorrent running stably. The ultima ratio seems to be to start with a fresh installation of debian...
argh.

ADSL2+ with Telefonica

Yay!:

Fritzbox 7170 connected directly to the "TAE" / No Splitter!

Yes, it is somewhat complicated. You'll need a proper cable to do that. And it seems you have to build it yourself. I'm still gathering information on that.

Nah, it has changed a bit. Watch the spectrum.

The spectrum is more square-edged or steppy between 64 and 90 kHz while the signal/noise quality is rounder. Also, I gained one dB in Signal/Noise-ratio... Yay!

Sole downer: lost 4 Kbit/s of potential upstream.. :)

Beta for Fritz!Box 7170: Firmware-Version 29.04.55-10393

DSL Version and figures almost the same, so I won't post any screenshot for now. Since I do not use the conventional (fixed) line any more (only VOIP), my next try is connecting the Fritz!Box directly to the TAE Box; I do not want to use the splitter any more. Effects on Signal Quality will be posted here soon.

Fritz!Box 7170 > DSL-Informationen

Mainly for my own ends I post here screenshots from my Fritzbox 7170 with "Labor-Version 29.04.97-10173" (DSL-Version 1.36.06.01) in order to compare it to my connection upgrade scheduled for march.
Currently, my ADSL is provided by 1&1, while the carrier is telefonica. The current Speed is 6656 kBit/s (down) and 640 kBit/s (up) (ADSL). When upgraded (ADSL2+), the carrier will still be Telefonica.

rtorrent on Debian NSLU2 unstable - Part 2

In order to find out the number of peers the nslu2 can handle i adjusted max_peers in ~/.rtorrent.rc to 50. It was running stably with the value of 40 before.
Sadly I had to find out, that with "50" rtorrent got killed again. So, I'll stick with "40" for now.

rtorrent on debian NSLU2

A few days ago I installed rtorrent on my debian slug. Rtorrent presents itself to be installed on the NSLU2 because of its

"[...] focus on high performance and good code.".

Therefore I expected a low memory and cpu footprint.
Furthermore, rtorrent makes use of ncurses and is therefore predestined to be detached with 'screen'.

Unfortunenately it turned out that the rtorrent-process (both libtorrent-0.12.0.0 with rtorrent-0.8.0 (unstable) and ibtorrent-0.11.9 with rtorrent-0.7.9.tar.gz) got regularly (every 2 hours or so) killed.

Dmesg in both cases:
Out of memory: Killed process 9754 (rtorrent).

Obviously, rtorrent consumes too much of the little RAM the NSLU2 has to offer. Being somewhat contrary to the quotation cited above...

In addition, it took rtorrent ages to hash a new torrent or to rehash a torrent when rtorrent got killed.

The hash problem could quite easily be resolved. With a little help from here all that had to be done was adjusting the hash parameters in ~/.rtorrent.rc:

# Hash read-ahead controls how many MB to request the kernel to read
hash_read_ahead = 5

# Interval between attempts to check the hash, in milliseconds.
hash_interval = 10

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
hash_max_tries = 3

The one problem remaining was the crashes. To cut a long story short: today rtorrent runs stably on my NSLU2. The only downer is with my current configuration I can only download one torrent at a time. Elsewise it gets killed again.


Here is my current .rtorrent.rc. The trigger to avoid the kills was adjusting the peers settings. Default was a much higher number (I don't remember.. ;)). I will continue adjusting it step by step to higher values to establish what I can expect from my NSLU2.


min_peers = 1
max_peers = 40

min_peers_seed = 1
max_peers_seed = 10

max_uploads = 2

download_rate = 0
upload_rate = 50

directory = ./dl-torrents
session = ./session

# Watch a directory for new torrents, and stop those that have been
# deleted.
schedule = watch_directory,5,5,load_start=/home/torrent/torrents/*.torrent
schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
schedule = low_diskspace,5,60,close_low_diskspace=100M
schedule = ratio,60,60,"stop_on_ratio=120,200M,150"

port_range = 30890-30998
port_random = yes

check_hash = no

use_udp_trackers = yes

# this setting remains from the actual (unstable)
# beta or alpha from rtorrent with dht tracker support.
# Thus commented out because I use a previous version
# dht_port = 30999

peer_exchange = yes

# here go the settings for faster hashing
hash_read_ahead = 5
hash_interval = 10
hash_max_tries = 3