Monthly Archives: Juni 2010

SIP – Geißel der Menscheit?

Posted on by

Hachja. Sagt mal. kann es sein, daß SIP eine echte bescheidene Erfindung ist? In Vorbereitung meiner Übersiedlung nach Berlin baue ich mir derzeit meine Netzanbindung (samt Telefonie, versteht sich) zusammen, und da ich den dortigen Hardwareaufwand minimal halten will, kommt vor Ort ein Speedport W900V, umgefritzt auf eine DECT-7170 (i. e. eine 7150, IIRC), zum Einsatz, welche über OpenVPN-Tunnel mit dem Gegenstück in Gütersloh, welche am heimischen ISDN hängt, kommunizieren soll. Die FritzBox in Berlin hängt als »Telefoniegerät am Anschluss “LAN/WLAN”« an der FritzBox in Gütersloh. Während das Raustelefonieren in beide Richtungen (also Hören und Sprechen) schon klappte, als die FB-GT nicht zur FB-B durchkam, hatte ich eben Spaß dergestalt, daß ich »in Berlin« zwar einen Anruf auf die Gütersloher Nummer annehmen konnte, Sprache vom »Gütersloh« anrufenden Handy allerdings kam nicht nach »Berlin« durch.
Nunja; wie ich dann feststellte, gab es Routingprobleme von »Berlin« nach »Gütersloh«. Warum aber die spigelbildliche Tonverbindung nicht funktionierte: keine Ahnung. Warum überhaupt die Rufannahme klappte: keine Ahnung.
Jedenfalls super zu debuggen:
GT nach B

# traceroute 193.26.120.30
traceroute to 193.26.120.30 (193.26.120.30), 30 hops max, 38 byte packets
1 192.168.44.9 (192.168.44.9) 47.611 ms 47.318 ms 43.141 ms
2 dockstar-4.vpn.uu.org (192.251.226.178) 214.321 ms 199.393 ms *
3 dhcp-14.berlin.uu.org (193.26.120.30) 201.338 ms 203.731 ms 198.400 ms

B nach GT

dockstar-4:~# traceroute fbw900v-2.uu.org
traceroute to fbw900v-2.uu.org (192.168.5.248), 30 hops max, 40 byte packets
1 gw-dockstar-4.vpn.uu.org (192.251.226.177) 319.574 ms 320.259 ms 320.401 ms
2 albert-vdsl2.uu.org (193.26.120.250) 359.448 ms 359.602 ms 359.728 ms
3 * * *
4 * * *

Falls sich jemand über die Zeiten wundert: »dockstar-4« ist mittles USB-UMTS-Stick und o2-SIM (200 MB-Angebot, bei dem u. a. auch VOIP erlaubt ist :-)) online, das Netz per OpenVPN-Tunnel aus dem Rechenzentrum in Gütersloh erreichbar. Nach Hause, ins 192.168.5er Netz geht’s aus dem DC ebenfalls per OpenVPN-Tunnel (partiell sogar per OpenVPN-in-OpenVPN …).
Gut, nachdem nun auch das bidirektionale Routing klappt …

dockstar-4:~# traceroute fbw900v-2.uu.org
traceroute to fbw900v-2.uu.org (192.168.5.248), 30 hops max, 40 byte packets
1 gw-dockstar-4.vpn.uu.org (192.251.226.177) 179.566 ms 189.495 ms 189.391 ms
2 albert-vdsl2.uu.org (193.26.120.250) 238.676 ms 278.454 ms 288.244 ms
3 192.168.5.248 (192.168.5.248) 308.005 ms 447.815 ms 447.787 ms

… sollte ja auch die bidirektionale VoIP-Kommunikation zwischen den FritzBoxen funktionieren. Aber was ist? Egal, was ich als Ton am Handy, welches die Festnetznummer anruft, welche auf das »Telefon«, aka die FritzBox Berlin, geleitet wird, einspeise: nichts kommt auf dem DECT-Mobilteil in »Berlin« an. Ton aus »Berlin« hingegen kommt super (ok, mit rd. 250ms Minimallatenz, also deutlich verzögert) auf dem »Gütersloh« anrufenden Handy an … Any clues?

