blogdoch reloaded

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 :(

/var/log/messages.4.gz:Sep 24 11:40:09 death kernel: [3113010.597097] motion[17123]: segfault at 0 ip (null) sp ae42a31c error 4 in libpq.so.5.2[110000+21000]
/var/log/messages.4.gz:Sep 24 11:48:29 death kernel: [3113510.427985] motion[17780]: segfault at 0 ip (null) sp ae31e31c error 4 in libavformat.so.52.31.0[110000+a8000]
/var/log/messages.4.gz:Sep 24 11:50:23 death kernel: [3113624.294781] motion[17921]: segfault at 0 ip (null) sp ae6ba31c error 4 in libpq.so.5.2[110000+21000]
/var/log/messages.4.gz:Sep 24 11:51:42 death kernel: [3113703.785569] motion[18012]: segfault at 1008 ip 0805e141 sp aaaff270 error 4 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 11:54:36 death kernel: [3113877.781585] motion[18217]: segfault at 1008 ip 0805e141 sp ae71e280 error 4 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:02:09 death kernel: [3114330.399101] motion[18943]: segfault at 0 ip 0056a136 sp b70c5fe8 error 4 in libc-2.10.1.so[4f5000+13e000]
/var/log/messages.4.gz:Sep 24 12:11:05 death kernel: [3114866.151856] motion[19991]: segfault at 27b16a09 ip 0806008d sp ad2fdfc0 error 6 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:17:14 death kernel: [3115235.402812] motion[20611]: segfault at 4181f4d9 ip 0806008d sp b700bfc0 error 6 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:31:20 death kernel: [3116081.925025] motion[22230]: segfault at 95afb350 ip 08060088 sp b6f08fc0 error 6 in motion[8048000+32000]
/var/log/messages.4.gz:Sep 24 12:54:36 death kernel: [3117478.032021] motion[24479]: segfault at 2 ip 00000002 sp b5efddac error 4 in libavutil.so.49.15.0[110000+c000]
/var/log/messages.4.gz:Sep 24 13:41:07 death kernel: [3120268.384388] motion[27775]: segfault at 54256e5c ip 004be136 sp b7779fe8 error 4 in libc-2.10.1.so[449000+13e000]

WTF? SEGFAULTs klingen irgendwie gar nicht gut, aber irgendwie mag ich nicht an karpotten Speicher zu glauben … Ganz neu ist es nicht, aber aktuell ist es extrem:
/var/log/messages: 1465
/var/log/messages.1: 1
/var/log/messages.2.gz: 0
/var/log/messages.3.gz: 1
/var/log/messages.4.gz: 49
Wobei das Gros der Abbrüche motion (eine Webcam-Überwachungssoftware) betrifft, seltener synergys (Steuerung mehrere Computer mitteles 1x Keyboard/Maus), nie bislang, soweit ich gesehen habe, VMware-Prozesse oder Firefox … Irgendjemand ‘ne Idee, was das sein könnte (OS ist Ubuntu Kotzender Koala)?

Im Grunde bin ich mit der Wahl meiner Switche – Netgear GS108T, 8x 10/100/1000 – zufrieden, ich habe seinerzeit auch für meine ehemalige Realschule, an der ich nebenbei »ein bißchen Netz gebastelt« habe, diese als Backbone-Switches anschaffen lassen. Mit rd. 100 EUR/Gerät und der grundlegenden Managementfähigkeit finde ich sie recht günstig — zumal, wenn man von den Preisen der IGMP-fähigen Alternativen ausgeht.
Leider funktioniert aber grade dieses IGMP-Snooping nicht reibungslos, zudem hängt sich die Managementoberfläche einer meiner 3 Netgear GS108T nach relativ kurzer Laufzeit komplett auf, der Webserver reagiert nicht mehr, ohne Power-Cycle ist der Switch nicht mehr administrierbar :-(
Aber auch wenn, lt. Weboberfläche allles im Lot scheint, etwas liegt im Argen. Zwar zeigen die Switche brav an, daß nur bestimmte Ports partizipierten …

…, doch die Realität sieht anders aus; sowohl über’s WLAN (802.11n 150 MBit/sec), über welches in dem Moment nichts anderes rüberkommt, als auch auf einem Gerät an Port 5 des GS108T im Untergeschoß fliegen diese Meldungen durch den tcpdump:

00:01:50.900314 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 327
00:01:50.903940 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 327
00:01:50.907573 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 336
00:01:50.911445 IP 192.168.5.230.3085 > 239.255.255.250.1900: UDP, length 336

IMHO dürfte sowas nie und nimmer auftreten; leider geschieht dies auch bei der neusten Firmware (3.0.4.10). Clues, anyone? So sind die GS108T jedenfalls für den Einsatz in Multicast-Umgebungen un-brauch-bar :-(
Und, mal ganz ehrlich: so langsam frage ich mich, ob T-Entertain den Streß und die heimischen Infrastrukturkosten (die 3 GS108T habe ich auch nur angeschafft, um den Multicast-Wahnsinn von meinen WLAN-APs fernzuhalten (da jene nämlich sonst nicht mehr als AP funktionieren können …) wert ist — neben den damals rd. 100 EUR für eine bis heute nicht in der beworbenen Form (2 DVB-T-Tuner, USB-Port für mehr als nur Stromlieferant für die PS3-Pads) bereitgestellte SetTopBox, die keinerlei Möglichkeiten der Sicherung der Aufnahmen vor einem Plattenausfall vorsieht, also weitere 300,– EUR direkte Kosten nur, damit man über’s »Internet fernsehen« kann … (Und mit »Internet« hat T-Entertain ja auch nur das Protokoll gemein …) Was für eine Sat-Anlage bekommt man wohl für 300,– EUR?

Es find letztlich damit an, daß ein weiteres meiner heiß und innig geliebten, also auch viel eingesetzten, D1171-Boards von FSC, diesmal in einem Scenic B, rumalzheimerte …
Aber von vorn … Im Zuge des Green-IT-Wahns habe ich vor geraumer Zeit den Full-Blown AMD Athlon XP im Keller stillgelegt — er war nur noch VDSL-Router und OpenVPN-Endpunkt und damit ziemlich oversized … Geplant ist (war) eigentlich, den GuruPlug Plus als VDSL-Router und OpenVPN-Endpunkt einzusetzen, da GlobalScale hier aber leider nur einen Heizkörper anstelle eines im Rahmen der initialen Spezifikationen funktionsfähigen Computers produziert hat, fällt diese Option erst einmal flach.
Und da nichts länger hält als ein Provisorium … hat sich hier auch lange Zeit nichts weiter getan, der neue Router, ein Scenic B, bekam eine zweite, LowProfile, Netzwerkkarte und hatte somit auf eth0 die heimischen Netze und auf eth1 die Verbindung zum VDSL-Modem.
Irgendwann begann dann, bei meinen nur noch kurzen Besuchen auf der Heimatbasis, das WLAN rumzuzicken, 30% und mehr Packetloss, das ist unspaßig, aber dermaßen auch … Und da mehrere Geräte nun über n-Draft-WLAN verfügten, lag es irgendwie nahe, auf wenigstens den n-Draft-150-MBit/sec-Zug aufzuspringen — zumal Edimax BR-6226N für 17,– EUR brutto bei Reichelt grade im Angebot waren. (Auch latent hackbare Boxen, linux-driven …) Jene lösten dann die betagten WRT-54G (nein, die wurden lange vor Existenz der “GL”-Modelle angeschafft und mit OpenWRT versehen) ab, in der Hoffnung auf bessere Verbindungen. Zugleich wurde damit dann das gute alte WEP-WLAN »UU Home« entsorgt; es wird ja bald schwierig, noch Geräte zu finden, die überhaupt noch das so-gut-wie-offene WEP unterstützen ;) Schade nur für die WLAN-basierte Ortung; aber ich bin sicher, die spionierenden Geräte von u. a. Apple und auch die ganzen Androiden werden die neue Situation schnell in den Datenbanken vermerken …
Tja. Nun habe ich also schnelle(re)s WLAN — aber die Probleme bleiben. Zudem hängt sich immer öfter der Router weg, dann routet er zwar noch mit wechselndem Paketverlust, im Usermode ist aber tote Hose (kein SSH-Login mehr, nicht mal das login auf der Console tat nach der Eingabe von “root” noch irgendwas). Quick- and dirty-Lösung: Fernschaltbare Steckdosenleiste vor den Router, bei Nichtantwort auf ssh-Verbindungen einen Power-Cycle initiieren. Das half … nicht wirklich, aber besser, als die bessere Hälfte dies händisch bei Entdeckung »Netz geht nicht« machen zu lassen …
Aber was nun tun? Im Keller laufen sowieso schon zwei Dockstar als Fileserver, und endlich sind die USB-Ethernet-Dongles angekommen — was also liegt näher, als einen Dockstar zum Router aufzubohren? Ich meine, hey, ein 08/15-Intel hat VDSL mit den beiden VLANs und den igmpproxy und das olsr-und-openvpn-Geraffel hinbekommen, wie schwer kann es sein?
Vorweg: ziemlich. Aua. Das war wieder einmal ein Griff in die volle … braune Brühe, in der ich dann gen Abend hin knietief watete. Denn so ein Router, der braucht so ziemlich alles, was ein Fileserver grade nicht braucht. Das fängt dann bei so Details wie vconfig und dem 8012q-Modul für’s VLANing langsam an, hört mit Details wie »das 100-MBit-USB-Dongle nutzt andere Treiber als das 1000er« nicht auf und gipfelt dann in der Notwendigkeit von »Advanced Router« (für verschiedenen Routingtabellen; einige Geräte, z. B. das Entertain-Böxchen, müssen über die T-VDSL-IP rausgehen statt über den meinen PI-Adressbereich bereitstellenden Tunnel) oder »Multicast Routing«, ohne das ipgmproxy nicht spielen mag.
Erschwerend kam hinzu, daß ich die ersten drei meiner Dockstars noch nach »Schema Holler« aufgesetzt hatte, d. h. in den freien Flashbereich des Standard-Dockstar wird ein USB-Boot-fähiges uBoot installiert, welches stumpf /boot/uImage vom ersten Laufwerk bootet. Dieses Setup hat den Vorteil, daß man weniger Flashen muß, zumal, wenn man wie hier im Stundentakt neue Kernel bäckt (diverse der Optionen sind im Kernel verankert); es hat aber leider, zumindes bei mir, den Nachteil, daß ein Reboot nicht möglich ist, beim Warmstart findet das neue uBoot zwar noch USB-Geräte, bei bzw. vor der Erkennung des USB-Storage-Geräte allerdings verabschiedet es sich sang- und klanglos — ohne Power-Cycle geht nichts :( Ein weiteres Detail, welches letztlich dazu führte, daß ich VLAN 7 und 8 über meine GS108T aus dem Keller ins Arbeitszimmer im 1. OG »legte«; ganz so mobil bin ich derzeit leider nicht und gleich wieder mit dem Powercycle-per-Steckdosenleiste-Holzhammer zu kommen, das erschien mir auch nicht zielführend.
Da meine »Radikaloperation«, bei der der Dockstar einen neuen Kernel als auch ein neues (UBIFS-) rootfs geflasht bekommt, dieses Rebootproblem nicht haben – wobei, daran, daß es mir jetzt erst aufgefallen ist, sieht man, wie stabil die Dockstar-Büchsen als NFS-Sever vorsichhinwerkeln … –, werde ich wohl doch meinen letzten »Spare«-Dockstar nach diesem Schema behandeln und nur Kernel/Module ändern auf das fertig (auf einer Box in Berlin Cross-) kompilierte 2.6.32.2 ink. Dockstar-Patches von Alexander Holler. So eine grün leuchtende LED ist einfach schicker als eine hektisch grün blinkende ;)
Schade, daß die Dockstar jetzt wieder im Bereich (jenseits) der 30,– EUR kostet; ich hätte für dieses kleine Wunderkiste sicher noch die eine oder andere Idee, um selbst nicht den Überblick zu verlieren, hier mal meine bisherige »Horrorshow« (aus Sicht von Seagate ;)):

1. ds-1 ersetzte nlsug-1 (NSLU2) als Fileserver; derzeit auch »Zentralgestirn« (Router, DHCP-, DNS-, OpenVPN-Server).
   Peripherie derzeit: 4x USB-HDD, 1 USB-Ethernet

2. ds-2 sammelte 3 weitere versprengte USB-HDD und serviert nun deren Daten ins LAN.
   Peripherie derzeit: 3x USB-HDD, 1 schaltbare Steckdosenleiste (SIS-PM)

3. ds-3 wandert demnächst in den Keller als (HD-) VDR-Server und wird wohl 1-2 Scenic Xs mit insges. 1x DVB-S2, 2x DVB-S, 1x DVB-T ersetzen.
   Peripherie derzeit: 1x USB-HDD, 2x S2-3600, 1x S-2400 (planned)

4. ds-4 steht im Office und malt bunte Smokeping-Graphen über die Netzanbindung …
   Peripherie derzeit: 1x USB-HDD

5. ds-5 habe ich einem Kollegen als Spielwiese überlassen. Er macht darüber wohl IPv6-Experimente ;)
6. ds-7 ist mein Router in Berlin (Alice-ADSL2, Alice-HSDPA, OLSR, OpenVPN, …), außerdem läuft FHEM drauf
   Peripherie derzeit: 1x USB-Stick als /dev/sda, 1x Huawei E620, 1x CUL

7. ds-8 ist mein DVB-T-VDR in Berlin
   Peripherie derzeit: 1x USB-HDD, 1x MSI DIGIVOX Duo DVB-T

8. ds-9 harrt noch einer Aufgabe.

BTW, über günstige (unter 26,–/Stück inkl. Versand) Bezugsquellen würde ich mich freuen als auch über Hinweise auf andere, änhliche Geräte; Seagate scheint mit dem »FreeAgent GoFlex« ja eine abgewandelte Form des Dockstar auf dem Markt gebracht zu haben, aber außer, daß da zwei Platten direkt reinpassen und dafür nur noch 1x USB rausgeführt wird, scheint es »nur« ein teurerer Dockstar zu sein?

Windgeschützte Messung auf Innenstadtbalkon …

Oh ja, der Winter kommt. Und zwar mit ziemlich großen Schritten. Nachts ist es wirklich schon empfindlich kalt bei unter 5 Grad, da jagte man keinen Hund mehr vor die Tür (geschweige denn ginge mit ihm freiwillig Gassi), und auch tagsüber ist es frisch.
Auch wenn meine über FHEM und CUL ausgewerteten Meßfühler aus der

Weder vor Sonne noch Wind geschützter Meßpunkt in Gütersloh

keine hochpräzisen Instrumente darstellen, bei paralleler Messung lag der Unterschied im Bereich von unter einem Grad. Insofern meine ich, feststellen zu können, daß durchaus auch jetzt eine unterschiedliche Temperaturkurve in Berlin gemalt wird, daß es in Berlin vermutlich durch die »Grundwärme der Großstadt« tatsächlich marginal wärmer ist in diesen kalten Nächten. Wobei ein Grad Celsius den Kohl nicht fett macht — aber irgendwie intereressant finde ich es doch ;)