Kategorie: Apfel

In meinem Haus gibt es überall Ethernet, aber nicht überall WLAN. Das ist ärgerlich, kein Router schafft es, das ganze Haus alleine auszuleuchten. Getestet bisher: FritzBox 7270, Telekom Speedport Hybrid, Apple Airport Extreme, Ubiquiti UniFi AP LR, TP-Link 741.

Ich möchte aber im ganzen Haus ordentliche Bits haben und handle mal kurz ab, wie ich versuche zu einer Entscheidung zu kommen.

Die naheliegende Lösung

Man rennt los und holt sich einen zweiten Access Point. Diese wird mit gleichen Einstellungen (ESSID, Kanal, Passwort) als Bridge zwischen LAN und WLAN betreiben. Das Problem an der Sache: die mobilen Clients „kleben“ an ihrem Access Point. Wenn man sich durch das Haus bewegt, wird die WLAN-Verbindung immer schlechter. Der Client hängt dann vielleicht mit 1MBit am Access Point in der oberen Etage und schafft kaum ein Paket zu empfangen, während man mit ihm neben dem Access Point in der unteren Etage steht. Schon fast reflexartig knipst man dann das WLAN am Mobiltelefon aus und wieder an, damit der nähere Access Point gewählt wird. Das ist nervig.

Die politisch inkorrekte Lösung

WLAN-Repeater kommen für mich prinzipbedingt nicht in Frage:

• Die Daten sind doppelt in der Luft, die Bandbreite leidet (gute Repeater können auf zwei Bändern funken und werden beim repeaten wenigstens nicht langsamer).
• Repeater machen „Magie“. Sie müssen tricksen und machen so eine Art NAT auf Layer 2, jeder Hersteller kocht da seine eigene Suppe. Disclaimer: dieser Punkt ist gefährliches Halbwissen, was ich nebenbei aufgeschnappt habe, in meinem Kopf blieb lediglich haften: Repeater sind grundsätzlich scheiße. Sie mögen funktionieren, sind aber immer noch der schlechteste Kompromiss.
• Es wiederspricht meinem gesunden Menschenverstand: ich habe überall Gigabit LAN, Daten gehören ins Kabel, nicht in die Luft

Die teure Lösung

Weil ich beruflich bedingt, aber auch sonst Apple-Fanboy bin, habe ich mir eine Airport Extreme geklickt. Dazu gibt es noch eine Airport Express für die untere Etage. Die Hoffnung ist, dass hier Roaming funktioniert. Die Airports sind sehr teuer, haben wenig Optionen und wollen alles für einen regeln. Leider musste ich feststellen, dass es (in meinem Netzwerk) nicht möglich ist die beiden Geräte kabelgebunden zu betreiben. Sobald beide Geräte am LAN hängen, geht gar nichts mehr: die WLAN-Verbindung an meinem Notebook bricht ständig zusammen, Paketverluste ohne Ende und natürlich kein Log, keine Info, keine Fehlermeldung – Apple halt.

Ich habe die beiden Airports dann so betrieben, dass die Express benutzt wurde um das WLAN der Extreme zu vergrößern (das scheint eine Art WDS oder Repeater-Funktion zu sein). Diese „Range-extender“-Lösung funktioniert soweit ganz gut. Ich kann zumindest durchs Haus laufen und i.d.R. hängt mein Telefon am „richtigen“ Access Point und hat eine gute WLAN-Verbindung.

Es ist jedoch irgendwie unbefriedigend, weil die Daten der Airport Extreme immer zweimal durch die Luft gehen, obwohl in unmittelbarer Nähe eine LAN-Dose zur Verfügung steht.

Die „richtige“ Lösung

Natürlich gibt es auch eine „richtige“ Lösung: Managed WLAN mit einem WLAN-Controller. D.h. eine Instanz im LAN spricht mit allen Access Points und kann entscheiden, welcher Client an welchem Access Point hängen sollte. Das Roaming zwischen den Access Points ist die hohe Kunst.

