Alice (Spharion) IAD 3231 – ICMP geblockt?

Im Großen und Ganzen bin ich nun fast zufrieden mit der Alice-Lösung; der bisherige Ablauf war unter aller Kanone, aber nun gut, warten wir mal ab — zumal ja Telefónica in den Übernahmestartlöchern stehen soll.
Nur eines nervt ganz gewaltig: Die eierlegende Wollmilchsau (IAD) von Alice scheint ICMP-Pakete generell nicht durchzulassen. Von der Fritz!Box hinter dem Alice-IAD sieht es wie folgt aus – und mit einem Laptop direkt am IAD nicht anders –; zuerst über den Fernwartungstunnel in mein Netz:

# uname -a
Linux fb7170-1 2.6.13.1-ohio #1 Mon Feb 16 13:02:19 CET 2009 mips unknown
# traceroute death.uu.org
traceroute to death.uu.org (192.251.226.52), 30 hops max, 38 byte packets
1 192.168.44.9 (192.168.44.9) 54.712 ms 52.176 ms 53.866 ms
2 igor-adsl2.uu.org (193.26.120.250) 90.384 ms 89.076 ms 91.009 ms
3 death.uu.org (192.251.226.52) 138.244 ms 91.496 ms 93.955 ms

Fein, fein. Leider geht’s über die IAD eben nicht:

# traceroute blogdoch.net
traceroute to blogdoch.net (192.251.226.27), 30 hops max, 38 byte packets
1 alicebox (192.168.1.1) 2.825 ms 1.485 ms 1.474 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
[...]
25 * * *
26 * * *
[...]

Ping hingegen funktioniert, hier scheint man ein Einsehen gehabt zu haben:

# ping -c 5 death.uu.org
PING death.uu.org (192.251.226.52): 56 data bytes
64 bytes from 192.251.226.52: seq=0 ttl=62 time=91.086 ms
[...]
— death.uu.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 90.662/92.363/97.007 ms
# ping -c 5 blogdoch.net
PING blogdoch.net (192.251.226.27): 56 data bytes
64 bytes from 192.251.226.27: seq=0 ttl=57 time=50.051 ms
[...]
— blogdoch.net ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 49.863/51.082/54.917 ms