DockStar debianisieren per NFS-Root, ohne Consolenzugriff

Posted on by

Von Dirk Tostmann auf die Idee gebracht, versuche ich mich derzeit an einem Prototypen für das Umflashen eines DockStars zu einem »kleinen« SheevaPlug. Ich habe im Folgenden versucht, meine Schritte zu dokumentieren, die Idee dazu stammt, wie gesagt, von Dirk. Die nachfolgenden Schritte habe ich mittlerweile an einem zweiten DockStar ausprobiert — ohne die Console bemühen zu müssen.
Aber dennoch, auch um mich abzusichern: DON’T TRY THIS AT HOME (YET)! IT MOST CERTAINLY WILL BRICK YOUR DOCKSTAR DEVICE! Sollten einzelne Schritte fehlschlagen, z. B. das Booten der NFS-Root nicht funktionieren, ist es notwendig, die serielle Schnittstelle des DockStars zu aktivieren. You have been warned …
Ablauf:

  1. Umgebung vorbereiten: uImage von sheeva.with-linux.com holen, auf dem TFTP-Server ablegen (hier als »sheeva-2.6.34-uImage«, ggf. anpassen).
  2. NFS-Rootumgebung bereitstellen auf einem vom DockStar erreichbaren NFS-Server. Ich nehme dazu wieder das Debian-Lenny-Archiv; zum uImage passende Modules von sheeva.with-linux.com holen und in der NFS-Root ablegen; ebenfalls das uImage nach $NFSROOT/boot packen.
    Die Datei $NFSROOT/etc/fstab korrigieren (alles auskommentieren), $NFSROOT/etc/mtab zur Sicherheit löschen. In $NFSROOT/etc/network/interfaces die Zeilen mit eth0 auskommentieren; das Netzwerk ist bei NFS-Root schon konfiguriert, wenn die init-Skripte loslaufen (nette Falle BTW ;)). Evtl. auch $NFSROOT/etc/resolv.conf anpassen, wenn man einen lokalen Nameserver hat (Fritz!Box z. B.).
  3. UBIFS erzeugen und in NFS-Root ablegen; ich habe hierzu ebenfalls das Lenny-FS genommen (um ehrlich zu sein: die NFS-Root nochmal kopiert) und insbesondere dort etc/network/interfaces angepaßt, sodaß eth0 per DHCP versorgt wird. Auch etc/hostname und etc/hosts habe ich dort angepaßt, schon um Unterschiede zur NFS-Root zu sehen.
    Erzeugung des UBIFS (im Unterverzeichnis ubifs-root-fuer-DockStar); im Ubuntu 10.04-Paket sind alle erforderlichen Binaries drin, wer auf Debian Lenny arbeitet, braucht das mtd-utils-Paket aus Debian Testing): 

    cat <<eof >ubi.cfg
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=200MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
eof
mkfs.ubifs -r ubifs-root-fuer-DockStar -m 2048 -e 129024 -c 4096 -o ubifs.img -x zlib
ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubi.cfg

    Die Datei ubi.img dann ins / des NFS-Roots kopieren.

  4. DockStar normal booten, IP per DHCP geben lassen. Einloggen per SSH (root, stxadmin). Dann: 
    cd