Es gibt dafür sehr teure Lösungen und es gibt etwas von Ubiquiti. Also habe ich mir zwei UniFi AC Lite Ufos geklickt. Das Paket war noch nicht ausgepackt, da chattet mich Kollege S. an. Er hat das gleiche Problem (große Wohnung, viel LAN, wenig WLAN) und hat festgestellt, dass Zero-Handoff scheinbar nicht mit AC-Geräten von Ubiquiti funktioniert. Wenn man danach googelt ist man nicht schlauer, in den Foren des Herstellers gibt es seitenlange Threads aus denen hervor geht, dass Zero-Handoff mit AC-Geräten möglicherweise nie funktionieren wird. Gründe dafür findet man aber nicht.

Was tun? Genau: nachmessen.

Der große Showdown

Ich habe zu testzwecken noch zwei Ubiquiti UniFi APs geklickt. Die können „nur“ 802.11n auf 2.4GHz. Das ist für meine Anwendung aber ausreichend (Twitter muss auf dem Klo funktionieren). Große Datenmengen schiebe ich am LAN-Kabel durch die Gegend und in der Praxis ist dann 802.11ac auch nicht sooo viel schneller.

Mein Benchmark ist: welche Geräte schaffen sauberes WLAN-Roaming? Ich möchte also durchs Haus laufen und möglichst immer Netz haben.

Die gewählte Messmethode ist hochwissenschaftlich: ping. Ich pinge 10x pro Sekunde mein Telefon an und laufe damit immer wieder die gleiche Strecke durchs Haus. Wenn ich unten in der Küche angekommen bin, wechselt das Telefon zum unteren AP. Auf dem Weg nach oben erfolgt ebenfalls nochmal ein Wechsel des Access Points. Damit das ganze etwas aussagekräftiger wird, wiederhole ich die Messung drei Mal. Dann teste ich noch verschiedene Paketgrößen: 56, 504 und 1492 Bytes.

Nachdem ich also 36 Mal durch das Haus gewandert bin und unter den irritierten Blicken der Familie Zahlen murmelnd wieder verschwunden bin kann ich folgendes verkünden:

In Worten bedeutet es, dass die Airports am meisten Pakete verlieren, wenn ich durchs Haus gehe. Die UniFi APs verlieren am wenigsten und die UniFi AC sind irgendwo dazwischen. Interessanterweise performt der UniFi AP mit eingeschaltetem Zero-Handoff schlechter. Die besten Ergebnisse bringt der UniFi AP ohne Zero Handoff.

Damit ist Entscheidung nicht einfacher: Zero Handoff funktioniert scheinbar nicht wirklich, außerdem muss man sich auf einen Kanal festlegen und hat nur noch die halbe 802.11n Bandbreite (HT20). Nachdem ich die ganze Messung durchgeführt habe, grübel ich schon wieder, was wichtiger ist: nahtloses Roaming (was es so nicht gibt) oder gute Bandbreite an einem bestimmten Platz im Haus (die ich eigentlich nicht benötige).

Disclaimer

• Das Ergebnis ist nur für meine Situation anwendbar. Jedes Haus, jede WLAN-Umgebung ist anders.
• Es ist natürlich etwas unfair, weil die Airport Express nicht am LAN hängt. Die Datenmenge ist viel zu klein und das ganze Vorgehen ist höchst unwissenschaftlich. Ich bin halt Praktiker 😉
• Jolly hat vor einem Jahr die Performance der UniFi APs viel genauer nachgemessen und festgestellt, dass es bei den Geräten Dropouts gibt. Das war nicht Teil meiner Untersuchung. Möglicherweise gibt es inzwischen einen Fix in der UniFi Firmware für das Problem. Ich konnte bisher keine Probleme feststellen. YMMV.

Ich empfinde das Eintauchen in die Welt von Objective C und Cocoa als sehr erfrischend, jeden Tag gibt es etwas neues zu entdecken. Wenn man sich mit anderen Entwicklern, die Objective C nicht kennen, unterhält, kommt aus der C++ Ecke garantiert die Frage: „Kann man dort Operatoren überladen?„.