Die versteckten Konfigurationsseiten habe ich schon durch; Firewall und ICMP-Filter sind ausgeklickt und bleiben es nach Reload auch, aber an der Nicht-Funktion ändert sich nichts :(
Ideen, irgendwer? (Außer wieder mal die Hotline zu nerven?)

Donnerstag

Ja, heute muß Donnerstag sein … Donnerstage sind nicht so meins.
Also, ja, der Alice-Techniker, der in Wirklichkeit von der T-Com war und nur auf die alte BiTel-Dose (wo das Alice-IAD schon tapfer DSL gesynct hatte um 11:40, als ich mich aufmachte, erwartend, es käme nun doch kein Techniker mehr, mal die vorhandenen TAE-Dose mit Alice’ IAD zu beglücken) die Alice-Comfort-DSL-Leitung am Hausverteiler umklemmte, der war da. Und die von QSC gelieferte DSL-Infrastruktur tut auch soweit — mittlerweile leuchtet die »Internet«-LED am IAD (Intgrated Access Device, DSL-Modem, Router, Switch und ISDN-/Analog-zu-VoIP-im-PVC-Gateway) auch.
Leider war die Inbetriebnahme alles andere als simpel; während der T-echniker freundlicherweise mit seinem Allzweckhörer über die Analogports des IAD die Voicefreischaltung (bei Alice muß man einen Code endweder im IAD hinterlegen oder aber vor dem ersten Telefonat eintönen) machte, tippte ich zum vierten oder fünften Male die olle, schriftliche mitgeteilte, Benutzerkennung »@alice-dsl.de« ins entsprechende Feld der IAD-Weboberfläche (die ich über ein »ifconfig eth0 192.168.1.2 up broadcast« erst erreichbar machen mußte — für die Einrichtung eines Internetzuganges Windows zu booten, ist dann doch unter meinem Niveau –; leider machte das IAD initial kein DHCP). Close … but no cigar.
Telefonie ok, Internet rot. Mierda. Gut, alles auf Anfang, es gibt einen – ohne Warnungen zu nutzenden – Menüpunkt »Werkseinstellungen« im IAD. Gelesen, geklickt.
IAD-Assistenten durchlitten, Telefoniefreischaltnummer eingegeben, angenommen – Telefonie-LED bleibt unterkühlt dunkel. Fickschweinkacke; aber weiter: Internetzugangsdaten doppelt und dreifach überprüft nochmals eingegeben – Internet: rot. Gnagnagna. Hilfreich übrigens, das »aus Sicherheitsgründen« keines der Passwörter angezeigt wird, auch nicht – wie bei der Fritz!Box – wahlweise. Kann man super Fehler finden …
Also – ich hatte ja mein HSDPA-Internet dabei – Alice-Kundenseite aufgerufen, dortige Hotline-Nummer zu diesem Vertrag angewurfen — es war die falsche, aber immerhin, man verband mich als »Comfort-« (und Business-) Kunden weiter an die richtige Hotline.
Ich: Hallo erstmal, ich brauch’ wohl neu Zugangsdaten …
Alice: Ah, welche nutzen Sie denn?
I: Na, die, die sie mir geschickt haben, …@alice-dsl.de.
A: Ahja, da hat der Computer leider einen Fehler gemacht, da fehlt noch ein -office nach alice.
I: [Schimpfworte zurechtleg für’ spätere Nicht-Niederschrift im Blog] Äh. Ah. Aaaaalso, heißt das @alice-office-dsl.de?
B: Ja.
I: Na super. Kein Wunder, daß das nicht ging … Gut, und ich brauche dann wohl eine neue Voice-PIN…
A: Wieso das denn?
I: Naja, nachdem das nicht ging, habe ich die IAD auf die Werkseinstellungen zurückge…
A: DAS SOLLEN SIE DOCH AUCH NICHT!
I: Äh, nicht? Da steht nicht, daß man das nicht soll, und da es mit der Anmeldung …
A: Aber dafür haben Sie doch die Hotline! Da kann ich jetzt auch nichts machen, das System [tut irgendwas, was ich weder verbal noch im Kontext verstanden habe] um 16 Uhr.
I: Und was heißt das? Telefonie ist jetzt tot… [“Jetzt” heißt: 12:46 ..]
A: Vor 16 Uhr kann ich da nichts machen!
I: Also muß ich jetzt ohne Telefon bis 16 Uhr warten — und dann nochmal anrufen, wenn’s immernoch nicht wieder geht?
A: Ja. Vor 16 Uhr kann ich da nichts machen, das System [und wieder habe ich es nicht verstanden; vielleicht auch eine Hörblockade bei mir …]
I: Na, dann hoffentlich auch nicht wiederhören um 16 Uhr, Danke. *klack*
Da wurd’ die doch richtig pampig, als ich sagte, ich hätte das IAD zurückgesetzt‽ Hallo? Liebe Alice, wenn Ihr nicht wollt, daß man sowas macht, dann sperrt doch auch den Zugriff auf diese Funktion, wie Ihr das ja mit zu ziemlich allem getant habt, was man als Enduser von seinem Modem-Router gerne erfahren würde (wie z. B. DSL-Parameter (vgl. Hansenet-User-Forum) …). Was für Sumpfdotterblumen, ehrlich.
Die fehlerhaften – schrftlichen – Zugangsdaten, zu deren Korrektur die Realisierungszeit dieses DSL-Zuganges von satten zwei Monaten(!) – fünf Wochen über dem Server-Versprecher-Versprechen von drei Wochen – nicht gereicht hat, mal ganz außen vor gelassen. Hätte Alice korrekte Daten geliefert, wäre das eine Sache von 5 Minuten statt 50 plus Anschiß von der Hotline gewesen. Business-Service, fürwahr.
Und der nächste Klopfer sind dann die rd. 6 MBit/sec des »maximal mögliche Bandbreite«-Anschlusses, wirbt Alice doch ganz anders:

Alice stellt bei allen Produkten immer die maximal mögliche Bandbreite von bis zu 16.000 kbit/s zur Verfügung.
Die tatsächliche Geschwindigkeit einer DSL-Leitung ist von verschiedenen technischen Faktoren abhängig, auf die kein DSL-Anbieter Einfluss nehmen kann. Hauptsächlich hängt sie von der Entfernung (Leitungslänge) Ihres Hauses zum nächstgelegenen DSL-Netzknoten ab oder ob Sie per WLAN oder Kabel ins Internet gehen

 
Naja, T-Com bewirbt hier VDSL und DSL16plus; das Alice-IAD sagt, die Dämpfung läge in dem Bereich, wo lt. Wikipedia rd. 18 MBit/sec noch drin sein sollten bei ADSL2+ …
Naja, ich habe mittlerweile auch nichts anderes mehr erwartet; mal sehen, wie stabil Internet und NGN-Telefonie sind …
Um den Tag abzurunden teilte mir die Telekom heute per »Auftragsbestätigung zu Ihrem Auftrag vom 13.07.09« mit, daß sie auf meinen angeblichen Wunsch hin zum 31.07.09 mir VDSL 25 abschalten und DSL16plus schalten würden. Telefonisch geklärt und storniert, zumal ich am 13.07.09 mit keiner Vertreternase gesprochen habe — das war drei, vier Wochen vorher und es ging um einen VDSL25-Neuvertrag zu günstigeren Konditionen. N-a-r-f-! Nicht mein Tag, dieser Donnerstag …

Fritz!Box 7240 als UMTS-Router mit openvpn …

Ich merkte es grade nur zufällig beim Debugging meines IMAP-Servers: die openvpn-Verbindung (die Binaries werden gem. the-construct.com-Methode nach dem Start aus dem Netz nachgeladen) in mein Heimnetz funktioniert 1A ;)

