Der Entschluss stand schnell fest, dass ich mir nun auch eine DSLR-Ausrüstung zulegen werde. Nach Vergleich von verschiedenen Modellen (sowohl aus dem DSLR- wie auch aus dem Systemkamera-Bereich bei http://www.dpreview.com) ist die Entscheidung auf die Canon EOS 60D gefallen, wobei die Wahl für Canon auch dadurch begünstigt wurde, dass der zuvor genannte Freund auch eine Canon-Ausrüstung hat und somit ein gewisser Austausch möglich ist.

Motive für erste Testaufnahmen fand ich letzten Donnerstag in der Zoom Erlebniswelt Gelsenkirchen.

Herzlichen Glückwunsch zum Geburtstag !

Seit einigen Monaten ist CRE für mich der meistgehörte und auch interessanteste Podcast. Dies liegt einerseits sicherlich an der Themenauswahl, die im Fall der technologischen Themen häufig zu meiner Arbeit oder zu meinen Hobbies passt. Die gesellschaftlichen Themen überzeugen schon durch ihre Aktualität, gerade und insb. auch im Bereich der computer- und netzbezogenen Themen.

Was mir aber besonders an Chaosradio Express gefällt, ist der Stil. Es handelt sich um einen Interview-Podcast. Eingeleitet wird die Sendung durch ein Audio-Zitat (wo gräbt Tim die nur immer aus?), anschließend folgt ein CRE-Jingle. Danach gibt es nur noch den oder die Gesprächspartner und Tim als Moderator. In einem ungezwungenen und vor allem freien Gespräch wird über das Thema gesprochen. Dazu gehört sowohl die Einordnung des Themas als auch ein ggf. historischer Rückblick. Zwischendurch fasst Tim das Gespräch immer mal wieder zusammen, so dass ich bisher nie den Anschluss verloren habe (wobei das Thema Python und PyPy schon recht abstrakt war *g*). Irgendwann ist das Gespräch dann durch - das kann schon nach einer Stunde oder auch erst nach 2,5 Stunden der Fall sein - und der Podcast ist zu Ende. Alle weitere Infos und Links zur Sendung kann ich dann bei Bedarf auf der CRE-Webseite sowie im CRE-Wiki (oder in der Sendungsbeschreibung in meinem iPod) nachlesen. Feedback und Kommentare sind im CRE-Blog gerne gesehen.

Dieser Stil nutzt aus, dass ich als Hörer in einem Podcast jederzeit pausieren kann. Nur so sind so lange und ausführliche Gespräche möglich. Vergleichbare Formate sind im Regelfall wohl in keinem anderen Medium realisierbar. Im Radio wird mindestens für die Nachrichten unterbrochen oder eben für Musik, Werbung und andere Dinge. Im TV habe ich noch nie eine Sendung gesehen, in der mit nur einer Person ein 2,5-stündiges Gespräch geführt wurde - es gab oder gibt zwar Formate, die in diese Richtung gehen, aber nicht so weit und in der Regelmäßigkeit wie CRE es tut. Auch wenn manchen Hörern die Podcasts zu lang werden, ich finde gerade das gut. Podcasts bieten genau diese Möglichkeit und Freiheit, warum sollte dies nicht genutzt werden?

Andere Podcasts gehen da anders vor. Häufig erinnern mich diese an Radio- oder gar Nachrichten-Sendungen. Es gibt Jingles, es wird ein Themen-Überblick vorgelesen, es folgen die einzelnen Themen von Jingles getrennt, zwischendurch werden vielleicht noch Kurznachrichten verlesen (ein Beispiel dafür ist - zumindest in den Sendungen, in die ich mal reingehört habe - der Podcast Bel étage des Handelsblatts). Diesen Stil mag ich persönlich nicht. Ich benötige keine vorgelesenen Kurz-Nachrichten o.ä., sowas ist in einem (ggf. zum Podcast zugehörigen) Blog in entsprechenden Kurz-Artikeln besser aufgehoben.

Ein Podcast bietet also - im Gegensatz zu allen anderen Medien - die Möglichkeit auch lange Gespräche über ein einzelnes Thema oder ein Themengebiet zu präsentieren. Dank "Pause"-Funktion komme ich als Hörer damit gut zurecht. Daher: weiter so !

Dieser Artikel ist übrigens als Reaktion auf Tims Aufruf zum CRE-Kettenblogging entstanden. Wenn Du der Kette gefolgt bist, müsstest Du von Chaosradio Express - Nachfragen erlaubt kommen und könntest in Werbung für Chaosradio Express (CRE) weiterlesen.

QNAP hat diese Problematik auch erkannt und stellt nun einen offiziellen Recovery Mode bereit, der wichtige Flash-Bereiche per TFTP wiederherstellen kann. QNAP-Geräte, die vor 2009 ausgeliefert wurden, beinhalten diesen Recovery Mode noch nicht, er kann aber nachgerüstet werden. Im wesentlichen muss dafür der Bootloader ("U-Boot") ausgetauscht werden.

Das Update des Bootloaders für QNAP-Geräte mit Original-Firmware wird im QNAP-Wiki beschrieben. Für Systeme, die bereits Debian verwenden, hat Martin Michlmayr Anleitungen bereitgestellt.

Danke an Martin für die Info zum Recovery Mode sowie die ausführliche Anleitung. Bei mir hat das Update problemlos funktioniert.

Update 14.12.2008: Das Support-Dokument ist nun hier (Benutzer: csdread, Passwort: csdread) in dem Archiv "TS-209 Update Image.rar" zu finden und enthält mittlerweile die korrigierten Adressen. Die Adressen sind mit den von mir ermittelten Adressen weiter unten identisch.

Auf dem TS-109 (sowie auf den anderen TS-x09-Geräten) wird der Bootloader "Das U-Boot" verwendet. Die Dokumentation zu U-Boot befindet sich hier.

Vor einer Installation von Debian sollten unbedingt Bereiche des Flash-Speichers gesichert werden. Es handelt sich dabei um den Kernel (/dev/mtdblock1), initrd (/dev/mtdblock2) und die U-Boot-Konfiguration (/dev/mtdblock4). Kernel sowie initrd werden bei der Debian-Installation durch alternative Versionen ersetzt. Sollte die Installation von Debian nicht erfolgreich sein, dann müssen diese beiden Bereiche wiederhergestellt werden, um eine Rückkehr zur QNAP-Firmware zu ermöglichen. Diese beiden Bereiche müssen auch auf die Originalversionen zurückgesetzt werden, wenn nach einer erfolgreichen Installation von Debian eine Rückkehr zu QNAP gewünscht wird.

Unter Linux kann eine Sicherung so erfolgen:

cat /dev/mtdblock1 > mtd1
cat /dev/mtdblock2 > mtd2
cat /dev/mtdblock4 > mtd4

Die Wiederherstellung läuft dann analog so:

cat mtd1 > /dev/mtdblock1
cat mtd2 > /dev/mtdblock2
cat mtd4 > /dev/mtdblock4

Wenn das System nun aber nicht sauber startet und kein Zugriff auf eine Shell besteht, dann muss dieser Prozess über die serielle Konsole mit U-Boot erfolgen. Dazu muss zunächst ein passendes Adapterkabel erstellt werden, welches die Spannungspegel zwischen PC und NAS konvertiert. Schließlich wird noch ein Terminalprogramm benötigt, welches das Dateitransferprotokoll Kermit versteht. Unter Windows kann dafür z.B. HyperTerminal verwendet werden, unter Linux minicom in Verbindung mit gkermit. Weitere Informationen zum Adapterkabel und zur Konfiguration des Terminals befinden sich hier.

Wird die TS-109 mit angeschlossenem Terminal gestartet, erscheint wenige Augenblicke später der U-Boot Bootloader. Dieser wartet ein paar Sekunden auf einen Tastendruck, um die U-Boot Shell zu starten. Ohne Tastenbetätigung bootet das installierte System. Dies sollte man auf jeden Fall einmal bei Problemen machen, da der Bootprozess von Linux einige Hinweise auf mögliche Ursachen eines Problems liefert. Insb. Unterbrechungen, die zur manuellen Durchführung eines fsck auffordern, sind bei mir bisher beliebte Gründe dafür, dass mein System von alleine nicht starten will.

In der U-Boot Shell gibt es diverse Kommandos, mit denen man Informationen zum System erhält und die U-Boot-Konfiguration anzeigen sowie ändern kann. Interessant sind für uns die Kommandos protect, iminfo, loadb und cp.b.

Um nun die zuvor genannten Flash-Bereiche (kernel, initrd, ubootconfig) zu ändern, wird noch deren Adresse im Flash benötigt. Die Adressen findet man hier. Allerdings sind die Adressen dort relativ zur Startadresse des Flash (0xff000000) angegeben, so dass die Adressen im U-Boot so verwendet werden müssen:

Update 14.12.2008: /dev/mtdblock3 ergänzt

Um die Speicheradresse für den Kernel zu prüfen, kann das Kommando iminfo verwendet werden:

Marvell>> iminfo 0xff000000
## Checking Image at ff000000 ...
Image Name:   Debian kernel
Created:      2008-08-13  11:32:38 UTC
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1366044 Bytes =  1.3 MB
Load Address: 00008000
Entry Point:  00008000
Verifying Checksum ... OK

Wenn an der angegebenen Adresse ein gültiges Kernel-Image liegt, dann sollte die Ausgabe wie oben aussehen. Erscheint dort eine Fehlermeldung, dann ist entweder kein gültiges Image vorhanden oder die Adresse ist falsch.

Update 14.12.2008: Hier stand mal ein Hinweis, dass der Schreibschutz des Flash aufgehoben werden muss (wird auch im QNAP-Dokument so gemacht). Abgesehen von der U-Boot-Konfiguration (Speicherbereich ab 0xff760000) ist aber kein Bereich geschützt, der nachfolgende beschrieben werden würde. Die U-Boot-Konfiguration muss normalerweise nicht verändert werden, daher entfällt die Aufhebung des Schreibschutzes. Sollte dies doch erforderlich werden, steht dafür das Kommando protect on bzw. protect off zur Verfügung.

Anschließend wird die Datei mit den zu flashenden Daten per Kermit ins RAM übertragen (0x00400000 ist die RAM-Adresse, die als Ziel für solche Operationen im QNAP-Supportdokument vorgeschlagen wird):

loadb 0x00400000

Nach diesem Kommando erwartet U-Boot den Kermit-Transfer der Datei (z.B. mtd1). Abschließend müssen die Daten vom RAM ins Flash geschrieben werden, zuvor muss der Flash-Bereich jedoch gelöscht werden.

Um den Kernel (mtdblock1) zu schreiben, sind die folgenden Kommandos notwendig:

loadb 0x00400000

Im Terminalprogramm muss nun der Transfer der Datei (mtd1) per Kermit gestartet werden.

erase 0xff000000 0xff1fffff
cp.b 0x00400000 0xff000000 ${filesize}

Die Angabe ${filesize} wird durch die Umgebungsvariable filesize ersetzt, welche beim loadb-Kommando auf die Größe der übertragenden Datei gesetzt wurde.

Für initrd (mtdblock2) sind die Kommandos wie folgt:

loadb 0x00400000

Im Terminalprogramm muss nun der Transfer der Datei (mtd2) per Kermit gestartet werden.

erase 0xff200000 0xff5fffff
cp.b 0x00400000 0xff200000 ${filesize}

Nun kommt der spannende Moment, der über das weitere Schicksal des Systems entscheidet :

reset

Damit startet das System neu. Wenn man vorher keine Fehler gemacht hat, dann sollte einen Augenblick später wieder U-Boot mit der neuen Konfiguration starten. Bei Wiederherstellung der Original-Daten von QNAP kann nun eine Installation der Firmware mit dem QNAP-Finder erfolgen oder eine (erneute) Installation von Debian erfolgen.

Viel Glück...

Achja, alle hier gemachten Angaben (insb. zu Speicheradressen) wurden nach bestem Wissen und Gewissen zusammengestellt. Ich übernehme aber keine Gewährleistung dafür.

Update

loadb-Anweisungen für mtdblock1/2 vervollständigt. Danke an Ingo S. für den Hinweis.

Update 14.12.2008

Hinweis auf neues QNAP-Supportdokument, Speicheradresse für mtdblock3 hinzugefügt, protect off all entfernt

Aber der Reihe nach. Die Story beginnt damit, dass ich auf meiner NAS (Debian Sid auf einem ARM-Gerät) einen IPv6-Tunnel mit SixXS eingerichtet habe. Über SixXS habe ich nun auch ein /48-er IPv6-Präfix. Aus einem /64-er Subnetz soll ein DHCPv6-Server auf dem NAS nun Adressen an Clients verteilen und teilweise gleich noch ein Update des DNS-Servers vornehmen, so dass die Namensauflösung für die dynamisch zugewiesenen Adressen auch funktioniert.

Beim DHCPv6-Server habe ich mich für Dibbler entschieden. Leider funktioniert Dibbler hier nicht korrekt auf dem NAS. Der Server kann die von Vista gesendete Solicit-Message nicht interpretieren. Auch Wireshark markiert diese Message als "malformed packet". Ich habe mich dann an die Dibbler-User-Mailingliste gewandt. Der Entwickler von Dibbler, Tomasz Mrugalski, ist beim Durchsehen meiner tcpdumps über den Grund für die "malformed packets" gestolpert: Ein Bug im DHCPv6-Client von Windows Vista.

DHCPv6 [RFC3315] sieht vor, dass der Client den gewünschten FQDN oder einen Teil davon (z.B. einen bestimmten Hostname) anfordern kann [RFC4704]. Für solche Domain Namen wird ein ganz bestimmtes Format gefordert, Abschnitt 8 des zuvorgenannten RFC3315 verweist dazu auf Abschnitt 3.1 der Domain Name Specification [RFC1035].

Um die folgenden Ausführungen besser verstehen zu können, sollte zunächst beleuchtet werden, wie Domain Namen syntaktisch grundsätzlich aufgebaut sind. Dazu zitiere ich die entsprechende rekursive Definition aus dem RFC1035:

<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9

Damit sind noch nicht alle Regeln abgedeckt, aber die gründsätzliche Struktur passt. Wichtig ist hier insbesondere die Konstruktion (bzw. Bezeichnung), dass eine (Sub-)Domain aus einer Reihe von Labels besteht, die durch Punkte getrennt werden. Im oben genannten Abschnitt 3.1 des RFC1035 steht nun, wie Domain Namen in Nachrichten (auch in DHCPv6) kodiert werden sollen.

Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets.  Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less.

Ein Domain Name wird also in seine einzelnen Labels zerlegt. Die Kodierung erfolgt nun so, dass ein Label durch ein Byte, welches die Länge des Labels angibt, und dann die Bytes, die dem Label entsprechen (gemäß ASCII), kodiert wird. Jeder Domain Name endet mit dem null-Label der Root-Domain. Daher folgt zum Schluss ein Längen-Byte mit Wert Null.

Beispiel:

Der DHCPv6-Client von Windows Vista arbeitet hier aber offenbar fehlerhaft, denn Vista trägt im FQDN-Optionsfeld der Solicit- und Request-Message die Domain einfach nur als null-terminierten String ein.

Beispiel:

Diese Kodierung verstößt gegen RFC1035. Ein DHCPv6-Server (bzw. -Relay), der sich an den RFC hält, wird damit erhebliche Schwierigkeiten haben und wird diese Option (oder gar die ganze Message) nicht verarbeiten können.

Fatal wird die Angelegenheit jedoch bei der folgenden Betrachtung. Vista kodiert den Domain Name nicht nur bei den Solicit- und Request-Messages, die an den DHCPv6-Server gesendet werden, fehlerhaft, sondern interpretiert z.B. auch Domain Namen in den Advertise- und Reply-Messages, die vom DHCPv6-Server an den Client gesendet werden, falsch.

Über die Domain Search List kann der DHCPv6-Server dem Client mitteilen, welche Suchdomains verwendet werden sollen. Diese Suchdomains kann der Client an unvollständige Hostnamen dranhängen, um ihn zu vervollständigen.

Beispiel:

Einem Client wird die Suchdomain "cs.uni-dortmund.de" übermittelt. So sind nun alle Hosts, die sich in der Domain "cs.uni-dortmund.de" befinden, direkt über den Hostname ansprechbar. So wird bei Zugriff auf "www" automatisch auf "www.cs.uni-dortmund.de" zugegriffen.

Aber wie gesagt interpretiert Vista die Domain Search List falsch. Ein RFC-konform arbeitender Server kodiert die Domain Namen wie oben beschrieben. Vista setzt die Labels jedoch nicht zu einem einem einzelnen Domain Namen zusammen, sondern interpretiert jedes Label als eigene Domain - mit unangenehmen Folgen.

Beispiel:

Dem Client wird wieder die Suchdomain "cs.uni-dortmund.de" übermittelt. Vista interpretiert dies so, dass es die Suchdomains "cs", "uni-dortmund" und "de" verwenden soll. Bei Zugriff auf "www" wird nun versucht auf "www.cs", "www.uni-dortmund" und "www.de" zuzugreifen. Irgendetwas davon wird sicherlich existieren, aber es handelt sich dabei sicher nicht um "www.cs.uni-dortmund.de".

Nun, das soll erstmal dazu reichen. Wo bzw. wie kann man eigentlich einen Bug an Microsoft berichten?

Abschließend sei nochmal ausdrücklich darauf hingewiesen, dass Tomasz Mrugalski diesen Bug gefunden und mich darauf hingewiesen hat. Ich habe das ganze hier nur ausführlicher beschrieben und weiter "erforscht" (Domain Search List).

Die originale QNAP-Firmware ist ganz nett und bietet in einer relativ einfachen Konfigurationsoberfläche einige Möglichkeiten. Wer sich bisher nicht näher mit Linux beschäftigt hat, sollte unbedingt bei dieser Firmware bleiben.

Ich selbst bin aus zwei Gründen auf eine native Debian-Installation umgestiegen:

• Komfortable Installation und Aktualisierung von Softwarepaketen mit apt-get
• Unabhängigkeit von QNAP und proprietären QNAP-Erweiterungen

Gerade der zweite Punkt verdient besondere Beachtung. QNAP verwendet auf der Daten-Partition ein modifiziertes ext3, welches mit einem anderen Linux-System nicht gelesen werden kann. Sollte die TS-x09 also mal ausfallen, kann die Datenpartition nur mit einem passenden QNAP-Gerät (also z.B. einer anderen TS-x09) gelesen werden. Klar, natürlich sollten die Daten noch auf einem anderen Backup-Medium liegen, aber ich sehe nicht ein, dass meine Optionen bei einem Ausfall so unnötig eingeschränkt werden. Deinen einen sinnvollen Grund für diese ext3-Extension von QNAP kenne ich bisher nicht.

Debian Lenny unterstützt die Installation auf den QNAP-Geräten mittlerweile direkt per Debian-Installer. Martin Michlmayr beschreibt auf seiner Webseite den Installationsprozess.

Vorsicht: Vorhandene Daten auf der Daten-Partition der TS-x09 müssen vorher gesichert werden, da das QNAP-ext3 proprietäre Erweiterungen verwendet und mit einem normalen ext3 (wie es in Debian enthalten ist) nicht kompatibel ist.

Hinweis: Wenn auf der TS-x09 bereits eine andere Linux-Installation durchgeführt wurde, welche eine Änderung der U-Boot-Konfiguration (/dev/mtdblock4) erforderte, muss vor der Debian-Installation die originale Konfiguration wiederhergestellt werden, da ansonsten der Debian-Installer möglicherweise nicht booten kann.

Der prinzipielle Ablauf ist wie folgt (die Details stehen in der oben genannten Anleitung):

1. /dev/mtdblock* sichern und ggf. auf Originalzustand zurücksetzen
2. Debian-Installer ins Flash kopieren
3. Box neustarten
4. Verbindung mit dem Installer per SSH herstellen
5. Debian mit dem normalen Debian-Installer installieren

Der Debian-Installer kümmert sich selbst darum, dass bei Abschluss der Installation der Kernel ins Flash kopiert wird. Dies geschieht übrigens auch automatisch bei neuen Kernel-Versionen, die per apt-get geladen wurden.

Eine serielle Konsole ist bei diesem Vorgehen nicht erforderlich. Es kann aber bei Boot-Problemen der einzige Weg sein, um die Box wiederherzustellen. Daher sollte man sich rechtzeitig um die benötigten Teile kümmern. Für den Zugriff auf die serielle Konsole werden ein Pegelwandler (z.B. MAX3232) und ein paar Kondensatoren benötigt (Infos).

Über die serielle Konsole erhält man Zugriff auf U-Boot und kann in den Debian-Bootprozess eingreifen. Mit Hilfe von U-Boot kann der Flash überprüft und neu beschrieben werden. Eine Anleitung dazu hat QNAP auf seinem FTP-Server veröffentlicht. Leider ist diese Anleitung bezüglich der Flash-Speicheradressen fehlerhaft. Die dort genannen Adressen sollten daher keinesfalls verwendet werden, ich habe mir so eine TS-109 zerschossen, indem ich U-Boot überschrieben habe. Die korrekten Adressen, die ich selbst bereits erfolgreich verwendet habe, werde ich in einem weiteren Blog-Artikel beschreiben.