Nein kann man nicht. Braucht man auch gar nicht. Operatoren zu überladen ist zweifelsohne cool, aber ich multipliziere nicht den ganzen Tag Matrizen, sondern baue Dinge für Endanwender. Das angenehme an Objective C ist, dass es bestimmte Real World Probleme sehr schön löst.

Key Value Observing ist so eine Lösung und es ist ein so verdammt einfaches Konzept, dass ich mich wundere, wie die Welt bisher ohne leben konnte… (Um es vorweg zu nehmen: GObject hat ein ähnliches Konzept und es gibt bestimmt noch mehr Implementierungen dieses Patterns).

Das Real World Problem kommt bestimmt jedem bekannt vor: man hat eine Klasse A gebaut und eine andere Klasse B muss benachrichtigt werden, wenn sich in A irgendetwas interessantes ändert. Bisher wäre das Herangehen, dass A eine Referenz auf B mitschleifen muss, damit Klasse A die Klasse B benachrichtigen kann. Das bringt natürlich das schöne Klassendesign durcheinander, eigentlich hat A mit B nichts zu tun und die Referenz auf B zu handhaben ist auch nervig.

In Objective C gibt es Properties, die Membervariablen und deren Getter und Setter erzeugen können:

// foo.h
@interface Foo
@property(nonatomic, copy) NSString* bar;
@end
 
// foo.m
@implementation Foo 
@synthesize bar;
@end

Im obrigen Beispiel hat die Klasse „Foo“ ein Member „bar“ und @synthesize generiert die Getter und Setter, die dann so verwendet werden können:

Foo *fooInstance = [Foo new]; // oder [[Foo alloc] init]
fooInstance.bar = @"Value";
NSLog(@"foo.bar=%@", fooInstance.bar); // "foo.bar=Value"
 
[fooInstance setBar:@"eulaV"]; // geht auch
NSLog("@foo.bar=%@", [fooInstance bar]); // "foo.bar=eulaV"
 
[fooInstance release];

Soweit, so trivial. Mit Key Value Coding kann man auf Properties programmatisch zugreifen. Das bedeutet, ich baue mir einen String zusammen, dessen Inhalt der Name einer Property ist und ich kann auf die Property zugreifen:

NSString* dings = [fooInstance valueForKey:@"bar"]; // "getter"
[fooInstance setValue:@"Hi there!" forKey:@"bar"]; // "setter"

Das wird unheimlich praktisch, wenn man z.B. XML parsen muss und die geparsten Key/Value-Paare direkt via KVC in den Properties einer Klasse speichern kann.

Key Value Observing ist nun die Lösung o.g. Problems: man kann sich einfach von außen als Observer für bestimmte Properties einer Klasse registrieren und wird benachrichtigt, falls sich ein Wert ändert.

Das spart eine Menge Code und die beobachtete Klasse A braucht sich um Klasse B nicht kümmern und muss keine Referenz auf B mitschleifen.

// als Observer registrieren ist einfach:
[fooInstance addObserver:self   // sag mir bescheid,
              forKeyPath:@"bar" // wenn sich bar ändert
               options:NSKeyValueObservingOptionNew
               context:NULL];
 
// der Observer muss diese methode implementieren, 
// um benachrichtigt zu werden:
- (void) observeValueForKeyPath:(NSString *)keyPath
		     ofObject:(id)object
		       change:(NSDictionary *)change
		      context:(void *)context 
{
    if ([keyPath isEqualToString:@"bar"])
        NSLog(@"new value for bar: %@", object);
}
 
// wenn man genug hat, meldet man sich wieder ab
[fooinstance removeObserver:self forKeyPath:@"bar"];

Ich finde das ziemlich elegant. Das Klassendesign bleibt sauber und trotzdem ist es möglich, sich kreuz und quer durch alle Schichten der Anwendung über Zustandsänderungen benachrichtigen zu lassen.

Update: Es gibt einen sehr schönen Wrapper von Andy Matuschak: Block Callbacks for Cocoa Observers (via Ole Bergmanns hoch interessantem Twitterstream)