traceroute to mail.uu.org (192.251.226.42), 64 hops max, 40 byte packets
1 fritz.box (192.168.178.1) 1 ms 1 ms 1 ms
2 192.168.78.2 (192.168.78.2) 122 ms 118 ms 128 ms
3 igor-adsl2.uu.org (193.26.120.250) 152 ms 158 ms 168 ms
4 famine.uu.org (192.251.226.48) 140 ms 190 ms 160 ms
5 mail.uu.org (192.251.226.42) 168 ms 157 ms 152 ms

Schon lustig, und zudem trivial, verglichen mit Gefrickel an La Fonera 2.

Fast schon DSL …

… wobei es bei dieser Mobilfunkanbindung, genau wie bei den Satellitenangeboten (»skyDSL« und wie sie alle heißen), ja schon etwas an der Line fehlt (DSL = Digital Subscriber Line) :)
Wenn’s jetzt noch ‘nen Tarif gäbe, z. B. für 10,–/Monat, der über HSPA pauschalen Internetzugang ermöglicht (im Preis ist ein Kontingent (300-500 MB) enthalten, bei Überschreitung greift dann eine Gebührenbremse in Form der automatischen Buchung, z. B. für den laufenden und den Folgemonat, der 5-GB-Flatrate für max. 20,–), dann könnte es sogar sein, daß hier, wo nur ein alter PC fernab des Analoganschlusses sein Dasein fristet, für dies und das nachzugucken ein stetiger Internetzugang gebucht würde. Na, Vodafone, das wäre doch mal ein innovatives Angebot? o2 hat derlei mit FONIC/Tchibo fast schon …

Regressions …

Wie geil ist das denn? Beim Test meines Huawei E160-USB-3G-Modems unter Ubuntu Jaunty Jackass (9.04) brach der blöde Network-Manager ins Essen:

Jul 7 14:36:05 greebo pppd[23125]: pppd 2.4.5 started by root, uid 0
Jul 7 14:36:05 greebo pppd[23125]: Using interface ppp0
Jul 7 14:36:05 greebo pppd[23125]: Connect: ppp0 <--> /dev/ttyUSB0
Jul 7 14:36:05 greebo pppd[23125]: Unable to obtain CHAP password for greebo on UMTS_CHAP_SRVR from plugin
Jul 7 14:36:05 greebo pppd[23125]: No CHAP secret found for authenticating us to UMTS_CHAP_SRVR
Jul 7 14:36:05 greebo pppd[23125]: CHAP authentication succeeded
Jul 7 14:36:05 greebo pppd[23125]: CHAP authentication succeeded
Jul 7 14:36:08 greebo pppd[23125]: Could not determine remote IP address: defaulting to 10.64.64.64
Jul 7 14:36:08 greebo pppd[23125]: Cannot determine ethernet address for proxy ARP
Jul 7 14:36:08 greebo pppd[23125]: local IP address 10.46.25.184
Jul 7 14:36:08 greebo pppd[23125]: remote IP address 10.64.64.64
Jul 7 14:36:08 greebo pppd[23125]: primary DNS address 193.189.244.205
Jul 7 14:36:08 greebo pppd[23125]: secondary DNS address 193.189.244.197
Jul 7 14:36:08 greebo postfix/master[2715]: reload configuration /etc/postfix
Jul 7 14:36:21 greebo NetworkManager: <WARN> pppd_timed_out(): Looks like pppd didn't initialize our dbus module
Jul 7 14:36:21 greebo NetworkManager: <info> (ttyUSB0): device state change: 5 -> 9
Jul 7 14:36:21 greebo pppd[23125]: Terminating on signal 15
Jul 7 14:36:21 greebo NetworkManager: <debug> [1246970181.004966] nm_serial_device_close(): Closing device 'ttyUSB0'
Jul 7 14:36:21 greebo pppd[23125]: Connect time 0.3 minutes.
Jul 7 14:36:21 greebo pppd[23125]: Sent 0 bytes, received 0 bytes.
Jul 7 14:36:21 greebo NetworkManager: <info> Marking connection 'Tschibo' invalid.
Jul 7 14:36:21 greebo NetworkManager: <info> Activation (ttyUSB0) failed. 

