Category: Geeks & Co.

Nachdem „Flüchtling” Christian sich des Galaxy Tabs angenommen hat und Kollege Stephen mir eröffnete, er hätte ein „Dual-Core Cortex-A8 10″-Android-Tablet mit kapazitativem Touchscreen” für unter 200,– EUR (hmm, könnten bei ihm auch Pfund sein …) via eBay sich jetzt bestellt (ETA in gut ‘ner Woche), habe ich dann auch mal gesucht — und zugeschlagen:

Eken M002 Android Tablet 7 Zoll Touchscr. / epad / apad Item# 180584318675	€59,00 EUR	1	€59,00 EUR
Shipping and handling			€29,00 EUR
Total			€88,00 EUR

Die Hardware saugt mal prinzipiell. resistiver 800x480er Touchscreen ist nicht wirklich state-of-the-iPad-age. Andererseits, »RockChip2808 600MHz, Chpiset: ARM600MHZ, DSP550MHZ« sollte so schlimm nicht sein, WLAN, Cam und sogar 10/100-Ethernet (wohl so’n lustiger USB-Adapter) oben drauf für 60,– EUR (leider zzgl. 50% Shipping :(), ganz für die Katz’ kann das eigentlich nicht sein, selbst mit nur Android 1.6.
Und wenn’s nicht als Skype-Gegenstelle für die Familiy in GT reicht, ist’s ‘n günstiger Einstieg ins Android-Hacking, denke ich — next stop dann eines der 1024x600er Android 2.x-Tablets ;) Bei dem Preis einer einfachen Fahrt GT-B (rd. 400km, rd. 10 l/100km, rd. 1,25/l Diesel) jedenfalls durchaus überlegenswert — mein simples USB-LCD für VDR war, bei 128x64er Auflösung, nicht viel günstiger (45,–, allerdings inkl. Versand) …

¡Mierda!
After upgrading the firmware, my N900 doesn’t auto-tag photos with the current GPS coordinates anymore; may be a Layer8 problem, haven’t had time yet to investigate.
To circumvent this, I enabled the history on Google Latitude, the big G now keeps the logs for me to see — and to export into .kml. I don’t know much about KML besides that’s another chatty way to store data instead of good old, sed-able, CSV … For batch-geotagging files I use gpscorrelate(-gui), which needs .gpx — fortunately, gpsbabel promses to convert e. g. .kml into .gpx. And it does, but regardless of the options (none, -t, -r), it leaves out the timestamp a waypoint was taken at; and without timestamps, gpscorrelate can’t correlate coordinates to pictures, thus it just gives an error trying to read the .klm converted to .gpx.
So, before making a 5-minute-issue a whole-day-coding event: anyone knows either another Linux application that can (batch-) tag photos with GPS coordinates from a (Google Latitude-) KML file or a way to convert the (Google Latitude-) KML to gpscorrelate-usable GPX format?

Es wäre ja auch zu einfach gewesen; ich habe meinen GoFlex Net nach Jeff Doozans Methode mit einem neuen uBoot versorgt, da dort nun auch der GoFlex Net genannt wird …

Kurzfassung: Satz mit X. Ohne (USB-) /dev/sda1 mit einem passenden /boot/uImage tut sich mal gar nix, das Doozansche uBoot versucht zwar, den gesicherten orginalen uBoot nachzulagen, an dieser Stelle allerdings hängt sich dann das System auf :( Wer wie ich darüber stolpert: die Belegung der

seriellen Schnittstelle ist im Thread auf mikrocontroller.net hinterlegt; analog Dockstar und auch auf Pin-Header rausgeführt, sehr dankenswert ;)
Damit war ich zumindest schon mal in der Lage zu erkennen, was schief läuft und, mittels eines für den Dockstar präparierten USB-Sticks, meinen GoFlex Net auch wieder zu booten. Für’s debricking ist das ja die halbe Miete, steht dann doch wieder eine Linux-Umgebung zum Bearbeiten des Kistchens zur Verfügung …

