Vernetzung

Da bei IPv6 Nodes (also Rechner und andere Teilnehmer an einem Netzwerk) schon konzeptionell mehrere Adressen haben ist die Auswahl welche Quell- und Zieladresse verwendet werden soll eine wichtige Funktion. Insbesondere dann wenn ein Rechner im Dual-Stack Betrieb sowohl IPv4 als auch IPv6 Adressen erreichen kann.

Bei IPv6 kann jedes Netzwerkinterface mehrere IPv6 Adressen haben, die dann entweder in unterschiedlichen Bereichen (Scopes) genutzt werden können (localhost, link, site, global) oder die unterschiedliche Bevorzugt (valid, prefered) sind. Durch die Unterstützung von Renumbering (stateless autoconfiguration) haben Adressen unterschiedliche Lebenszeiten. Zudem gibt es Adressen die über eine Migrations-/Tunnel Technologie wie Toredo, ISATAP oder 6to4 bereitgestellt werden, und nicht immer benutzt werden sollen.

Idealerweise würde eine Anwendung oder das Betriebssystem alle möglichen Quell/Ziel-Adresskombinationen ermitteln, und alle (aussichtsreichsten zuerst) durchprobieren. RFC 3484 beschreibt ein Verfahren für die Default Address Selection für IPv6. Der von Microsoft Research verfasste Entwurf gibt Regeln vor wie die Auswahl von Ziel- und Quelladressen zu geschehen hat, und definiert auch eine Möglichkeit dass der Administrator eines Systems eigene Gewichtungen definieren kann.

Ideal wäre eine Laufzeit Funktion, der man einen Hostnamen übergibt, und die dann die Verbindung zur Gegenstelle herstellt und dabei alle Regeln des RFC 3484 (und dringend notwendiger zukünftiger Verbesserungen) beachtet. Durch die Trennung zwischen Kernel und Usermode, und aus Gründen der Kompatibilität mit existierendem Netzwerkcode verwenden die meisten* Systeme allerdings ein anderes Verfahren. Bestehende Funktionen wie z.B. getaddrinfo(3) wurden erweitert: die Auflösung von Hostnamen in Adressen liefert jetzt eine nach Präferenzen sortierte Liste der Zieladressen zurück. Dabei greift die Bibliotheksfunktion auf Adress- und Routinginformationen des Kernels zurück. Denn es müssen für jede zurückgelieferte Zieladresse auch die potentiellen Quelladressen bestimmt und bewertet werden.

Unter Windows kann die Sortierung mit der prefixpolicy (netsh.exe interface ipv6 show prefixpolicies) angezeigt werden. Linux Systeme speichern die Konfiguration in /etc/gai.conf, aktuelle Einstellungen können mit dem iproute2 Paket angesehen werden (ip addrlabel). Das ganze ist im Kernel und der glibc implementiert.

Auch bei Java wurde kein komplett neues Verfahren für den Verbindungsaufbau für IPv6 definiert**. Die Anwendung selbst ist dafür zuständig alle möglichen Zieladressen der Reihe nach durchzuprobieren. Wenn die Anwendung keine Quelladresse angibt (was sie vermeiden sollte) so wird dann der Kernel für jeden der Zieladressen eine Quelladresse auswählen. Wenn eine Adresse nicht erreichbar ist, so muss die nächste Adresse verwendet werden. Wenn alle Adressen nicht erreichbar sind, so sollte eine Fehlermeldung zurückgegeben werden die alle probierten Zieladressen benennt und den ersten (oder alle) Fehlermeldungen benennt.

Beispielhaft kann dies so aussehen:

Socket connectToHost(String host, int port)
	throws UnknownHostException, SocketException
{
	IOException firstException = null;

	InetAddress[] addressArray = InetAddress.getAllByName(host);
	for(InetAddress addr : addressArray)
	{
		try {
			return new Socket(addr, port);
		} catch (IOException ex) {
			if (firstException == null)
				firstException = ex;
		}
	}

        // build informative error message
	StringBuilder msg = new StringBuilder("Unable to connect to host=");
	msg.append(host); msg.append(" port="); 
        msg.append(String.valueOf(port)); msg.append(" [");
	
	for(int i=0;i < addressArray.length;i++)
	{
		if (i != 0)
			msg.append(',');
		msg.append(addressArray[i]);
	}
	msg.append("]: "); msg.append(firstException.getMessage());
	SocketException se = new SocketException(msg.toString());
	se.initCause(firstException);
	throw se;
}