Eigentlich mag ich den Komfort von Network-Manager, mit zunehmendem Alter hat man’s nicht mehr so mit ellenlangen Kommandozeilenorgien, nur um im nächsten Ort mit freiem WLAN wieder Zugang zu bekommen — man lernt den Komfort, den Windows XP hier brachte, einfach zu schätzen. (Auf der anderen Seite war es all’ den Ärger, den Network-Manager mir in den letzten Jahren gemacht hat, eigentlich nicht wert. Nunja.)
Etwas herumgegoogled, auf Bug #371291 gestoßen. Geflucht, die Settings ausprobiert, keine Änderung. Kurz vor dem das-Laptop-an-die-Wand-werfen doch mal im xterm mit »su -« ein »exit« eingegeben:

Jul 7 15:47:04 greebo pppd[25403]: pppd 2.4.5 started by root, uid 0
Jul 7 15:47:04 greebo pppd[25403]: Using interface ppp0
Jul 7 15:47:04 greebo pppd[25403]: Connect: ppp0 <--> /dev/ttyUSB0
Jul 7 15:47:04 greebo NetworkManager: <debug> [1246974424.570514] nm_ppp_manager_start(): ppp started with pid 25403
Jul 7 15:47:04 greebo NetworkManager: <info> Activation (ttyUSB0) Stage 2 of 5 (Device Configure) complete.
Jul 7 15:47:04 greebo NetworkManager: <info> (ttyUSB0): device state change: 5 -> 6
Jul 7 15:47:04 greebo pppd[25403]: CHAP authentication succeeded
Jul 7 15:47:04 greebo pppd[25403]: CHAP authentication succeeded
Jul 7 15:47:04 greebo NetworkManager: <info> (ttyUSB0): device state change: 6 -> 7
Jul 7 15:47:12 greebo pppd[25403]: Could not determine remote IP address: defaulting to 10.64.64.64
Jul 7 15:47:12 greebo pppd[25403]: Cannot determine ethernet address for proxy ARP
Jul 7 15:47:12 greebo pppd[25403]: local IP address 10.46.18.151
Jul 7 15:47:12 greebo pppd[25403]: remote IP address 10.64.64.64
Jul 7 15:47:12 greebo pppd[25403]: primary DNS address 193.189.244.205
Jul 7 15:47:12 greebo pppd[25403]: secondary DNS address 193.189.244.197
Jul 7 15:47:12 greebo NetworkManager: <info> PPP manager(IP Config Get) reply received.
Jul 7 15:47:12 greebo NetworkManager: <info> Activation (ttyUSB0) Stage 4 of 5 (IP Configure Get) scheduled...
Jul 7 15:47:12 greebo NetworkManager: <info> Activation (ttyUSB0) Stage 4 of 5 (IP Configure Get) started...
Jul 7 15:47:12 greebo NetworkManager: <info> Activation (ttyUSB0) Stage 5 of 5 (IP Configure Commit) scheduled...
Jul 7 15:47:12 greebo NetworkManager: <info> Activation (ttyUSB0) Stage 4 of 5 (IP Configure Get) complete.
Jul 7 15:47:12 greebo NetworkManager: <info> Activation (ttyUSB0) Stage 5 of 5 (IP Configure Commit) started...
Jul 7 15:47:12 greebo postfix/master[2715]: reload configuration /etc/postfix
Jul 7 15:47:13 greebo NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS.
Jul 7 15:47:13 greebo NetworkManager: <info> (ttyUSB0): device state change: 7 -> 8
Jul 7 15:47:13 greebo NetworkManager: <info> Activation (ttyUSB0) successful, device activated.
Jul 7 15:47:13 greebo NetworkManager: <info> Activation (ttyUSB0) Stage 5 of 5 (IP Configure Commit) complete.
Jul 7 15:47:14 greebo postfix/master[2715]: reload configuration /etc/postfix
[...]
Jul 7 16:04:22 greebo NetworkManager: <info> (ttyUSB0): device state change: 8 -> 3
Jul 7 16:04:22 greebo NetworkManager: <info> (ttyUSB0): deactivating device (reason: 0).
Jul 7 16:04:22 greebo NetworkManager: <debug> [1246975462.358644] nm_serial_device_close(): Closing device 'ttyUSB0'
Jul 7 16:04:22 greebo pppd[25403]: Terminating on signal 15
Jul 7 16:04:22 greebo pppd[25403]: Connect time 17.2 minutes.
Jul 7 16:04:22 greebo pppd[25403]: Sent 534924 bytes, received 14574132 bytes.