Unbricking …

new-dockstar:~# ./fw_setenv arcNumber 3089, wie von Jeff vorgeschlagen ergibt mit meinem Dockstar-Kernel erwartungsgemäß:

Error: unrecognized/unsupported machine ID (r1 = 0x00000c11).
Available machine support:
ID (hex) NAME
00000690 Marvell DB-88F6281-BP Development Board
00000691 Marvell RD-88F6192-NAS Development Board
00000692 Marvell RD-88F6281 Reference Board
0000078c Marvell 88F6281 GTW GE Board
00000831 Seagate DockStar Board
0000085b QNAP TS-119/TS-219
00000915 Marvell OpenRD Base Board
Please check your kernel config and/or bootloader. 

Tcha. Also doch den Compiler anwerfen? Darauf läuft’s hinaus und da ich ja DVB-Geraffel auf dem GoFlex Net laufen lassen will, wird das eine länger dauernde Aktion werden :( Nun ja, ich werde nun also erst einmal dem Pluggapps-Kochbuch folgen, um wieder einen Kernel mit SATA-Support zu bekommen …

Ich gebe zu, etwas in den Popo beiße ich mir ja schon, daß ich bei 25 bis 31 EUR/Dockstar nicht nochmal nachgeordert habe; denn zu dem Preis war der Dockstar genau die eierlegende Plugconputer-Kiste, die, wie ich mir seinerzeit erhoffte, der SheevaPlug werden könnte. Mittlerweile hat der Preis allerdings die Werte von vor einem halben Jahr überschritten und den USB-only Dockstar und seinen 2x SATA-Cousin GoFlex Net trennen nur noch rund 10 EUR …
Wozu ich meine Dockstars einsetze, habe ich ja schon mal aufgelistet; neuester Zugang in der »PlugComputer«-Kategorie ist der

GoFlex Net, eine weitere Abwandlung des SheevaPlug-Designs, diesmal ohne internen USB-Hub, weiterhin mit 1x GBit-Ethernet und, neu, zwei »invertierten« SATA-Anschlüssen, auf die man 2,5″-SATA-Platten direkt draufstöpseln kann (wackelige Angelegenheit; gedacht ist das für Seagates 2,5″-GoFlex-Platten, die ein schützendes Gehäuse drumherum haben).
Meine Kabelage für »invers-SATA-auf-eSATA« ist ja leider in Berlin gestrandet, sodaß ich jetzt erst einmal mit internen, d. h. nakten, 2,5″-SATA-Platten arbeiten werde. Der GoFlex Net wird meinen Dockstar als VDR-Basis zumindest temporär ersetzen, um zu sehen, ob 2 HD-Tuner am USB problemlos(er) laufen, wenn die Aufzeichnung über SATA statt ebenfalls USB weggeschrieben wird.

Danke, Hermes …

Empfänger Sendungs-ID Datum der Paketschein-Erfassung Datum der letzten Bearbeitung Letzter Sendungsstatus 13355 BERLIN 77900………. 27.10.2010 29.10.2010 Die Sendung wurde zugestellt Datum Uhrzeit Sendungshistorie 29.10.2010 19:46:06 Die Sendung wurde zugestellt 29.10.2010 09:42:21 Die Sendung befindet sich heute in der Zustellung. 29.10.2010 07:07:37 Die Sendung befindet sich heute in der Zustellung. 29.10.2010 04:28:12 Die Sendung ist an der zuständigen Hermes Niederlassung Berlin-Ost eingetroffen und wird für die Zustellung sortiert. 28.10.2010 14:38:51 Die Sendung wurde sortiert und befindet sich auf dem Weg in die zuständige Hermes Niederlassung. 27.10.2010 19:52:38 Die Sendung wurde angekündigt.

Tja, doll. Irgendein Honk klingelte auch kurz vor 20 Uhr, ich war grade nach Hause gekommen, aber da er/sie/es auch bei Nachbars klingelte, war die Gegensprechanlage stumm, ergo habe ich den Öffner nicht betätigt — hatte sich offensichtlich verklingelt. Und in den Briefkasten habe ich natürlich auch nicht mehr geguckt, wer rechnet denn abends um Acht noch mit Post?
Tja, so liegen nun meine genderchangenden SATA-Adapter in meinem Berliner Briefkasten, während die Seagate GoFlex Net nun in GT ist — ergo erst einmal kein Test, ob sich über Adapterkabel eSATA-Geräte zuverlässig anschließen lassen :(

Ach wie nett, DeNIC kassiert für ß-Domains nun doppelt? 2008 habe ich mir meine eigene Zwei-Zeichen-DE-Domain zugelegt — über IDN, lange bevor das DeNIC diese Möglichkeit – nach einem verlorenen Rechtsstreit – auf US-ASCII-Basis schuf.
Und anders als bei den berühmt-berüchtigten Beispielen db.de und ix.de, die in den »Wirrungen« der Anfänge der deutschen TLD registriert wurden und auch nach den willkürlichen Einschränkungen des DeNICs den Namensraum betreffend nicht kassiert wurden, so gibt es für mein æß.de (xn--ss-0ia.de) keinen Bestandsschutz. Um weiterhin unter der Klarschriftadresse http://æß.de erreichbar zu sein, muß ich nun zusätzlich diese Domain nochmals registrieren (und damit für zwei IDN-Domains – æß.de in der alten Übersetzung nach æss.de => xn--ss-0ia.de sowie æß.de in der neuen, IDNAbis, Übersetzung, für die ich leider noch kein Tool gefunden habe; Verisign z. B. macht da auch heute am 27.10.2010 noch xn--ss-0ia.de draus – zahlen). Und eine Aufgabe der »alten« Übersetzung ist nicht ratsam, denn, wie DeNIC ausführt, der neue Standard ist inkompatibel zum bisherigen:

Die fehlende Rückwärtskompatibilität des neuen IDN-Standards mit dem vorherigen Standard lässt– solange nicht alle Browser und Anwendungen ihn unterstützen – keine eindeutige Adressierung von Domains mit den Zeichen(ketten) “ss“ oder “ß“ zu. […]
Änderungen infolge des neuen Standards
Entsprechend dem bisher geltenden IDN-Protokoll wurde das „ß“ in ein ASCII-kompatibles Format konvertiert, damit es vom Domain Name System (DNS) verarbeitet und bei der Registrierung von Domains verwendet werden konnte. Hat ein Internetnutzer bisher eine Domain mit „ß“ in seinen Browser eingegeben, wandelte dieser automatisch in „ss“ um, d.h. aus „straße.de“ wurde automatisch „strasse.de“. Ob diese Umwandlung in der Adresszeile für den Nutzer ersichtlich war, richtete sich nach dem verwendeten Browsertyp. Der neue IDN-Standard sieht dagegen vor, das „ß“ als selbstständiges Zeichen zu führen, so dass eine Umwandlung von „ß“ in „ss“ nicht mehr stattfindet. Dies wird konform zum neuen Standard vom DNS so realisiert. Damit sind “straße.de” und “strasse.de” nunmehr zwei unterschiedliche Domains. Das bedeutet, dass Anwendungen, die auf dem alten IDN-Standard beruhen, nicht mehr kompatibel mit dem neu eingesetzten Standard sind. Man spricht hier von fehlender Rückwärtskompatibilität.
Auswirkungen der fehlenden Rückwärtskompatibilität
Aus Nutzersicht kann diese Umstellung in einer Übergangszeit insofern zu unerwarteten Ergebnissen führen, als aktuelle Webbrowser und E-Mail-Clients zumeist noch auf dem alten IDN-Standard basieren. Je nach eingesetzter Software gelangen Nutzer bei der Eingabe von „ß“ innerhalb einer Domain demnach zu unterschiedlichen existierenden Domains. Während mit dem neuen Standard konforme Browserversionen den Nutzern die entsprechend ihrer Eingabe korrekte Seite anzeigen, werden die Nutzer älterer Versionen nach wie vor grundsätzlich auf eine Domain mit „ss“ geführt. Diese muss jedoch – unabhängig davon, ob sie auf denselben Inhaber registriert ist – nicht notwendigerweise identisch mit der angefragten „ß“-Domain sein. Wann die Browserhersteller die Neuerungen des DNS-Protokolls ebenfalls mit Updates unterstützen werden, liegt nicht im Einflussbereich von DENIC. Solange diese technische Unwägbarkeit fortbesteht, empfiehlt DENIC Interessenten an einer Domain mit dem Bestandteil „ß“ daher, diesen Umstand bei der Nutzung der Domain zu berücksichtigen.

 
Im Klartext heißt dies also, daß DeNIC sich diesmal ganz offenherzig einem neuen Standard gegenüber gibt (zu zweibuchstabigen Domains mußte DeNIC erst geklagt werden, groß anders war’s Ende der 80er nicht mit Firmendomains, die eine führende Ziffer hatten. Schon damals stand DeNIC im Widerspruch zu geltenden RFCs, die explizit sowas wie 3jean.de seit Jahren ermöglichten … nicht anders war es bis 2009 mit den zweibuchstabigen de-Domains; meine 42.to war schon seit Ende der 80er Jahre technisch problemlos konnektiert, entgegen den DeNIC-»Vorbehalten«) und einen bestehenden (im Gegensatz zum vormals nur behaupteten, aber faktisch nicht vorhandenen) Bruch gerne in Kauf nimmt, um die Domaininhaber ein zweites Mal abzukassieren.
Ein korrektes Vorgehen wäre gewesen, jeder SS-Domain die IDNAbis-Domain mit Eszett als Klon hinzuzustellen, kostenlos, versteht sich — die Kostenlosigkeit könnte man auf max. 10 Jahre ja begrenzen, wobei der Domaininhaber ja nichts für diesen technischen Unsinn kann, den sich andere ausgedacht haben. Der grundlegende Fehler war, das Eszett initial nicht zuzulassen und in ss zwangszuübersetzen; durch die – unnötige – Änderung dieser Entscheidung kommt es jetzt zu einem richtigen Kuddelmuddel. Und das DeNIC glänzt in seiner Paradedisziplin, dem Abkassieren, Stichwort DeNICdirekt …
Ach so: müßig eigentlich hinzuzufügen, daß keiner meiner beiden Registrare – joker.com und regfish.de – mir heute, am 27.10.2010, Tag 1 nach der DeNIC-Verlautbarung, æß.de in der IDNAbis-Version registrieren kann; beide zeigen mir an, daß æß.de bzw. genauer »Domain: æss.de, Domain-Ace: xn--ss-0ia.de« mir gehören … Gründliche Vorbereitung solcher »Staatsstreiche« ist etwas, was man dem DeNIC in der Vergangenheit nicht vorwerfen konnte; es scheint sich nichts geändert zu haben :( Leider mache ich mit æß.de keinen kommerziellen Umsatz, sodaß nicht einmal ein Schadensersatz in Frage kommt; und 12 EUR/Jahr (regfish) bzw. 6,30 EUR/Jahr (joker) lohnen eigentlich nicht einmal das Telefonat mit der Rechtsschutzversicherung … aber grade deshalb sollte man DeNIC hier Paroli bieten, IMHO.

Tja, der eine oder andere mag sich fragen, was eigentlich aus meinem GuruPlug geworden ist, was ich in den fünf Monaten des Besitzes mit ihm gemacht habe, nach all’ den Beiträgen zu insbesondere den Dockstars …
… und die Antwot lautet: nix. Das Ding ist ein Staubfänger, da sich der Distributor NewIT (.co.uk) nach wie vor auf Nachfrage ausschweigt, wann ich denn nun endlich mein »upgrade kit« bekommen kann, welches aus dem lautlosen »Heizkörper« (siehe auch Wills Kommentar hier) einen lärmenden macht :(
Sprich: der GuruPlug war für mich ein Griff ins Klo, wie schon im Juni angedeutet. Insofern, da das grundsätzliche Problem (die heiß werdende CPU) ja auch SheevaPlugs (bei mir: 2 von 2 Netzteilen starben innerhalb <6 Monaten; für den Ersatz des zweiten verlangt der Distributor NewIT mittlerweile Geld, obwohl unbestreitbar es extrem naheliegend ist, daß die hochgegangenen Elkos der enormen Hitzelast im Sheeva-Gehäuse geschuldet sind) betrifft sowie die die darauf aufbauenden Seagate-Geräte Dockstar und insbesondere GoFlex Net sowie GoFlex Home, welche jeweils über SATA-Ports verfügen, bin ich etwas gespannt, wie sich die Rücklaufquote bei grade den GoFlex-Kisten entwicklen wird. Mein(e) Dockstar(s) werden zwar warm, insbesondere, wenn sie 20 MByte/sec zwischen USB und Ethernet zu jonglieren haben, aber zeigen bislang keine Auffälligkeiten. Der SheevaPlug mit noch internem (Ersatz-) Netzteil (Plug Nummer 1 hat ja ein externes Netzteil seit Juni) z. B. verliert sporadisch, leider häufig, und unmotiviert seine USB-Geräte — ein Verhalten, was die (wg. oftmals /dev/sda1 als Root-FS auf USB besonders angewiesenen) Dockstars, toi, toi, toi, bislang nicht aufweisen.
Schade. Aber zum echten »Plugcomputer« ist es offensichtlich noch ein weiter Weg; ins Steckernetzteil jedenfalls gehört das Heizelement, die Marvell-Sheeva-CPU, derzeit offensichtlich nicht :(

… wird ein Kaptiel darin sicher sich um IT im allgemeinen, Linux im besonderen und meine Erfahrungen mit dem ganzen Schrott drehen. Schreiben würde ich sie auf einen altmodischen Schreibmaschine, so mit ohne Kugelkopf und Stromanschluß, just in case.
Das »Schöne« an diesem Gebiet ist nämlich, daß es nie langweilig wird; meine letzten »Herausforderungen« habe ich gemeistert, in dem ich nun alles über eth0 des Dockstars abwickle. Hierzu bekam der Port des Dockstars am GS108T im Keller auch VLAN 1, das Standard-VLAN des Switches, ‘markiert’ zugeführt (alle anderen Ports aller meiner 3 GS108T haben es als Basis-VLAN, unmarkiert), die Konfiguration des LANs wanderte von eth0 nach eth0.1 und eth0 hat nun eine 169.254er Adresse, um das IF hochzubekommen. (Wahrscheinlich geht das in Debian auch anders, aber ich war ehrlich gesagt zu faul, danach zu suchen.)
Soweit, so genial ;) Leider triggert diese Konfiguration offensichtlich einen neuen Bug in der rottigen Firmware des als unzuverlässig und fehlerhaft verrufenen Netgear GS108T: Nachdem bislang der Switch im OG gerne mal seine Managementfähigkeit abschaltete und komplett stumm wurde (HTTP-Requests liefen in den Timeout), hat nun der GS108T im UG, an dem einige Dockstars als Fileserver sowie, wie gesagt, der Dockstar-als-Router hängen, eine neue Marotte entwickelt: dieser schaltet seine Managementoberfläche nun komplett ab, sodaß die HTTP-Pakete wg. »no route to host« verenden.
Einfach großartig. Ich bin nicht wirklich überrascht; seit der besagten Umstellung läuft auch Multicast (T-Entertain) nicht mehr, genauer gesagt versagt das IGMP-Snooping des/der GT108T und der Verkehr wird stumpf an alle Ports geschickt (Broad- statt Multicast). Sobald ich den igmpproxy auf dem Dockstar starte, flooden mir alle GT108T nach wenigen Sekunden das gewählte TV-Programm an alle Ports — die der WLAN-APs eingeschlossen, was dann das WLAN dicht macht. Ach so, genau um das zu vermeiden, hatte ich mir die 3 GS108T gekauft …
Ich werde also nun den ersten Netgear GT108T wegen erwiesener Untauglichkeit und auch in Firmware 3.0.4.10 weiterhin vorhandenen Fehlern durch einen Cisco SLM2008 ersetzen; auch dieses kleine Wunderwerk der Technik soll des IGMP-Snoopings fähig sein, vielliecht schützt die Cisco-Box ja die beiden alzheimernden Netgears endlich wieder vor dem bösen Multicast … Und vielleicht setzt Cisco ja ein fehlerfreiers Switch-Kontroll-OS ein — die Hoffnung stirbt zuletzt ;)

Nach den Versionen 1 (»Holler«-Ansatz mit USB-fähigem neueren uBoot in mtd3) und 2 (UBIFS-Root in mtd3, vom Dockstar-uBoot gestartet) möchte ich heute eine dritte Variante vorstellen, wie man seinen Dockstar »um Debian erweitern« kann.
Anstatt mit mtd3, dem freien Flashbereich der Dockstars, rumzuspielen, möchte ich heute, nachdem auch die JTAG-Belegung bekannt ist und das Risiko eines dauerhaften Bricks somit geringer, das »Übel« an der Wurzel anpacken: der kastrierte leistungsarme uBoot-Loader des Dockstars.
Jeff Doozan hat es dankenswerterweise verskriptet, sodaß es eigentlich nur der Dreisprung Dockstar auspacken, das ersten Mal booten und Jeffs uBoot installieren sein sollte …

-bash-3.2# cd /tmp
-bash-3.2# wget http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh
Connecting to jeff.doozan.com (69.163.187.226:80)
install_uboot_mtd0.s 100% |*******************************| 15859 00:00:00 ETA
-bash-3.2# chmod +x install_uboot_mtd0.sh
-bash-3.2# ./install_uboot_mtd0.sh
!!!!!! DANGER DANGER DANGER DANGER DANGER DANGER !!!!!!
If you lose power to your device while running this script,
it could be left in an unusable state.
This script will replace the bootloader on /dev/mtd0.
This installer will only work on a Seagate Dockstar or Pogoplug Pink.
Do not run this installer on any other device.
By typing ok, you agree to assume all liabilities and risks
associated with running this installer.
If you agree, type 'ok' and press ENTER to continue: ok
DISABLE POGOPLUG SERVICES
The pogoplug service includes an auto-update feature which could
be used to cripple or disable your device. It is recommended
that you disable this service.
NOTE: The pogoplug service is proprietary software
created by Cloud Engines. It is not available for use
in other distributions and will not be available in
your new linux installation even if you choose not to disable it.
Would you like to disable the pogoplug services? [Y/n] y
Applying fixes to the pogoplug environment...
Disabling the pogoplug service...
Done fixing pogoplug environment.
# checking for /uboot-original-mtd0.kwb...
# Installing /uboot-original-mtd0.kwb...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot-original-mtd0. 100% |*******************************| 49 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot-original-mtd0. 100% |*******************************| 512k 00:00:00 ETA
# Successfully installed /uboot-original-mtd0.kwb.
# checking for /usr/sbin/blparam...
# Installing /usr/sbin/blparam...
Connecting to jeff.doozan.com (69.163.187.226:80)
blparam.md5 100% |*******************************| 42 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
blparam 100% |*******************************| 14168 --:--:-- ETA
# Successfully installed /usr/sbin/blparam.
# checking for /usr/sbin/nandwrite...
# Installing /usr/sbin/nandwrite...
Connecting to jeff.doozan.com (69.163.187.226:80)
nandwrite.md5 100% |*******************************| 44 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
nandwrite 100% |*******************************| 11500 --:--:-- ETA
# Successfully installed /usr/sbin/nandwrite.
# checking for /usr/sbin/nanddump...
# Installing /usr/sbin/nanddump...
Connecting to jeff.doozan.com (69.163.187.226:80)
nanddump.md5 100% |*******************************| 43 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
nanddump 100% |*******************************| 21286 00:00:00 ETA
# Successfully installed /usr/sbin/nanddump.
# checking for /usr/sbin/flash_erase...
# Installing /usr/sbin/flash_erase...
Connecting to jeff.doozan.com (69.163.187.226:80)
flash_erase.md5 100% |*******************************| 46 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
flash_erase 100% |*******************************| 12819 00:00:00 ETA
# Successfully installed /usr/sbin/flash_erase.
# checking for /usr/sbin/fw_printenv...
# Installing /usr/sbin/fw_printenv...
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_printenv.md5 100% |*******************************| 46 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_printenv 100% |*******************************| 652k 00:00:00 ETA
# Successfully installed /usr/sbin/fw_printenv.
# checking for /etc/fw_env.config...
# Installing /etc/fw_env.config...
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_env.config.md5 100% |*******************************| 48 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_env.config 100% |*******************************| 329 --:--:-- ETA
# Successfully installed /etc/fw_env.config.
# Attempting to auto-detect your device...Dockstar detected
# Installing uBoot
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb.md5 100% |*******************************| 49 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb 100% |*******************************| 512k 00:00:00 ETA
Erase Total 4 Units
Performing Flash Erase of length 131072 at offset 0x60000 done
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
## Verifying new uBoot...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb.md5 100% |*******************************| 49 --:--:-- ETA
# Verified successfully!
# Installing uBoot environment
Warning: Bad CRC, using default environment
## Error: "ethaddr" not defined
Warning: Bad CRC, using default environment
## Error: "rescue_installed" not defined
Warning: Bad CRC, using default environment
## Error: "bootcmd_rescue" not defined
Warning: Bad CRC, using default environment
## Error: "rescue_custom_params" not defined
Warning: Bad CRC, using default environment
## Error: "usb_custom_params" not defined
Warning: Bad CRC, using default environment
## Error: "ubifs_custom_params" not defined
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.environment.md 100% |*******************************| 52 --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.environment 100% |*******************************| 128k 00:00:00 ETA
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000 done
Writing data to block 6 at offset 0xc0000
# Verifying uBoot environment
ECC failed: 6
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000c0000 and ending at 0x000e0000...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.environment.md 100% |*******************************| 52 --:--:-- ETA
# uBoot installation has completed successfully.

… wobei es erst einmal nach »Danger, Will Robinson!« aussieht. Aber die Warnungen sind wohl dem ersten Lauf und dem noch leeren Environment des neuen uBoot geschuldet, denn gesetzt wurde augenscheinlich alles:

-bash-3.2# /usr/sbin/fw_printenv
ethact=egiga0
bootdelay=3
baudrate=115200
arcNumber=2097
mainlineLinux=yes
console=ttyS0,115200
led_init=green blinking
led_exit=green off
led_error=orange blinking
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
mtdids=nand0=orion_nand
partition=nand0,2
stdin=serial
stdout=serial
stderr=serial
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_list=1 2 3 4
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_init=run usb_scan
usb_device=0:1
usb_root=/dev/sda1
usb_rootfstype=ext2
usb_rootdelay=10
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset
ethaddr=00:10:75:XX:XX:XX

Also, Mut zur Lücke und »halt« getippt. Nach ein paar Sekunden Dockstar stromlos machen, USB-Stick oder -Platte (mit /boot/uImage in Partition 1) angeschlossen und dem Affen Zucker, also dem Dockstar Energie, gegeben …
(Als Debian-Filesystem habe ich mein NFS-Root meiner besherigen Variante auf ‘nen Stick kopiert und dann meinen aktuellen 2.6.32.2er Kernel (mit den Hollerschen Dockstar-Patches) nach /boot/uImage sowie die passende Module nach /lib/modules/2.6.32.2 auf dem USB-Medium geschoben.)
… und in der Tat, der so behandelte Dockstar bootet klaglos /boot/uImage von einem ext3-formattierten USB-Stick (1 Partition) — und auch ein »shutdown -r now« wird klaglos ausgeführt, hier hing die uBoot-läd-uBoot-lädt-von-USB-Lösung ja leider. Kühl. Wenn es jetzt noch haltbare USB-Sticks gäbe …

(Insbesondere) Linux ist immer wieder für eine Überraschung gut. Jaja, ich hätte es mir denken können, daß dieses nicht ganz standardkonforme Verhalten bei solcher Hardware Probleme macht; aber, hey, warum eigentlich? Wegen 4 Bytes?
Worum geht es? Wie schon geschrieben habe ich, mehr so notgedrungen, einen meiner Dockstars zum T-VDSL-Anbindungsrouter umfunktioniert — und das zweite Ethernet via USB-Ethernet-Adapter realisiert. Soweit, so erfolgreich.
Allerdings liegt die Geschwindigkeit über den OpenVPN-Tunnel ungleich höher als über die T-VDSL-IP direkt; http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.7.tar.bz2 per OpenVPN-Tunnel:

100%[======================================>] 69.255.636 946K/s in 68s

Im Vergleich dazu, direkt über die T-VDSL-IP:

100%[======================================>] 69,255,636 366K/s in 3m 30s

Schon ein Unterschied, und der liegt, wie auch im Netz nachzulesen, an:

Oct 19 12:00:10 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:10 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:10 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:12 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:14 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:14 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:21 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:22 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:22 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:25 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:25 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:26 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:26 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Oct 19 12:00:28 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518

Hintergrund: die Deutsche Telekom nutzt bei T-Entertain-Anschlüssen (mittlerweile IIRC auch bei ADSL2+ (»16plus«), nicht nur an VDSL-Anschlüssen wie meinem) ein Setup mit zwei VLANs, die aus dem xDSL-Modem kommen: VLAN7 für den Internet-Verkehr, VLAN8 für das Entertain-Produkt inkl. Multicasting für Live-TV.
Mit anderen Worten, aus dem Ethernet-Interface meines VDSL-Modems Speedport 300 HS »fallen« getaggte Ethernetframes raus, die statt 1518 max. 1522 Bytes groß sind. Das ist für meinen Switch kein Problem, das ist für Linux kein grundsätzliches Problem — aber leider unterstützt entweder die Hardware sowohl des »asix«-getriebenen GBit/sec-Adapters von Belkin noch die MosChip-MCS7830-basierten Logilink-Adapter oder deren (Linux-?) Treiber keine Ethernetframes mit >1518 Bytes. Die Folge sind Paketverluste, der asix-Treiber loggt diese zumindest, und damit einhergehend massiver Durchsatzeinbruch.
Evtl. läßt sich das Problem mittels einer kleineren MTU umschiffen, alternativ böte es sich an, den Switch das Tagging erledigen zu lassen und die VLANs 7 und 8 auf getrennten Ports ungetagged dem Dockstar über dann zwei USB-Ethernet-Adapter zuzuführen. Oder alles auf einen Port, ggf. das Heimnetz in ein VLAN verfrachten?
Hrmpft. All das wäre unnötig, wäre der GuruPlug der versprochene Rechner statt eines Brandbeschleunigers :(