>
Mein freundlicher Quadro-Dealer war so nett, mir Samstag Nachmittag doch noch zu antworten und so gab es doch noch kurz vor Toreschluß Nachschub – für den ‘Wohnraum’, wie die Kinder sagen :) *.
>Neues aus Schilda?
>
Gesehen heute in einem der ländlicheren Stadtteile Bielefelds. *.
Nachschub
(Blogged via flickr)
Mein freundlicher Quadro-Dealer war so nett, mir Samstag Nachmittag doch noch zu antworten und so gab es doch noch kurz vor Toreschluß Nachschub – für den ‘Wohnraum’, wie die Kinder sagen :)
Kamera: HTC HTC Magic
Neues aus Schilda?
(Blogged via flickr)
Gesehen heute in einem der ländlicheren Stadtteile Bielefelds.
Kamera: HTC HTC Magic
>Baustoffmangel
>
Auch der Hobbybaumeister leidet zuweilen unter Nachschubproblemen. Als wir vor Jahren mit dem Quadro Großbaukasten anfingen, war der Hersteller grade irgendwo zwischen Selbstauflösung und Pleite; dankend kauften wir in Geschäften der Umgebung großzügig reduzierte Restposten auf. Mittlerweile scheint Quadro mit neuem Kapital ausgestattet zu sein — auch wenn mir Toys World Gütersloh heute beschied, Quadro sei Pleite und Neuware gäbe es nicht mehr … Dennoch bleibt der Bezug von Ergänzungsteilen schwierig, Spielzeugläden scheinen es nicht zu führen, die nächste Quelle scheint ein ebay-Händler in Bielefeld zu sein; leider hat er auf eMail gestern nicht geantwortet und telefonisch gab es heute nur.nen AB; die Faxnummer ist dauerbesetzt :( Also doch bestellen bei einem anderen Händler aus der Bucht bzw. dem Quadro-Online-Store … und warten :( *.
Baustoffmangel
(Blogged via flickr)
Auch der Hobbybaumeister leidet zuweilen unter Nachschubproblemen. Als wir vor Jahren mit dem Quadro Großbaukasten anfingen, war der Hersteller grade irgendwo zwischen Selbstauflösung und Pleite; dankend kauften wir in Geschäften der Umgebung großzügig reduzierte Restposten auf. Mittlerweile scheint Quadro mit neuem Kapital ausgestattet zu sein – auch wenn mir Toys World Gütersloh heute beschied, Quadro sei Pleite und Neuware gäbe es nicht mehr … Dennoch bleibt der Bezug von Ergänzungsteilen schwierig, Spielzeugläden scheinen es nicht zu führen, die nächste Quelle scheint ein ebay-Händler in Bielefeld zu sein; leider hat er auf eMail gestern nicht geantwortet und telefonisch gab es heute nur.nen AB; die Faxnummer ist dauerbesetzt :( Also doch bestellen bei einem anderen Händler aus der Bucht bzw. dem Quadro-Online-Store … und warten :(
Kamera: HTC HTC Magic
Vodafones Einwegkommunikation 2.0
Das schnell zu den Akten … ich schrieb im Vodafone-Blog zum twittermon-Artikel:
#143 Kai ‘wusel’ Siering Says:
Juli 21st, 2009 at 1:40 am
@Carmen Hillebrand (#52):
»Offenheit bedeutet aber eben auch, daß wir durchaus konträre Positionen stehenlassen sowie Inhalte, die wir nicht teilen. Dies wird gerne von unseren Kritikern, Euch, als “fail” bezeichnet, wir bauen darauf, daß wir nur durch diese Offenheit einen Dialog haben können, auch wenn wir lieber positive Kommentare lesen würden.«
Jetzt mal ehrlich, bis auf den letzten Absatz, Stil hin oder her, mag das ja noch ein netter Blogpost sein; aber was bitte erwartet Ihr ernsthaft auf ein »Seit drei Monaten habe ich ein neues Handy, das HTC Magic mit Internetanschluss. Tolles Ding, mit wenig Knöpfen dran, das ist äußerst praktisch. Mein altes Handy hatte viel zu viele Knöpfe. […] So geht mir nichts mehr verloren und meine Handyrechnung beschert mir seitdem auch keine böse Überraschung mehr.« als Abschluß eines solchen Posts?
Das HTC Magic ist unterhalb monatlich 59,95€ nicht einsetzbar (SuperFlat Internet; SuperFlat Internet Wochenende würde mir ja reichen bei denn paar Anrufen, beinhaltet aber nur 200 MB/Monat zzgl. »0,49 Euro proMB« ab MB 201 => worst case also Privatinsolvenz, wenn so ein Always-On-Gerät mal datenhungrig wird; die Option Vodafone live! InternetFlat, die da einen o2-ähnlichen Fallschirm aufspannen würde ist, lt. Aussage des Shopangestellten, mit den SuperFlat-Tarifen nicht buchbar!) und beinhaltet dann »VideoTelefonie1« (kann das HTC Magic nicht; peinlich eigentlich), »Basiskanäle von MobileTV15« (mit dem HTC Magic nicht nutzbar) sowie »3.000 SMS und 1.500 MMS aus dem deutschen Vodafone-Netz ins deutsche Vodafone-Netz« (abgesehen davon, daß ich vorher nicht weiß, in welchem Netz die Zielnummer ist, ein tolles Angebot, 4,17 SMS und 2,01 MMS darf ich also je Stunde schicken …) — reife (zwangsweise bezahlte aber nicht wirklich nutzbare) Leistung! Vielleicht hat Frau Hamelmann ja wirklich ein unbegrenztes Telekommunikationsbudget, mich schmerzt das »Eintrittsgeld« in die mobile Kommunikation bei D2 schon, irgendwie …
Und, nur am Rande: Schon mit dem N95, und das ist mittlerweile aaaalt (hat aber noch immer eine deutlich bessere Kamera als das Magic :() und der besagten Vodafone live! InternetFlat war seit langem das Hochladen von Bildern möglich; ich hab’s mit locr gemacht, flickr & Co. gehen sicherlich auch.
Neu am Magic ist eigentlich nur die Anzahl der gleichzeig möglichen, den Akku leersaugenden, Programme (und der Komfort, wie man diese auf sein Handy bekommt), dumm ist aber die Laufzeit von, na, mit Chance 8 Stunden »always on«.
Also, mit Verlaub, ein solcher Text gehört nicht in eine Blogumgebung, damit schafft man jedenfalls keine »Offenheit« und bekommt auch nur schwerliche »positive Kommentare«, da die Story hanebüchen, ja, sorry, bullshit ist. Jedenfalls für jemanden, der nicht erst mit dieser tollen Kampange angefangen hat, das Internet mobil *zu nutzen* …
Die Kommentare sind mittlerweile geschlossen; eine Replik der Vodafone gab es nicht – Dialog 0.0. Gut, sicher, man mag dagegen halten, daß Vodafone/deren Marketeers nach dem 211. Kommentar zum Beitrag von Ex-Schnutinger Ute Hamelmann die ausufernde Diskussion offensichtlich morgens am 22.07.09 beendet haben, auch hier die Reißleine gezogen. Macht es das besser?
Ich finde nicht; eine Kampange im Web 2.0, die eine sogenannte »Generation Upload« adressiert, kann nicht einfach den Dialog beenden, den die Wahl des Mediums Blog impliziert. Klar, technisch kann man das. Bedeutet aber, daß der ganze – in der Pressekonferenz auch arg bemüht kommunizierte – Web-Zwo-Null-Zinnober nichts als der Versuch ist, dummdreißte Werbesprüche in einem Web-Zwo-Null-Gewand an den »Uploader« zu bringen. Im Westen also doch nchts Neues. Gut, wie kein kleines Kind auch jegliche Aufmerksamkeit – und sei es der Zorn des Elters ob der Quengelei – als Erfolg verbucht, so gilt für Werbetreibende auch eher das Motto: »Aufmerksamkeit um jeden Preis«.
[ ] Vodafone hat verstanden.
Denn Wochen nach der Pressekonferenz gibt es nach wie vor eben keine »Uploader« anziehenden Tarife. Es gibt im Vodafone-Blog täglich einen Beitrag, der sich weder mit bisherigen Geschehnissen rund um die #Vodafail-Kampagne zu auseinandersetzt noch irgendwie den Anschein erweckt, etwas anderes zu sein als die Abarbeitung der im Fünf-Wochen-Plan vorgesehenen Posts. Schade.
In Anlehnung an einen anderen Spruch – »nicht alles, was hinkt, ist ein Vergleich« – bleibt also festzustellen, daß die Wahl einer Blogsoftware (ich tippe mal auf WordPress, auch wg. <link rel="stylesheet" href="http://blog.vodafone.de/wp-content/themes/vfblog/style.css" type="text/css" media="screen" />) nicht automatisch eine Website zu einem (We-)Blog(-buch) macht. Auch hilft es wenig, »Blog« drüber zu schreiben, wenn man »Kundeninformation« meint.
Nachtrag: Alice
Zu meinem – aus meiner Sicht nach wie vor viel zu milden – Alice-Bashing noch ein Nachtrag, wat mut, dat mut: Donnerstag Nachmittag rief die Alice-(Kriesen-?)Kundenbetreuung an, um mit den Auftraggeberinnen zu sprechen. Quintessenz war dann wohl, daß das Einschreiben doch schon durch die Alice-internen Abläufe nach oben gespühlt wurde (ich glaube, die Frist war da zwei(?) Wochen abgelaufen?) und man sich für den Ablauf zu entschuldigen suchte. (Einsehend, daß man einen Monat Unerreichbarkeit schwerlich ungeschehen machen könne; immerhin.) Mit kleinen Erlaß-Gesten und einer »beschleunigten« Alice-Mobile-Bestellungs-Ausführung möchte man die Wogen glätten.
Kommentar: ich finde es erschreckend, wie langsam diese Mühlen mahlen, insbesondere, wenn ich bedenke, daß ich seit Abschaltung des Analog- und Nichtschaltung des Alice-Anschlusses in der ersten Woche fast täglich, in der zweiten schriflich und müdlich im Wechsel keinen Hehl aus der Unzumutbarkeit des Verhaltens von Alice seinem Kunden gegenüber gemacht habe. Und ich muß leider davon ausgehen, daß ohne das Einschreiben mit Rückschein es nicht einmal diesen Anruf – der ja auch nichts ungeschehen machen kann; immerhin schien man das verstanden zu haben – gekommen wäre. Nunja. Mitte nächster Woche sind zwei Wochen rum, ich bin gespannt, ob die angeblich automatische Schaltung des ADSL2+-16-MBit-Profils auch wirklich stattfindet (und wie; das Modem trennt die DSL-Verbindung ja nicht von sich aus, und da am DSL die NGN-Telefonie hängt, würde ich ja schon erwarten, daß man die Schaltung mit dem Anschlußinhaber koordiniert, damit keine telefonische Unerreichbarkeit aufgrund von DSL-Problemen resultiert. Aber auch hier fokussiere ich wahrscheinlich zu sehr auf die Kundeninteressen …).
ip_conntrack my $whatever
*sigh* Das hat jetzt doch etwas gedauert.
Lessons learned 1: Nicht noch schnell vor’m Schlafengehen eine zweite Kiste aufsetzen mit munterem copy-and-paste der Konfiguration.
Nicht alles, was außerhalb des LANs sinnvoll ist, funktioniert genausogut innerhalb des LANs; also zum Beispiel jetzt das lokale Netz über den OpenVPN-Tunnel zu jagen ist i. d. R. kontraproduktiv und führt zu sehr selektiver Dysfunktion … Nicht wirklich hilfreich ist es ferner, diese Tunnel mit identischen (war ja nur’n schneller Test) Credentials aufzubauen und munter IP- und Socket-Adressen mit bestehenden Tunneln zu verzwurbeln. Da wird dann der Tunnel einseitig established, dank des identischen Schlüssels kommen auch Pakete an; leider auf dem falschen Tunnelendpunkt, die Kommunikation war arg einseitig.
Lessons learned 2: NAT ist böse. Also nicht so böse, wie IPv6-Protaginisten z. B. bei Heise schreiben, aber schon böse, wenn ip_conntrack lustig auf die alte T-Online-IP nattet, obwohl das schon die von (Vor-)Vorgestern ist.
tcpdump auf Fritz!Boxen hat schon was; da sieht man dann endlich, daß die Pakete, die auf dem Tunnelgegenüber rausgehen, nicht ankommen. Und wenn man dann – mit etwas Ruhe – dann darauf kommt, daß man irgendwo in der Tunnelaufbauphase wohl gucken muß, warum die Pakete, die lt. tcpdump auf dem Tunnelendpunkt von der Fritz!Box ankommen und mit korrekten Antwort-IP auch wieder in diesem Tunnel zur Fritz!Box verschwinden, letztlich nicht im Tunnel auf der FB ankommen.
Skizze? Skizze:
LAN ppp0 RZ-LAN [Fritz!Box_________[Router]________[Internet]________[OpenVPN-Server] \_________________________________________________/ OpenVPN-Tunnel 192.168.5.248 zu 195.... (ovpn: ifconfig 192.168.44.8 192.168.44.9)
Eigentlich simpel das Ganze. Die Fritz!Box baut einen OpenVPN-Tunnel auf, sie hat im LAN eine RFC1918-Adresse. Der Router (angejahrtes full-blown-Linux-System, Kernel 2.4) macht für die RFC1918-Adressen ein SNAT auf die aktuelle ppp0-IP (via /etc/ppp/ip-*.local) und schickt das Paket auf Reisen über ppp0. Auf dem OpenVPN-Server hat – für dieses Szenario – jede Verbindung ihren eigenen OpenVPN-Daemon und mithin ein dediziertes Socket, sprich IP & Port. Kommuniziert wird normalerweise über UDP, fallweise auch mal über TCP. Rennt hammergeil – eigentlich. Nur die Fritz!Box, die ich zwischen T-ISDN und meinen heimischen S0-Bus gehängt habe und die nun auch lustige VoIP-Geschichet, teils zu anderen FBs, teils über einen zentralen Asterisk, macht plötzlich Probleme.
Gut, nach längeren Suchen stieß ich drauf, daß zwei Routen zum gleichen Ziel, eines directly connected, eines über den Tunnel (der über das directly connected LAN liefe) eher kontraproduktiv sind (Lesson 1).
Jetzt aber, ums verrecken tut der eine Tunnel nicht, der zum obigen Setup. (Die FB unterhält noch einen zweiten Tunnel zum zentralen Asterisk, primär um SIP durch die NAT-Welt da draußen zu bekommen, sekundär aber auch zwecks Erhöhung der Privatheit der Kommunkation. Anyway, der Tunnel rannte schon immer.)
Nach langem Gedumpe kam ich dann drauf zu verifizieren, ob denn der Tunnelaufbau überhaupt klappt oder ich vielleicht an völlig falscher Stelle debugge. Und irgendwann fiel’s mir wie Schuppen aus den Haaren: die Pakete gehen korrekt raus. Äh, halt, da stimmt doch die IP der anderen Tunnelseite nicht‽
08:42:18.273448 IP 195....10000 > 93.217.189.219.10000: UDP, length 60
Tja, leider; mittlerweile hatte es mind. 1 Zwangstrennung gegeben, aber davon wollte ip_conntrack nichts wissen:
root@router:~ # grep 189.219 /proc/net/ip_conntrack tcp 6 137482 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=36553 dport=443 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=443 dport=36553 [ASSURED] use=1 tcp 6 101822 CLOSE_WAIT src=192.168.5.108 dst=XXX.XX.XXX.XXX sport=36398 dport=5228 src=XXX.XX.XXX.XXX dst=93.217.189.219 sport=5228 dport=36398 [ASSURED] use=1 tcp 6 94463 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=60622 dport=443 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=443 dport=60622 [ASSURED] use=1 tcp 6 137480 CLOSE_WAIT src=192.168.5.108 dst=XX.XXX.XX.XXX sport=52715 dport=80 src=XX.XXX.XX.XXX dst=93.217.189.219 sport=80 dport=52715 [ASSURED] use=1 tcp 6 322804 ESTABLISHED src=192.168.5.108 dst=XXX.XX.XXX.XXX sport=53735 dport=5228 src=XXX.XX.XXX.XXX dst=93.217.189.219 sport=5228 dport=53735 [ASSURED] use=1 udp 17 172 src=192.168.5.247 dst=195... sport=10000 dport=10000 src=195... dst=93.217.189.219 sport=10000 dport=10000 [ASSURED] use=1 [...]
Unter anderem die OpenVPN-Links standen noch munter mit der alten externen IP dort; wieso einige TCP-Verbindungen angeblich noch ESTABLISHED sein sollen, wo doch die externe IP nun ganz woanders endet – ich weiß es nicht. Tendentiell wäre das mit TCP schon aufgeflogen, da der Tunnel sich nicht hätte aufbauen können (Three-Way-Handshake); da ich aber UDP nutze, bekommt der OpenVPN-Server ein gültiges Paket von der falschen (falsch genatteten) Adresse, das reicht für den Tunnelaufbau. Pakete von der Fritz!Box kamen auch an, nur die Antwortpakete gingen an die falsche Zieladresse — was OpenVPN auch berichtete:
Jul 23 07:58:50 azrael openvpn[4711]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Lessons learned 3: Auch mal ‘nen Layer hochschauen. Wenn der Tunnel einseitig tut, nicht im Tunnel den Fehler suchen oder im Routing oder vermuteten Filtern, sondern auch mal ins syslog gucken …
Eigentlich war jede Info da; es hätte schneller gehen müssen, aber so ist das, wenn schon verkorkst, dann richtig :( Der Trigger für mich war die syslog-Meldung (nach Neustart des Tunnels auf der Britz!Box):
Jul 23 07:58:50 azrael openvpn[4711]: Peer Connection Initiated with 93.217.189.219:10000 Jul 23 07:58:50 azrael openvpn[4711]: Initialization Sequence Completed Jul 23 07:58:50 azrael openvpn[4711]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Also Verbindung hergestellt und sofort wieder EHOSTUNREACH, wie kann das sein, zumal Pakete reinkommen?
Die Überprüfung der iptables-Einstellungen ergab … nichts; da war die korrekte IP als SNAT-Ziel eingestellt. Also ab, herausfinden, wie das NATing eigentlich funktioniert und auf /proc/net/ip_conntrack gestoßen. Nach längerem Googlen stellte sich einerseits heraus, daß sowas wohl gelegentlich vorkommt beim 2.4er Kernel, bei 2.6 wird derlei wohl wieder anders gehandhabt. Und die oft propagierte Lösung lautet: Modul entladen — was bei einem Router mit n Interfaces nur wegen der technisch unnötigen T-Online-24h-Zwangstrennung eher no go ist.
Zum Glück fand’ sich ein Lösungsansatz aus 2005 (für jemanden, der das Problem mit seinem OpenWRT-Router offensichtlich auch hat); ich habe ihn ausprobiert …
UDPTO=`cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout`; UDPTOSTREAM=`cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream` ; echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream && echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout && sleep 10 && echo ${UDPTOSTREAM} > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream && echo ${UDPTO} > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
… und, juhee, die alten UDP-Einträge sind futsch und wie von Zauberhand rennt der Tunnel:
traceroute to 192.168.45.1 (192.168.45.1), 30 hops max, 38 byte packets 1 192.168.44.9 (192.168.44.9) 44.464 ms 45.643 ms 45.539 ms 2 192.168.45.1 (192.168.45.1) 97.082 ms 95.747 ms 96.096 ms
Tja, reif für die Insel würde ich sagen :( Warum noch immer da TCP-Sessions als ESTABISHED stehen, wo ich das fragliche Endgerät im LAN doch schon vor ‘ner halben Stunde abgeschaltet habe — ich weiß es nicht und derzeit ist es mir auch eher egal; ein 2.6-basierter neuer Router ist schon am Betatest, insofern wird’s obige Zeile in der ip-up.local wohl für die nächste Zeit tun. NAT an sich finde ich gar nicht schlimm oder schlecht; nur, wenn sowas dazu kommt, dann wird’s haarig ;)
Respekt …
… muß ich dann mal wieder Google zollen: sie hosten da ein Projekt, für welches es für ihr eigenes Handy-OS, Android, keine Clients gibt. #fail auf der einen Seite, aber irgendwie auch so angenehm un-Apple …