Mein einziger Trost ist, daß ich für diese Software nicht bezahle; würde ich dafür bezahlt haben, hätte ich wieder Hannibal-Lecter-Gelüste gegenüber dem Hersteller …
Ich nutze seit ca. 5 Jahren, mindestens seit 5 Jahren, eigentlich immer eine xterm-Session mit “su -” auf meinen Arbeitsplatzrechnern, einfach, weil ich dies und jenes mal brauche und ein NOPASSWD-Eintrag für meinen Hauptnutzer in der sudoers weniger sicher finde als einen root-Login. Ich weiß nicht, was »sie« in 9.04 wieder hypergeiles eingebaut haben, daß als Nebeneffekt eines angemeldeten UID-0-Nutzers Network-Manager nicht mehr vernünftig funktioniert — sicher bin ich mir indes, daß keine Ursachenforschung und keine Fehlerbehebung für 9.10 zu erwarten ist: es gibt ja ‘nen Workaround. Es gibt Tage in »meinem Leben mit Linux«, da möchte ich einfach nur schreien … :(

Why, oh why?

Hach ja … Ich schrieb ja – der aufmerksame Blog-Leser zumindest wird sich erinnern – jüngst, daß ich eine »Alice-Unfähigkeitsüberbrückung« mittels einer Fonera 2 und Tchibos Pre-Paid-3G-Flat realisieren will.
Mit einer Prerelease der Fonera-2-Firmware rannte mein Huawei E160 denn auch schon – und, anders als unter Ubunty Jaunty Jackass, war gleichzeitig auch die Micro-SD im E160 ansprechbar *sigh* –, aber bei rund 1 MBit/sec war Schluß. Da es einen entsprechenden Bugreport bzw. Bugfix-Eintrag für spätere Releases gibt, ließ ich die finale Firmware installieren — weitere 30 Minuten meines Lebens, die mehr zweckfrei entronnen sind: Die GUI-Helden der Fonera-2-Firmware haben die Eingabemasken für APN, PIN, Username und Passwort bei 3G rückstandslos ersetzt durch ein Dropdown mit einer endlichen – aber eben systembedingt unvollständigen Liste, die Einstellugen z. B. für Tchibo (APN: webmobil1) oder FONIC (APN: pinternet.interkom.de oder sowas) fehlen und manuelle Einstellung/Änderung der Voreinstellung ist offensichtlich auch im geladenen Developer-Image nicht vorgesehen. Hut ab vor sowie … »Weitsicht« :(
Derzeit flasht sich die Fonera 2 auf 2.2.6 RC2, in der vagen Hoffnung, man habe den Irrweg erkannt. Falls nicht, bleibt Downgrade (und Limit auf 1 MBit/sec) oder – Use The Source, Luke! – das backen der eigenen Firmware. Ein weiterer Eintrag in die Hall of Fame unter der Überschrift »mal eben schnell« :(
[Update] Man spare sich die Installation von 20090528_FON2202_2.2.6.0_rc2.tar.gz, funktional hat sich am UMTS/3G-Teil nichts geändert :( [/Update]

Neues vom bloden schönen DSL-Fräulein

Während ich so auf des Firmwareupdate einer meiner (Developer-) La Fonera 2.0 warte – das dauert so seine 30 Minuten – und online über eben jenen »Social Router« und Tchibos 19,95-€-5-GB/Monat-dann-Drosselung-3G-Flatrate bin, merke ich, daß ich noch ein Update zurm leidigen Thema »Alice und die nicht stattfindende DSL-Schaltung« schuldig bin …
Denn es begab sich, daß unsere italienische Freundin sich am 26.06.2009 (Eingang: 04.07.09) Zeit nahm, auf »Ihre Anfrage vom 17.06.2009« zu antworten. Also so schriftlich, mit augenscheinlich echten Kugelschreiberunterschriften.
Selbst ein reitender Bote hätte das vor 100 Jahren wohl schneller von Hamburg nach Gütersloh transportiert, aber, wie gelernt, allzuviel verlangen darf man wohl nicht bei einem Unternehmen, welches mit einer hübschen Frau für ein sehr technisches Produkt wirbt. Wie dem auch sei, die Quintessenz dieses langen Reifeprozesses lautet wie folgt:

Bezüglich der bereits abgeschalteten Rufnummer, bzw. des abgeschalteten Anschlusses […] bei der Deutschen Telekom, können wir Ihnen mitteilen, dass dieser nicht von uns zum jetzigen Zeitpunkt gekündigt wurde, sondern erst zum tatsächlichen Zeitpunkt der Rufnummern- und Leitungsübernahme. Bitte richten Sie eventuell anfallende Schadensansprüche an den verantwortlichen Anbieter.

 
Doh! Sollte ich der hübschen Italienerin Unrecht getan haben? Naja, selbst, falls diese Aussage stimmen würde – die Terminfreiheit des initialen Telekom-Schreibens könnte diese Annahme stärken –, der Auftragnehmer war nun einmal Alice und außer Alice kann – lt. Aussage der Telekom – grade keiner was tun bzgl. der Rufnummer. Insofern sehe ich Alice alles andere als »vom Haken« bzgl. Schadensersatzforderungen; mit der Telekom hatte die auftraggebende Praxis ja kein Vertragsverhältnis, mit Alice schon. IANAL, meiner billigen und gerechten Auffassung nach müßte der Ablauf aber wie folgt sein: Auftragsgeber verklagt Alice, bekommt Recht; Alice verklagt dann die Telekom auf Ersatz des Schadensersatzes?
Egal, der gereichte Schwarze Peter wurde schon am Wochenende an die Telekom eingeschrieben und vorab gefaxt, mal gucken, ob da nun endlich mal jemand zum Telefonhöhrer greift und mit Alice klärt, warum 6 Wochen nach Auftragserteilung noch keine Leitung bereitgestellt wurde von der Telekom für Alice.
Ach so; was ich mit der Fonara 2.0 und ‘ner 3G-Flatrate mache? Nunja, da Alice absehbar nichts liefern wird – und auch zu servicewüstig ist, von sich aus auf die Idee zu kommen, z. B. über Mobilfunk eine provisorische Erreichbarkeit und Surfgelegenheit bereitzustellen –, wird’s Zeit für einen Plan B: Internet-Zugang und sichere LAN-Kopplung müssen langsam mal eingerichtet werden, also habe ich am Samstag einen (weiteren) Huawei E160 samt SIM (hier: Tchibo; ebenfalls das o2-Netz nutzend) gekauf und bringe derzeit meinen Spare-Fonera 2.0 als Alice-Ersatz an den Start. Die dahinter geschaltete Fritz!Box wird sich dann über OpenVPN mit meinem Netz verbinden und alles wird gut. Bis auf die massiv erhöhten Telefoniekosten, da die Anrufe auf die einzig verbliebene Rufnummer der Praxis nun auf Privathandies parallel signalisiert werden müssen (statt per VoIP-over-VPN für lau). Aber diesbezüglich begeben wir uns dann später in Gottes Hand, sprich auf den Rechtsweg …

Briefpapier pimpen for run-aways

Wie das nun einmal so ist … Da gibt es ein benötigtes Programm (ein Abrechungsprogramm für Heilpraktiker), welches entweder bißchen Text und notfalls noch ‘n Logo zusammen mit dem Abrechnungstext drucken kann — oder aber nichts dergleichen, wenn man richtiges Briefpapier, so altmodisch in schwerer und bedruckt, verwendet.
Nun mag man sich aber auch für Briefpapier mit Logo und so entscheiden, welches anlaßabhängig als Informationsschreiben, Aushang, Rechnung, … der verschiedenen in der Praxisgemeinschaft agierenden Heilpraktikern verwendet werden kann. Die Pflichtangaben bei Heilpraktikern sind etwas anders als bei z. B. ‘ner GmbH und der subtile Unterschied zwischen Seite 1 und den folgenden Seiten wird spätestens dann läßtig, wenn man mangels multipler Einzugsschächte dauernd das Papier wechseln müßte. Abgesehe davon ist auch der papierne Durchsatz einer Naturheilpraxis nicht so hoch, daß n-tausend Blatt nur so durch den Drucker rauschten …
Wie auch immer, das Problem war nun, daß auf das mit Logo, Anschrift, Namen und Kommunikationsadressen versehene Briefpapier nun jene Abrechnungen gedruckt werden sollten. Mit Praxisadresse usw. druckt das fragliche Programm die Absenderzeile für Fenster-Briefumschläge, die Bankverbindung — aber eben auch einerseits doppelt und andererseits über den vorbedruckten Bereich die Praxisdaten (Name, Anschrift, …).
Alternativ kann das Programm eben auch nur die Adresse und die entsprechenden Abrechungsdaten drucken — dann fehlen bei diesem Briefpapier aber die Absenderzeile für Fenster-Briefumschläge sowie die Bankverbindung. Hrmpft.
Klar kann man jetzt einfach mit OpenOffice’ »Writer«-Anwendung diese Daten platzieren, das Praxisbriefpapier in einem ersten Durchlauf damit bedrucken und schließlich dieses vorpräparierte Papier zur Rechnungsdruck verwenden. Finde ich aber plöd; sowas sollte ich auch automatisch gehen, irgendwie‽
Und tatsächlich, die quick-and-dirty-Lösung geht über cups-pdf, einen Ausdruck-nach-PDF-Datei-Druckertreiber und pdftk, dem coolen PDF-Toolkit:

If PDF is electronic paper, then pdftk is an electronic staple-remover, hole-punch, binder, secret-decoder-ring, and X-Ray-glasses. Pdftk is a simple tool for doing everyday things with PDF documents. Keep one in the top drawer of your desktop and use it to:

  • Merge PDF Documents
  • Split PDF Pages into a New Document
  • Rotate PDF Pages or Documents
  • Decrypt Input as Necessary (Password Required)
  • Encrypt Output as Desired
  • Fill PDF Forms with FDF Data or XFDF Data and/or Flatten Forms
  • Apply a Background Watermark or a Foreground Stamp
  • Report on PDF Metrics such as Metadata, Bookmarks, and Page Labels
  • Update PDF Metadata
  • Attach Files to PDF Pages or the PDF Document
  • Unpack PDF Attachments
  • Burst a PDF Document into Single Pages
  • Uncompress and Re-Compress Page Streams
  • Repair Corrupted PDF (Where Possible)

Pdftk allows you to manipulate PDF easily and freely. It does not require Acrobat, and it runs on Windows, Linux, Mac OS X, FreeBSD and Solaris.

 
Wieder was dazugelernt; pdftk lernte ich erst bei der gestrigen Google-Session nach Lösungen für mein Problem kennen. Mit diesen beiden Bausteinen – einem von Windows aus ansprechbaren Netzwerkdrucker, der PDFs ablegt (cups-pdf) und einem PDF-Manipulationstool (pdftk) war der Rest mehr oder weniger ein Selbstgänger:

  • Unter Windows cups-pdf als Postschript-Drucker anlegen
  • Das Programm darauf trimmen, darüber zu drucken (es druckt ausschließlich auf den Standardrucker – Halleluja!)
  • Eine Vorlage erstellen (mit OpenOffice Writer), die einzig die Absenderzeile und die Bankverbindung beinhaltet (hierbei darauf achten, daß Textboxen mit »no fill« mit einem 100% transparentes Weiß gefüllt werden, dann gibt’s keine überraschenden weißen Überdeckungen) und diese nach PDF exportieren
  • Periodisch (ich mach’s minütklich per cron) etwaige PDFs in /var/spool/cups-pdf/ANONYMOUS/ mit etwas in der Art »pdftk $file stamp OOtemplate.pdf output /var/tmp/$$-tmpfile.png && rm $file && lpr -Pcooler_drucker /var/tmp/$$-tmpfile.png && rm /var/tmp/$$-tmpfile.png« verwursten und ausdrucken lassen

Noch nicht das Optimum, aber mal eben für einen späten Abend gar nicht mal so schlecht ;)

Medion P7610 und der Pinguin

Bevor’s durch Tab-Schließen in Vergessenheit gerät: Meine Schritte, um das Medion P7610 (Aldis 17″-Monster-Schlepptop von Anfang 2009) unter Ubuntu 9.04 gangbar zu machen …

  • Platz schaffen (C:\ verkleinern); unter Vista hat MS das entsprechende Tool unter Systemsteuerung -> Verwaltung -> Computerverwaltung -> Datenträgerverwaltung (oder so) versteckt. Nicht wundern, zumindest wenn mit Vista schon gearbeitet wurde, kann es sein, daß die Verkleinerung, trotz Abschaltung der Auslagerungsdatei, von den 280 GB der Partition nur ~90 GB freigeben möchte; bein HP 2133 Mini-Note (Vista nicht gestartet) machte beim Verkleinern keine solchen Probleme …
    Wenn Windows-Bordmittel nicht ausreichend helfen: Partition defragmentieren (auch irgendwo in Kontextmenüs versteckt -> Google weiß es im Zweifel), den Vormittag mit Freunden im Miner’s/der Kaffetränke der Wahl verbringen, Ubuntu-Live-CD booten, gparted auf C: loslassen, den Nachmittag mit Freunden an anderem Ort verbringen (nicht wieder Kaffee => zu viel Koffein!), Windows booten und über die wg. 0 GB Partitonsgröße fehlende winload.exe nicht wundern. Reparationsinstallation von der Vista-DVD booten, C: reparieren lassen, Vista booten und über Nacht den chkdsk werkeln lassen. Am nächsten Morgen könnte man zum nächsten Schritt übergehen …
    Alternativ: den proprietären, bloated program loader (aka Windows Vista) von der Platte putzen, zur Sicherheit dann auch gleich die Recovery-Partition mitnehmen (kann man ja zu swap machen).
    FYI, meine Platte sieht derzeit so aus:
    root@greebo:~# fdisk -l
    Disk /dev/sda: 320.0 GB, 320072933376 bytes
    255 heads, 63 sectors/track, 38913 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Disk identifier: 0x68216821
    Device Boot Start End Blocks Id System
    /dev/sda1 * 1 18182 146046883+ 7 HPFS/NTFS
    /dev/sda2 36364 38914 20477952 c W95 FAT32 (LBA)
    /dev/sda3 18183 36363 146038882+ 5 Extended
    /dev/sda5 35957 36363 3269196 82 Linux swap / Solaris
    /dev/sda6 18183 35956 142769592 83 Linux
    Partition table entries are not in disk order
  • Ubuntu-CD booten, Ubuntu nach /dev/sda5 (oder wohin auch immer) installieren.
  • Ubuntu 9.04 zum Ersten Mal booten; der fehlende Sound läßt sich über NC10-PPAs nachrüsten — oder zu Fuß, es braucht »nur» ein neueres ALSA. Und den Eintrag in /etc/modprobe.d/alsa-base.conf:
    options snd-hda-intel model=medion
    Reboot und … Tusch!
    Ach so: auch wer keinen Sound benötigt, sollte dieses nachinstallieren — out-of-the-box schluckten Firefox bei offenen Flash-Video oder auch twirl (Adobe-AIR-Anwendung für’s Microblogging) 100+% CPU, da es mit dem Sound nicht tat …
  • Die Webcam ist das nächste Multimedia-Sorgenkind; leider – natürlich – kein UVC-Gerät, aber, Community sei Dank, es gibt auch für GL860 einen Treiber, zumindest prinzipiell funktioniert meine Webcam damit (wenn auch mit xawtv viel zu hell und mit Hänger bei Hellingkeitsänderung oder Verlassen von xwatv).

Hibernate hat jetzt einmal zumindest klaglos geklappt; WLAN rennt out-of-the-box, LAN dito, Bluetooth hat das Notebook nicht …

DECT. Why I hate it.

Ich bin ja nun ein »Neu-Freund« der AVM-Geräte mit »Fritz« im Namen (und deren baugleicher oder -ähnlicher Vettern aus der »Speedport«-Familie des Telekom-Stammbaums). Nachdem ich nun also Blut geleckt hatte mit der DECT-Basis in der 72×0, die mit dem AVM-Mobilteil MT-D HD-Telefonie ermöglicht, mußte ich natürlich auch mal gucken, wie toll denn die Telekomversion (Speedport W900V) der 7150er-Box von AVM ist.
Ich will niemanden auf die Folter spannen; in meinen Augen ist es ein mittleres Desaster :( Ich habe hier einen »fritzsierten« Speedport W900V sowie zwei AVM Fritz!Fon MT-D – jene mit HD-Telefonie – und muß sagen, daß das MT-D ausschließlich an der 72×0 seine Funktionen ausspielt :( Am W900V ist es grade mal ein GAP-Handgerät, mit dem man zwar telefonieren kann, sämtliche Komfortfunktionen aber fehlen. Einen Vergleich der Funktionalität des Vorgängermobilteils MT-C an der 7150 bzw. 7270 gibt es im IP-Phone-Forum (Anmeldung erforderlich); das MT-D hingegen funktioniert außer an der 7270 (und ggf. dem änhlichen Speedport-Model, W920V) auch an Gigaset-Basen nicht wirklich gut — GAP eben.
Ob es Absicht war, daß man das englische Wort »gap« (»Lücke«) als Kürzel für herstellerübergreifende Basisfunktionalität bei DECT-Basen und -Mobilteilen verwendet hat? Wobei es eigentlich mehr als lückenhaft ist, was an Funktion bei DECT/GAP geboten wird. Ich habe zum Beispiel ein Motorola D800-Series-Mobilteil an einer T-Sinus 45-Basis angemeldet: telefonieren geht so, bei Anruflisten hat der Spaß ein jähes Ende. Umgekehrt aber auch, Siemens Gigaset SL1 an Motorola D800-Basis: Telefonie ja, jegliche Einstellungen aber Fehlanzeige. Naja, und, wie zu erwarten, dito auch das MT-D an der Sinus- (Gigaset-) Basis: telefonieren per se geht. Funktional auf den Niveau von Graham Bells initialer Erfindung: es wird Sprache übertragen, immerhin.
Man stelle sich vor, dieser minimaistische Ansatz wäre bei ISDN verfolgt worden: Runfnummernanzeige, Halten, Makeln, all’ die ISDN-Komfortfunktionen würden nur zwischen herstelleridentischen ISDN-Telefonen und den entsprechenden ISDN-Baugruppen in der Vermittlung funktionieren, wer hätte da ISDN gekauft?
Was mich ziemlich enttäuscht ist, daß, obwohl das MT-D (und die 72×0-Basis) auf Swissvoice-DECT-Technik aufbaut und eigentlich nur eine Weiterentwicklung der Swissvoice-DECT-Technik im 7150 (W900V) ist, funktioniert außer reinem Telefonieren fast nichts mit einem AVM-Mobilteil MT-D an einer AVM-Basis der 7150er-Familie. Bei Siemens’ Gigaset-Reihe war das für mich einer der wesentlichen Punkte: neuer Mobilteile konnten weitgehend auch an älteren Basen die Funktionen, die ältere Mobilteile dort konnten, ältere Mobilteile an neueren Bases nahezu alle Funktionen, die sie schon an ihren älteren Basen hatten. Zeigt sich hier, daß AVM eben kein Telefonhersteller ist sondern ein DSL-Router-Fabrikant? Sicher, der Verkaufspreis des MT-D mit unter 40 Euro liegt deutlich unter den derzeit mindestens 59 Euro, die für ein MT-C hingeblättert werden müssen. Aber es gibt am Markt auch komplette (analoge) Basen samt Mobilteil für unter 20 EUR, so richtig teuer kann die Technologie eigentlich auch nicht mehr sein …