Dieser Code überlässt die Auswahl einer Quelle dem Kernel (es werden also nicht alle möglichen Kombinationen durchprobiert). Ebenso ist kein Handling für Timeouts enthalten, und ein Cache der Verbindungszustände erinnert oder gar ein paralleler Aufbau zu mehreren Zielen ist noch nicht enthalten. Trotzdem ist der Code schon recht komplex, sollte also nicht mehrfach implementiert werden müssen.

Von InetAddress.getByName(String host) würde ich auf jeden Fall Abstand nehmen. Diese Methode gibt nur die bevorzugte Addresse zurück, und führt bei DualStack Anwendungen dazu, dass nicht IPv6 und IPv4 Adressen durchprobiert werden.


* Microsoft ist typischerweise Entwicklerfreundlicher und muss weniger Rücksicht nehmen auf etablierte APIs, deswegen gibt es die Funktion WSAConnectByName() die alle Addressen selbst durchprobiert.

** Java kennt Socket(String name, int port), dieser Konstruktor verwendet aber keine Schleife um alle möglichen Adressen zu kontaktieren.

Mir ist gerade zufällig aufgefallen (als ich diesen Bugreport nachgestellt habe) dass Windows 7 IPv4 Address-Einträge die eine führende 0 haben im hosts file ignoriert:

C:\Windows\system32>echo 9.20.187.06 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96

C:\Windows\system32>echo 9.20.187.6 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96
    (Host-)A-Eintrag  . . : 9.20.187.6

Um Java Applets und JAR Files zu signieren nutzt man den jarsigner, der normalerweise ein Java-Keystore (.jks) file nutzt. Es ist allerdings ungünstig Codesigning Zertifikate einfach so in Files herumliegen zu haben (auch wenn man diese gesondert sichert). Es ist anzuraten ein Zertifikat besser in einer SmartCard oder einem Token zu speichern.

Der Oracle jarsigner.exe verwendet die Java Security Provider der JCE API. Um damit ein Hardware Token anzusprechen gibt es im wesentlichen 2 Methoden. Entweder den PKCS#11 Provider (benötigt eine PKCS#11 library (.dll oder .so) des Hardwareherstellers) oder unter Windows den Microsoft CryptoAPI (MSCAPI) treiber. Letzteres hat den Vorteil dass die meisten Smartcards unter Windows 7 oder 2008 bereits Treiber beim einstecken installieren. Diese Minitreiber sind nur begrenzt nutzbar, aber für das signieren reicht es aus.

Bei meinen Versuchen habe ich aber einige Einschränkungen gefunden:

• Es wird Java 5,6 oder 7(>b144) benötigt.
• Ich habe nur die Java Distribution von Sun/Oracle getestet
• In der 64bit Variante wird der Provider aktuell nur von Java 7 ausgeliefert
• Über MSCAPI wird immer in getrenntem Dialog nach PIN gefragt

Anbei Beispielbefehle zum auslesen des Keystores (in dem auch das Codesigning Zertifikat das auf dem USB Token gespeichert ist sichtbar ist) sowie dem Signaturvorgang:

c:\Program Files (x86)\Java\jdk1.6.0_24\bin>keytool -list -storetype Windows-MY

Keystore-Typ: Windows-MY
Keystore-Provider: SunMSCAPI

Ihr Keystore enthält 4 Einträge.
...
FIRMA AG, PrivateKeyEntry,
Zertifikatsfingerabdruck (MD5): 57:EF:97:04:EA:91:EE:FF:CF:BF:7F:75:AE:E1:A2:7D
...
c:\Program Files (x86)\Java\jdk1.6.0_24\bin>jarsigner.exe -storetype Windows-MY
%TEMP%\test.jar "FIRMA AG"

