#Firesheep in Aktion …

(Blogged via flickr)

Schon faszinierend einfach (Mac vorausgesetzt; mit Linux bin ich leider noch außen vor), der Identitätsklau in unverschlüsselten öffentlichen Netzen (hier: Miner’s GT), grade bei/über Facebook …

Kamera: Nokia N900 (Brennweite 5.2mm, f/2.8)

GuruPlug – mein erstes »brick on arrival«-Gerät

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

Wenn ich meine Memoiren schreibe, …

… 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 ;)

DockStar debianisieren reloaded

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 …

Fallstricke

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

Bones, is it dying?

/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)?

C, T, S – oder doch IP?

Bei der Suche nach Wohnraum kommt, neben der Lage relativ zu öffentlichen Verkehrsmitteln einerseits und deren Fahrzeit zur Wirkungsstätte, heutzutage natürlich auch eine andere, nein, eigentlich zwei, infrastrukturelle Fragen auf: 1. Ist mindestens ADSL2+ mit mind. 16 MBit/sec, besser noch VDSL50, verfügbar?

2. Welche Empfangsmöglichkeiten für TV habe ich?
Portale wie immobilienscout24.de haben sich darauf eingestell und bieten einerseits mit den Wohnungsdaten einen direkten Link in die VDSL-Ausbaugrafik der Telekom, andererseits einen Link zu Kabel Deutschland, um ort ebenfalls recherchieren zu können.
Gut, für mich kommt außer DVB-S eigentlich nichts anderes in Frage, denn wo ich bei DVB-S nur für ‘n Kabel & ‘n ‘Baumarktreceiver sorgen muß, komme ich beim Kabelfernsehen, verrauschtes Analog-TV mal außen vor, dank der Grundverschlüsselung beim Digitalprogramm nicht umhin, um mehrere Smartcards zu bitten (was ggf. Zusatzkosten verursacht; die Erfüllung dieses Wunschens, nicht das Betteln drum), mehrere (teurere, ggf. »zertifizierte«) Receiver zu kaufen (die bei einem Umzug in das Gebiet eines anderen Kabelanbieters ggf., *schupps*, zu Sondermüll werden) und für dieses ganz normale Verhalten, nämlich mehrere Fernseher im Haus zu haben, muß ggf. zusätzlich gezahlt werden. Extra toll ist es natürlich, wenn die »Kabelgebbühren« schon in den Mietnebenkosten verrechnet sind; selbst, falls man kein Kabel-TV nutzen möchte – zahlen muß man dann dafür trotzdem.
Ähnlich wie beim Kabel-TV verhält es sich (zumindest beim Marktführer) beim »Internet-TV« IPTV. Auch hier sind mehrere SetTopBoxen kostenpflichtig zu erstehen, im Falle T-Entertain sind dies Geräte, die ohne T-Internetverbindung nichtfunktionaler Sondermüll sind. Und, IIRC, derzeit ist nur genau 1 Aufnahmegerät pro Haushalt vorgesehen, selbst wenn die weiteren STBs diese Funktion technisch auch böten …
Kurz: für mich ist DVB-S die Macht, nur, leider, sehen das die meisten Vermieter anders und beglücken den Mieter mit zwangsweise Kabel-TV, und ob eine Line of Sight zu Astra überhaupt möglich ist, muß man ggf. vor Ort ausmessen — was man vor der Anmietung aus taktischen Gründen besser läßt, sind viele Vermieter doch stolz auf’s Kabel …

Multicast-Stürme im WLAN und andere T-Entertain-Probleme

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 …

GS108T UG: Dynamic Multicasting
ID VID Multicast Entry Port Members
1 1 01:00:5E:7F:FF:FA 8
2 1 01:00:5E:23:8B:0B 4 ,8
Port 4: VDR mit IPTV-Plugin sowie den (ÖR-)T-Entertain-Kanälen in der channels.conf
Port 8: Link ins EG
GS108T EG: Dynamic Multicasting
ID VID Multicast Entry Port Members
1 1 01:00:5E:7F:FF:FA 3 ,4
2 1 01:00:5E:23:8B:0B 1 ,3 ,4
Port 1: Link ins UG
Port 3: X301T im Wohnzimmer (Direktanschluß an Switch)
Port 4: Link ins OG
GS108T OG: Dynamic Multicasting
ID VID Multicast Entry Port Members
1 1 01:00:5E:7F:FF:FA 1 ,3 ,8
2 1 01:00:5E:23:8B:0B 1 ,3 ,8
Port 1: Link ins EG
Port 3: LAN-Port des Routers (Dockstar mit igmpporxy)
Port 8: GBit-Switch “Layer1″ (unmanaged)

…, 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?