Wenn das offizielle isync-Plugin von Nokia sich beschwert, dass man zuerst isync aktualisieren soll, obwohl man die geforderte isync-Version 2.4 installiert hat, dann sollte man sicherstellen, dass isync wirklich im Ordner „Programme“ installiert ist (und nicht in einen Ordner unterhalb verschoben wurde).

Ich bin ein Mail-Junkie. „Mein Gott, bist Du kommunikativ!“ ist noch ein Vorwurf der netten Sorte.
Was ich nicht in meinem Kopf habe, liegt in meiner INBOX. Die Suchfunktion des Mailprogramms hat schon so manche Gedächtnislücke gefüllt. Seit etlichen Jahren schwöre ich auf die Kombination aus IMAP und Eichhörnchen, damit ich auch von überall auf der Welt an meine Mails komme und ich nicht zwei Postfächer pflegen muss.
Seit dem Apfel auf meinem Schreibtisch versuche ich mit Mail.app glücklich zu werden. Bisher klappt es auch ganz gut, es gibt aber ein paar geniale Tools, die das ganze noch komfortabler machen.

Mail Appetizer

Mail Appetizer zeigt neue Mails in einem halbtransparenten Vorschaufenster an. Man kann also mit einem kurzen Blick prüfen, ob es sich lohnt das Mailprogramm nach vorne zu holen. Das kling simpel, ist aber extrem nützlich. Und so sieht’s aus:

IMAP-IDLE

IMAP-IDLE stattet Mail.app mit Unterstützung für das IDLE-Feature von IMAP aus. Wenn der Mailserver dieses Feature unterstützt, benachrichtigt er Clients sofort beim Eintreffen von neuen Mails. Mail.app muss also nicht mehr den Server im Minutentakt nach neuen Mails fragen.

Für Courier-IMAP muss man in der /etc/courier/imapd das Idle-Feature mit folgender Zeile aktivieren:

IMAP_ENHANCEDIDLE=1

IMAPCheck

Leider Prüft Mail.app nur die INBOX selbst und keine Unterordner. Wenn Mails direkt vom Mailserver in die Ordner sortiert werden, merkt man so lange nichts davon, bis man nicht auf diesen Ordner klickt.
Dieses Problem behebbt IMAPCheck: damit werden alle IMAP-Ordner nach neuen Nachrichten geprüft.

Ich haben endlich das leidige Problem mit den Netzlaufwerken und dem Ruhezustand gelöst. Mit Sleepwatcher kann man so ziemlich jede Aktion beim Einschlafen bzw. Aufwachen seines Macs ausführen lassen.
Egomanen lassen sich bei jedem Aufwachen von der eingebauten iSight-Kamera fotografieren und bekommen auf diesem Wege interessante Einblicke in die Service-Abteilung von Apple 🙂 Meiner einer ist nicht ganz so selbstverliebt und begnügt sich mit dem Ausführen einiger AutomountMaker-Scripte. Das .wakeup Script sieht jetzt bei mir so aus:

#!/bin/sh
/Applications/Utilities/AutomountMaker/AutomountMaker.app/Contents/MacOS/AutomountMaker \
  /Users/melle/Documents/automount/mount-mp3.amsf \
  /Users/melle/Documents/automount/mount-shared.amsf \
  /Users/melle/Documents/automount/mount-melle.amsf

Was mich beim ipod extrem nervt, ist die Sortierung der Songs. Jeder andere Player sortiert im Zweifelsfall die Songs in einem Verzeichnis nach dem Dateinamen. Apple hält sich für besonders schlau und sortiert, wenn keine Tracknummer im ID3-Feld steht, statt dessen nach dem Songtitel. Ahrg, da nützt es natürlich nichts, wenn die Dateien „Track01.mp3“ bis „Track99.mp3“ benannt sind 🙁
Ok, was tun, wenn man 1300 Alben auf der Platte hat, von denen bei etwa der Hälfte die Tracknummer fehlen? Easytag ist zwar gut, aber so viel Zeit habe ich dann doch nicht 😉 Ich habe mir ein olles PHP-Script hingefrickelt, bis es tat, was es sollte. Wer mehr Komfort möchte, darf es schöner machen 😉
„MP3s durchnummerieren“ weiterlesen