Als Speicher für die Zertifikate verwende ich ein Athena ASEKey Crypto Token in das ich mit den Athena IDProtect Tools auf einem anderen Computer das Codesigning Zertifikat von Verisign (Promo:WINQUAL99) importiert habe. Das Zertifikat ist übrigens ein Authenticode Class 3 Zertifikat das es aktuell für Teilnehmer am Microsoft WinQual Programm für ein Jahr günstig ($99) gibt. Entgegen den Angaben von Verisign lässt sich dieses auch problemlos für Java Signig verwenden.

Einziges Problem bei der Sache, mit -storepass oder -keypass lässt sich die PIN für die SmartCard nicht angeben, diese fragt immer mit einem Popup nach entsprechender Freigabe. Ich habe in den Athena Tools keine Möglichkeit gefunden diese abzuschalten (allerdings geht es mit der PKCS#11 API, wie ich im nächsten Beitrag berichten werde).

c:\Program Files (x86)\Java\jdk1.6.0_24\bin>jarsigner -verify -certs -verbose %T
EMP%\test.jar

         134 Thu Jun 02 23:27:48 CEST 2011 META-INF/MANIFEST.MF
         258 Fri Jun 03 00:04:02 CEST 2011 META-INF/FIRMA_AG.SF
        4764 Fri Jun 03 00:04:02 CEST 2011 META-INF/FIRMA_AG.RSA
           0 Thu Jun 02 23:23:38 CEST 2011 META-INF/
sm     15104 Sun Mar 06 04:56:06 CET 2011 jarsigner.exe

      X.509, CN=FIRMA AG, OU=Software Development, 
                OU=Digital ID Class 3 - Microsoft Software Validation v2,
                  O=FIRMA AG, ST=Baden-Wuerttemberg, C=DE
      [certificate is valid from 21.12.10 01:00 to 22.12.11 00:59]
      X.509, CN=VeriSign Class 3 Code Signing 2010 CA
      [certificate is valid from 08.02.10 01:00 to 08.02.20 00:59]
      [KeyUsage extension does not support code signing]
      X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5
      [certificate is valid from 08.11.06 01:00 to 17.07.36 01:59]
      [KeyUsage extension does not support code signing]


  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Update: Ich habe das ganze gerade mit der b144 von Java 7 getestet, und damit lassen sich sowohl mit 32bit als auch mit der 64bit Version der MSCAPI Provider für die Signatur von JAR Files via Smart Token nutzen.

Kris weißt in einem Tweet auf eine Diskussion zum Thema Sicherheit von Management-Adaptern hin. Im konkreten Fall wurde vermutet dass ein BMC (Der Mikro-Controller der die IPMI Schnittstelle bereitstellt) Spam Mails versendet hatte (nachdem er kompromittiert wurde). In dem Forum wird nicht klar, ob es wirklich der Fall ist und welche Schwachstelle dabei verwendet wurde. Aber in den Kommentaren sind einige sehr bedenkliche Meinungen und Vorgehensweisen zu entdecken:

Management Adressen (SSH, HTTP, Remote-IPMI) werden von einzelnen Admins absichtlich im öffentlichen Netz zugänglich betrieben - oder aus Versehen aus Unkenntnis. Hersteller der BMCs installieren keine oder unsichere Default-Passwörter. Generell waren die Admins der Meinung dass BMCs gar nicht die Ressourcen haben um Spam zu versenden, und es wird unterstellt die Firmware auf den Controllern sei unbedingt sicher.

Das ist natürlich eine naive Annahme. Auf den BMC Mikro-Controllern läuft ein Betriebssystem mit vollem IP-Stack und Anwendungsprozesse (Web Server, SSH Daemon, IPMI Agent, Shell/Menu) und diese können natürlich falsch konfiguriert werden oder verwundbar sein. Die IPMI Firmware wird oft von Administratoren vernachlässigt, weil es nicht in den normalen Update Prozessen des Betriebssystems integriert ist.

Ich sehe folgende Punkte für den Betrieb von Servern mit Management Adaptern (oder Lights-Out Karten) als wichtig an:

• Firmware des BMC in den Update/Patch Prozess aufnehmen
• Mittels physischer Ports oder VLANs BMC in getrenntem Management LAN betreiben
• Zugriff auf Management LAN beschränken, nur über sichere Hops zugreifen lassen
• Server provisioning Prozedur muss sichere Konfiguration der BMC Adapter beinhalten (Zertifikate, Passwörter, User, evtl. SSO, WoL Secret....)
• Verzicht auf Produkte die keine Netzwerksicherheit (Verschlüsselung) bieten

Generell kann man sagen, der Remote-Zugriff auf BMC Funktionen ist vergleichbar mit physikalischem Konsolen-Access (besonders dann wenn hier auch Consolas und Laufwerke gemapped werden können).

Aus gegebenem Anlass:



Übrigens, es wird Zeit dass Facebook Gruppen mit ernstem Hintergrund genausoviele Fans bekommen wie Satiregruppen (Pro Guttenberg), deswegen hier meine Like Empfehlung: http://www.facebook.com/AtomausstiegJetzt

Mit dem neuen (Beta) Dienst Beanstalk steigt Amazon in das Platform-as-a-Service Geschäft ein. Vergleichbar mit dem Google AppEngine for Java Dienst können Java Entwickler einfach Web Anwendungen in WAR Files verpacken und in die Cloud hochladen. Amazon kümmert sich um die Skalierung aller Komponenten. Man könnte fast annehmen ursprünglich war das WAR Deployment Modell genau so gedacht.

Amazon rechnet die unterliegenden Infrastrukturdienste ab. Das ergibt sich aus den Freiheitsgraden die man hat, macht die Rechnung aber komplex - und vor allem für Low-Traffic Anwendungen eventuell nicht gerade preiswert. Die Amazon Beispielrechnung kommt z.B. auf $30/Month. Immerhin können die sehr günstigen EC2 Micro Instanzen ($0.02/h) genutzt werden.

One advantage of running your own Diaspora pod is the fact, that you have access to the MongoDB which is used to store your Seed. This allows you to do some functions which do not yet have a UI (for example canging the E-Mail address of a user) or which is required to work around alpha hickups (deleting duplicate requests).

The mongo shell is a client to the mongodb, which can evaluate JavaScript expressions. It has some macros ("use", "show" and "help"), the other commands are typically JavaScript methods.

First you assign a Database Object to the variable "db", you can use that with "use". In the case of Diaspora, the database is named "diaspora-ENVIRONMENT". If you start mongo shell, it will start with the database "test", but you can list all existing databases, and pick one:

$ mongo
connecting to: test
> print('hello JavaScript!')
hello JavaScript!
> show dbs
admin
diaspora-development
local
magent
> use diaspora-development
switched to db diaspora-development
> db
diaspora-development
> show collections
aspects
comments
contacts
invitations
people
posts
requests
system.indexes
users

Note: you can specify non-existing databases and collections, they are initially empty but will be created, so do not misstype. You can use db.collection.help() to see the available methods on a collection object. find() is used to search and display documents. If you specify no parameters it will return a cursort with all documents. The first parameter can be a list of filter criterias, and the second parameters a list of properties to return. mongo shell will iterate and print the first ten entries of a cursor automatically:

> db.users.find({},{username:1,email:1})
{ "_id" : ObjectId("4cf1..02"), "username" : "bernd", "email" : "bernd-09@eckenfels.net" }
{ "_id" : ObjectId("4cf1..2d"), "username" : "mela", "email" : "mela@mela.de" }
{ "_id" : ObjectId("4cf2..3b"), "username" : null, "email" : "xx@example.com" }

Here you can see, that this pod has 3 users (seeds), two are already established, the third is a pending invite (token).

To change the e-mail address of a existing user you can assign the document to a variable, change the desired property and update the collection. For this we use the findOne method, which does return the first match instead of a cursor:

> var bernd = db.users.findOne({username:"bernd"})
> print(bernd.email)
bernd-09@eckenfels.net
> bernd.email = "bernd-10@eckenfels.net"
> db.users.save(bernd)
> db.users.findOne({username:"bernd"}).email
bernd-10@eckenfels.net

The above will not create a new document, since the variable "bernd" contains the property _id, and therefore it will update the existing entry in the collection.

You need to know that db.users contains the actual users of the pod (i.e. the seeds) and db.people contains a copy of the public part of other seeds (if you received a request from them, or if you added them to an aspect).

> db.requests.findOne()
{
        "_id" : ObjectId("4cf1...a3"),
        "sent" : true,
        "from_id" : ObjectId("4cf1...03"),
        "to_id" : ObjectId("4cee7...a9"),
        "into_id" : ObjectId("4cf1...9d")
}
> db.people.findOne({_id:ObjectId("4cf1...03")}).diaspora_handle
bernd@pod.eckenfels.net
> db.people.findOne({_id:ObjectId("4cee7...a9")}).diaspora_handle
daniel...@joindiaspora.com
> db.aspects.findOne({_id: ObjectId("4cf1...9d")}).name
Piraten

As you can see I sent a request to "Daniel", inviting him to my aspect "Piraten", but he has not yet responded.

Hope this helps you to find your way around in the object model of Diaspora. I recommend you read the MongoDB tutorial to better use the mongo shell, and check the JS API documentation for the details.

Diaspora* die Software für verteilte soziale Netze wurde in einer Alpha Version veröffentlicht.

Bei Diaspora ist vorgesehen dass es keine zentrale Plattform gibt, sondern Benutzer Ihre eigenen Server - Pods genannt - betreiben. Da es aktuell auch auf dem offiziellen pod von joindiaspora.com keine Benutzer freigeschalten werden, ergibt es Sinn einen eigenen Server aufzusetzen.

Im Diaspora Wiki findet man dazu eine Anleitung. Allerdings beschreibt diese nicht, wie man in einer Produktivumgebung die Ruby Anwendung mit einem Webserver versieht, der die Anfragen auf Port 80 entgegennimmt (und statische Assets direkt ausliefert).

Ich habe dazu einen virtuellen Host mit Apache eingerichtet, die Konfiguration sieht so aus:

LoadModule proxy_module ...
LoadModule proxy_http_module...

<VirtualHost *>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/example.com/pod/data/public
    ServerName pod.example.com
    ErrorLog /var/log/httpd/pod.example.com-error_log
    CustomLog /var/log/httpd/pod.example.com-access_log combined

    Alias /uploads/ "/var/www/example.com/pod/data/public/uploads/"
    Alias /images/ "/var/www/example.com/pod/data/public/images/"
    Alias /stylesheets/ "/var/www/example.com/pod/data/public/stylesheets/"
    Alias /javascripts/ "/var/www/example.com/pod/data/public/javascripts/"

    ProxyPass / http://pod.example.com:3000/

  <Directory "/var/www/example.com/pod/data/public">
    Options Indexes FollowSymLinks MultiViews IncludesNoExec ExecCGI
    AllowOverride All
    Order Allow,Deny
    Allow from All
  </Directory>
</VirtualHost>

D.h. Diaspora ist im Verzeichnis /var/www/example.com/pod/data installiert, und der Ruby Server "thin" ist erreichbar auf dem Port 3000.

Falls es jemand testen will, mein Diaspora Seed ist damit unter bernd@pod.eckenfels.net erreichbar.

Vor einiger Zeit habe ich mich bei der PR Agentur von Trekstor beschwert, dass diese mir als Blogger zwar unverlangt Pressemitteilungen senden, aber ohne Testgeräte ich nicht viel berichten kann und will. Jetzt habe ich überraschend ein Testgerät von Trekstor erhalten, und will dies hier gerne besprechen:

In einem sehr kleinen Paket habe ich den "Trekstor Portable WLAN Hotspot" für einen 2-wöchigen Test erhalten. Ein Gerät in der Größe eines Mobiltelefons das als WLAN Hotspot eingesetzt werden kann, und dabei die Verbindung mit dem Internet mittels eingebauter UMTS Funktion herstellt. Es ist also ein UMTS WLAN Router, benötigt dabei aber keinen externen USB Stick, die SIM-Karte des Mobilfunkanbieters wird direkt in das UMTS fähige Gerät eingelegt.

Bis zu 5 WLAN Geräte können sich mit dem Hotspot verbinden, und dieser stellt dann die Verbindung zum Internet via UMTS/HDSPA (3G) oder GSM her. Zusätzlich hat das Gerät einen Mini-USB Anschluss über das es geladen werden kann. Über diesen USB 2.0 Anschluss kann auch ein weitere Rechner (Via Hi-Speed USB 2.0 Netzwerk Interface Treiber) angebunden werden.



Der kleine Hotspot kümmert sich dabei um NAT, Firewall, hat einen DNS Proxy und DHCP Server eingebaut. Konfiguriert wird das Gerät über den Web Browser. Die Knöpfe am Gerät beschränken sich auf ein Minimum (Ausschalter, WLAN Schalter, Manueller Connect).

Das Trekstor Gerätes ist Baugleich mit dem E5 von Huawei (dies wird auch nicht versteckt, das Logo ist auf der Rückseite zu sehen). Das Gerät ist Netlock frei, konnte in meinem Test mit Prepaid Standard SIM Karten von blau.de ebenso wie mit einem UMTS Datenvertrag von O2 genutzt werden. Es unterstützt UMTS im 2100MHz Band sowie Quad-Band GSM (EDGE, GPRS) 850/900/1800/1900MHz - ist also für Reisen geeignet. Das WLAN Modul kann im 2,4GHz Band die Kanäle 1-13 nutzen. (Es gibt bei den Europäischen Modellen eine Ortseinstellung bei der man auch "Japan" auswählen kann, diese schaltet aber keinen weiteren Kanal frei). Das Gerät unterstütz WPS, konnte ich aber mangels Gegenstelle nicht testen. Diese Funktion klingt aber kaum einfacher als das abtippen eines Passwortes von der Gehäuserückseite.

Die Anwendungsfälle sind vielfältig. Als Besitzer von Internet Tablets oder Game Consolen die keine UMTS-Stick Möglichkeit haben ist das Gerät auf jeden Fall eine praktische Option. Weiterhin kann das Gerät von kleinen Reisegruppen oder Arbeitsgruppen mit Note- oder Netbooks genutzt werden um einen (teuren) Internetzugang gemeinsam zu benutzen. Es ist damit Ideal geeignet die Wartezeit am Flughafen zu überbrücken ohne dass jeder der beteiligten einen eigenen Datentarif haben muss (einige Provider erlauben nicht den Betrieb von mehreren Geräten per NAT, dies muss im Einzelfall geprüft werden).

Praktisch an dem Prinzip der WLAN Anbindung ist, dass in der Regel alle Geräte ohne spezielle Treiber die Vermittlungsfunktion des Gerätes nutzen können. Es wird dabei WLAN nach 802.11 b/g mit WPA und oder WPA2.

Der WLAN Hotspot wird mit einem austauschbaren 3.7 V, 1500 mAh Akku geliefert. Es kann über USB vom Rechner geladen und mit Strom versorgt werden. Bei meinen Tests hatte es Laufzeiten von über 4h. Es kann dabei auch von USB Steckernetzteilen oder externen Akkus (Test mit einem Phillips Reserveakku, der zum Beispiel von iPhones nicht akzeptiert wird, war erfolgreich).

Als zusätzliche Funktion bietet das Gerät übrigens noch einen MicroSD Kartenslot in der Speicherkarten bis zu 32GB eingesteckt werden können. Diese können dann entweder über den USB Anschluss benutzt werden, oder der Zugriff auf den Inhalt steht über den Web Server des Geräts zur Verfügung.

Generell ist das Gerät und die Software gut durchdacht, es können mehrere Mobilfunk Profile angelegt werden; mutige Zeitgenossen können die Mobilfunk-PIN im Gerät speichern; wenn Roaming erkannt wird vermeidet das Gerät automatisch Online zu gehen. Bei der Auslieferung hat das Gerät einen eindeutigen Verschlüsselungskey (der auf der Geräterückseite aufgedruckt ist). Die NAT (ALG, DMZ) und Firewall Funktionen können mit guten Home Routern locker mithalten.

Das Gerät wird mit einem kurzen Mini-USB nach USB Kabel geliefert (aber keinem Netzteil) und einem Quick-Start Guide der keine der Optionen der Software auch nur ansatzweise erklärt. Er ist aber ausreichend um die erste WLAN Verbindung mit dem Gerät aufzubauen (Ich empfehle als einer der ersten Aktionen den WPA2 Modus zu aktivieren).

Ja, ich kann das Gerät fast nur loben, auf der Seite der Nachteile sehe ich vor allem den relativ hohen Preis (wobei es im direkten Vergleich mit anderen Geräten in der Leistungsklasse mit 139,- Eur günstig abschneidet), kleinere Lieblosigkeiten in der recht technischen Web Oberfläche (zum Beispiel die Deutsche Übersetzung "x Tag x Stunden x Protokoll") und die doch recht knappe Begrenzung auf 5 WLAN Clients.

Das OLED Dot Display ist recht übersichtlich aber unter vielen Lichtbedingungen kaum abzulesen (spiegelt). Dem Gerät fehlt auch eine VPN Funktion, allerdings sehe ich das nicht als Nachteil an, ein VPN sollte besonders in diesem Einsatzszenario (WLAN) auf dem Endgerät (Notebook) terminiert werden.

Für den stationären Einsatz würde ich das Gerät nicht empfehlen, ebenfalls nicht zur (Not)Versorgung von Veranstaltungen mit Internet (wegen der Anzahl der Clients und den fehlenden externen WLAN Antennen). Aber als Reisebegleiter macht es eine sehr gute Figur. Ich habe keine Erfahrungen mit der Stabilität des Gehäuses, beim Anfassen traut man dem Gerät keine große Robustheit zu. Das Gerät ist auf jeden Fall im Vergleich zum Mitbewerb (D-Link MyPocket, Novalink MiFi) sehr kompakt.

Immer wieder liest man Empfehlungen dass man auf keinen Fall private Nutzung der Unternehmens-IT zulassen darf, dass es problematisch ist wenn man persönliche Mails duldet, ja sogar steuerlich schwierig ist, wenn man den Mitarbeitern geldwerte Vorteile (wie einen Internet Zugang) bietet. Auch vor den Sicherheitsaspekten wird gewarnt. Lizenzgründe oder Haftungsgründe werden angeführt.

Ich möchte mich hier mal auf die andere Seite stellen: warum haben Arbeitgeber ein Interesse daran, dass Mitarbeiter die Firmen-IT auch für Aktivitäten nutzen die nicht direkt im Geschäftsinteresse stehen.

Nun allen voran natürlich die Mitarbeiterzufriedenheit. Gute Mitarbeiter zu halten ist wichtig. Wenn diese ein offenes Klima erleben sind sie viel gewillter zu bleiben. Grade bei Überstunden oder exotischen Arbeitszeiten ist es wichtig nebenbei auch Kontakt mit den Lieben zu halten. Sich mit der Freundin im Messenger auszutauschen damit diese nicht den Arbeiter nach Hause zitiert.

Daneben ist jeder Mitarbeiter der sich im Web bewegt auch ein informierter Mitarbeiter. Im Zweifel auch ein Mitarbeiter der für das Unternehmen Werbung macht. Ganz gemäss des (schon öfters genannten) Cluetrain Manifests werden immer mehr Kunden durch direkte Kontakte mit Mitarbeitern auf Produkte aufmerksam.

Betrachtet man das Leben eines Consultants (Road Warriors) auf der Straße und in Hotels, so hat dieser gewiss andere Probleme als mehr als einen Notebook mit sich herumzuschleppen. Wird Ihm verwehrt diesen auch zum DVD Genuss einzusetzen, so wird er noch weiter benachteiligt und hat irgendwann kein Interesse mehr auf Außeneinsatz.

Die Nutzung von Diensten des Arbeitgebers wie Mail und IM sollte so offen gestaltet sein, dass Mitarbeiter gerne auch nach Feierabend diese Medien nutzen. Ganz im Interesse der Firma: die Mitarbeiter bleiben in Notfällen einfacher ansprechbar.

Das surfen am Arbeitsplatz - sei es nun in Wartezeiten oder der Mittagspause ist eine Entspannung vergleichbar mit der Raucherpause oder dem Mittagsspaziergang. Wird die Nutzung des Webs eingeschränkt oder strikt kontrolliert, so suchen sich kreativ arbeitende Köpfe andere Ablenkungen (zum Beispiel sinnlose Meetings). Es ist also nur in Ausnahmefällen so, dass die Produktivität dadurch gesteigert wird.

Unmotivierte Mitarbeiter die Zeit haben ihren Tag zu vertrödeln sind eine Herausforderung an das Team oder die Vorgesetzten, aber sicher nicht für die interne-IT.