mount -o rw,remount /
wget http://plugapps.com/os/pogoplug/uboot/blparam
chmod 755 ./blparam
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/root
blparam orgbootcmd='nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
blparam netmask=255.255.255.0
blparam ipaddr=192.168.5.235
blparam serverip=192.168.5.2
blparam arcNumber=2097
blparam mainlineLinux=yes
blparam bootargs_end=:::DB88FXX81:eth0:none
blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) ; bootm 0x800000'
blparam bootcmd='run tftpboot'
blparam mtdparts='orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0x2000000@0x500000(rootfs),0xDB00000@0x2500000(data)'
blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) $(mtdparts) ; bootm 0x800000'

    Hier die Daten natürlich dem eigenen Umfeld entsprechend anpassen. Achtung, in dieser Konfiguration hat der NFS-Root-gebootete DockStar *kein* Default-Gateway!

  5. Dann beherzt einen Reboot des DockStars durchführen.
  6. Nach kurzer Zeit sollte er wieder erreichbar sein (ping aus dem gleichen Netz auf, hier, 192.168.5.235, sollte beantwortet werden), dann wieder einloggen (root, root). Der ssh-Client wird wegen falscher Keys meckern, dann entsprechend den alten löschen. (Alternativen wie eine .ssh/options überlasse ich dem geneigten Leser ;)).
    Auf dem nun per NFS-Root laufenden DockStar mal die Flashaufteilung ansehen: 

    debian:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 0fb00000 00020000 "root"

    Sieht gut aus. Nun wird’s haarig ;) 

    route add default gw 192.168.5.2
wget http://http.us.debian.org/debian/pool/main/m/mtd-utils/mtd-utils_20090606-1_armel.deb
dpkg -i mtd-utils_20090606-1_armel.deb
flash_eraseall /dev/mtd2
ubiformat /dev/mtd2 -s 512 -f /ubi.img -y
flash_erase /dev/mtdblock1
flash_eraseall /dev/mtd1
cat /boot/uImage > /dev/mtdblock1
wget http://plugapps.com/os/pogoplug/uboot/blparam
chmod 755 ./blparam
./blparam
./blparam bootargs_ubi='ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'
./blparam newbootcmd='nand read.e 0x800000 0x100000 0x300000 ; setenv bootargs $(console) $(mtdparts) $(bootargs_ubi) ; bootm 0x800000'
./blparam bootcmd='run newbootcmd'
  7. Nach dieser Prozedur sollte der nächste Reboot in ein Debian auf dem DockStar führen, welches als UBIFS im Flash läuft …
  8. Login war bei mir aufgrund des gewählten Filesystemarchivs root, root; man sollte dementsprechend auf dem neuen System – ggf. ist nochmal wieder ein Meckern von ssh wegen der ssh-Keys zu umschiffen – noch folgendes tun:
    • Passwort von root ändern (»passwd«-Befehl)
    • Keys für ssh neu machen, z. B. so: 
      rm /etc/ssh/ssh_host*
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
    • /etc/hostname, /etc/hosts anpassen

No animal was harmed during these procedures … No liability assumed, your mileage may vary, standard disclaimers apply …

Tribut an den Winter …

Posted on by

(Blogged via flickr)

Die Verbindungen am Schlauch haben nichts abbekommen; die beweglichen Geräte allerdings sind fast alle mehr (Bild) oder weniger undicht :( Waren die -1x Grad in der Gartenhütte doch zu viel Kälte?

Kamera: Vignette Vignette for Android

Android (Market), Für und Wider

Posted on by

Ich bin, als Kunde/Anwender, nicht 100%ig zufrieden mit dem, was Google bzgl. Android tut; die Fernkontrolle über Smartphone-Inhalte ist ein Punkt, die nicht-existente OS-Upgradepolitik ein anderer. Grade Letztes ist schon verstörend, so gibt es für mein HTC Magic »with Google« von Vodafone bis heute kein Update auf eine 2.x-Version — und schon vor längerer Zeit wollte z. B. Pixelpipe die Unterstützung für Android 1.5 einstellen …


http://blogdoch.net/images/CAP201006280933-2.png width=180 float=right]So pauschal kann man nicht sagen, daß ausländische Apps mit AMEX nicht bezahlt werden können …

Die Vorwürfe von Jon Lech Johansen bezüglich der Bezahlbarkeit von Anwendungen im Android Market allerdings erscheinen mir zu kurz zu greifen bzw. schlecht recherchiert:

In addition, the price for foreign apps is not displayed in the user’s local currency and developers do not have the option of customizing pricing by country. To make matters worse, you can’t pay for foreign apps using your Amex card or carrier billing. There’s also no support for in-app payments and changelogs (to communicate app changes).

 
Daß man fremde Währungen angezeigt bekommt ist latent vielleicht ärgerlich, ein Problem darin sehe ich als deutscher Europäer, der mit Schweizer Franken, Österreichischem Schilling, Dänischer Krone, Französischen Franc, Spanischer Peseta und nicht zuletzt Englischem Pfund aufgewachsen ist, nicht.

… allerdings geht mit AMEX nicht alles — was zumindest europäische AMEX-Nutzer eigentlich nicht überraschen sollte; toom z. B. akzeptiert auch im Juni 2010 zumindest in Gütersloh AMEX nicht, dies ist kein Android-Market-Problem.

Franc, Schilling und Peseta sind, wie die Deutsche Mark, Euro-Geschichte; mit Franken, Pfund oder auch Krone muß ich aber nach wie vor ggf. umgehen können. In Zeiten eines noch immer relativ stabilen Wechselkurses sehe ich auch und grade für den Endkunden kein Manko darin, mit Frendwährungen konfrontiert zu werden.
Der zweite Vorwurf ist, daß man mit seiner Kreditkarte von American Express – AMEX – »nicht für ausländische Apps zahlen« könne; nun, diese Aussage ist zumindest für eine deutsche AMEX-Karte im deutschen (gibt’s andere?) Android-Market nicht richtig für (manche? Bei mir bislang alle) Apps, die in USD abgerechnet werden. Aber mit AMEX ist man – meiner persönlichen Erfahrung nach nicht nur in Deutschland – generell nicht der beliebteste Kunde, insbesondere Nichtakzeptanzstellen sprechen von deutlich höheren Provisionen und anderen Gründen, die sie von der Akzeptanz der AMEX-Karten abhalten. Und, wie die Screenshots zeigen, ist der Einkauf im Android Market mit einer deutschen MasterCard auch dort möglich, wo die AMEX gesperrt ist (beispielsweise gehen auch Yenn). Das Problem ist mithin mehr eines der verwendeten Kreditkarte denn des Android Markets …
Inwiefern ich »in-app payments« vermisse, weiß ich nicht; vermutlich vermisse ich sie eher nicht, vermutlich fände ich Apps, die kostenlos daher kommen und so kostenlos nur Platz auf meinem Smartphone verbrauchen, jede aktive Dienstleistungs aber extra abrechnen wollen, eher doof. YMMV.

Mobile I Am.

Posted on by

Es ist etwas untergegangen, aber ich habe gestern beim »Public Viewing« – wie übersetzt man das eigentlich, »öffentliches Gucken«? – im Parkbad Gütersloh mehr oder minder zufällig das 4:2 4:1 Deutschlands gegen England (BTW, bei Gelegenheit mag mir mal wer erklären, warum beim »FIFA World Cup« die »Länder« »England« und »Schottland« antreten (könnten), nicht aber auch Bayern, Sachsen oder Texas …) per Motorola Milestone aufgenommen und, einmal ist immer das Erste Mal, per Pixelpile zu flickr hochgeladen:

Sicherlich kein cineastisches Highlight, und die knapp 12 MB .3gp-Video sehen nach Re-Encoding durch flickr auch nicht besser aus; aber irgendwie cool, daß das geht, finde ich das schon ;) (Ich hätte ja auch qik genommen, aber deren App wollte meine Credentials wissen; keine Ahnung, ob ich die App mal aus Frust ob der schlechten »HighQuality« entsorgt habe oder ein Update schief lief — ein Verlust ist die Löschung von qik IMHO eh’ nicht, sodaß ich sie grade vollzogen habe …)