Nach Hause telefonieren

Wieso habe ich in meiner letzten Mobilfunk-Abrechnung den Posten einer Auslands-SMS? Ich selbst habe keine SMS an eine Nummer verschickt, die nicht mit der +49 begonnen hätte.

Die Hotline teilte mir die Zielrufnummer mit, die mir völlig unbekannt war: +44 7537410250

Zum Glück wusste Google mehr darüber: Offenbar wird diese SMS von alten iOS (in meinem Fall iOS 9 auf einem iPhone 4s) verschickt, um Facetime bei Apple zu registrieren. Wes wird zwar auf dem Gerät eine allgemeine Warnmeldung gezeigt („Bei der Benutzung von Facetime können Gebühren anfallen“), aber das bezog ich auf den normalen Verbrauch des Datenvolumens.

Bei neueren iOS-Versionen schient es anders gelöst zu sein oder es wird eine inländische Rufnummer verwendet.

Dekaden-Mac

Mein uralter MacPro (macpro2,1) aus 04/2007 hat soeben eine neue Aufgabe gefunden und wird jetzt als 3GHz, acht-Kern CPU mit 9GB RAM unter Windows 10 mit 64bit betrieben.

Dieser Link auf MacRoumors hat die entscheidenden Hinweise gegeben, denn man kann diesen alten MacPro mit seinen 32bit UEFI nicht von einer 64bit CD/DVD booten und somit schien die vollständige Rehabilitierung des bereits seit einigen Jahren eingemotteten Rechners nicht zu gelingen (nachträglich lässt sich aus einem 32bit Windows 7 kein 64bittiges System erzeugen).

Aber nachdem mit Hilfe von VMware Fusion (unter MacOS 10.7 auf den vorderen Partitionen der SSD) die physische Partition 4 mit Windows 8 Pro 64bit bespielt werden konnte, war auch das Booten von dieser Partition möglich und anschließend auch der Upgrade zu Windows 10 mit 64bit machbar.

Anders als im Artikel oben durchgespielt kann auch nur eine Partition (statt des vollständigen Laufwerks) verwendet werden. Der Befehl zur erstellen der Parameter-Datei für den Zugriff auf diese Partition musste von „fullDevice“ auf „0“ umgestellt werden.

Internet-Nutzungsstatistiken von der Fritz!Box unter FritzOS 6.20

Seit Jahren verwende ich MRTG zum Visualisieren der über meinen Internet-Zugang transferierten Daten. Die Fritz!Box liefert dazu die Anzahl kommender und gehender Bytes via der UPNP-Schnittstelle. Das Script „UPNP2MRTG“ holt diese Daten ab und generiert die Grafiken, die ich mir an meinen Rechnern einblende (mit „Geektool“).

Die UPNP-Schnittstelle hat sich im neuesten FritzBox-Firmware jedoch geändert, genauer: Der URL, unter der die Daten abrufbar sind, und das verwendete Script hatte den URL hardkodiert. Aber welcher wäre jetzt richtig?

Dazu schreibt der AVM-Support binnen hervorragender 24 Stunden:

Guten Tag Herr Hidde,

vielen Dank für Ihre Anfrage an den AVM-Support.

Die neueren FRITZ!OS 6-Versionen enthalten eine UPnP-IGD-Template-Umstellung, weshalb externe Anwendungen die per UPNP-Statusinformationen von FRITZ!Box abfragen nun eine Fehlermeldung generieren.

die UPnP-IGD-Url’s sind jetzt unter

/igdupnp/control/WANIPConn1 (alt: /upnp/control/WANIPConn1)

zu erreichen.

Bspw:

alt: POST /upnp/control/WANIPConn1 HTTP/1.1
neu: POST /igdupnp/control/WANIPConn1 HTTP/1.1

Normalerweise ist das allerdings kein Problem für einen UPnP-Klienten, da die URL’s sich in der UPnP-Description (xml) befinden und vom Klienten initial immer geladen werden müssen.
Wenn aber ein Klient, und davon gehe ich in Ihrem Fall aus, darauf verzichtet und die URL’s fest im Code zu stehen hat, kommt es zum Fehler z. B.

HTTP/1.1 500 Internal Server Error oder

oder

InvalidDescription

Gelöst werden kann dass Problem in diesem Fall in dem der Pfad in Ihrer Anwendung angepasst wird. Wie genau dies bei Ihrer Software vorgenommen wird erfragen Sie bitte beim Hersteller der Software. Diese Information liegt mir leider nicht vor.

 

Freundliche Grüße aus Berlin
(AVM Support

 

 

Eine Ära geht zu Ende

Gestern habe ich unseren Telefonanschluss von ISDN/VDSL auf „IP-only“ umgestellt. Obwohl die Umschaltung auf 15:59 Uhr lt. Kundencenter/Aufträge terminiert war, konnte man schon am Vormittag nicht mehr via ISDN telefonieren. Meine früheren Versuche, schon eine der MSN auf den VOIP-Server der Telekom umzustellen, hatte nicht geklappt – jetzt funktionierte es aber: Die Rufnummern konnten „registriert“ werden.

Überhaupt gelang der Umstieg recht problemlos, denn die AVM Fritz!Box 7390 bringt einfach alles mit, was man zur Einrichtung braucht: Auch die Adapter für das DSL-Kabel mit RJ45-Stecker (vulgo: „Westernstecker“) zum Anschluss direkt an die TAE-Dose (Übergabepunkt der Telekom im Haus) sind im üblichen Lieferumfang enthalten (man muss sie nur im Originalkarton wiederfinden, den man vor vielen Monaten im Keller verbuddelt hat). Dann kann man den Splitter und die parallel angeschlossenen NTBAs abklemmen und das ISDN-Endgerät direkt in den ISDN („S0“)-Ausgang der Fritz!Box stecken. Soweit zur Verkabelung.

In der Admin-Oberfläche der Fritz!Box werden jetzt die einzelnen Festnetz-Rufnummern gelöscht und als Internet-Rufnummer neu eingetragen. Jeweils dazu wählt man den Anbieter (hier: Telekom) und man erhält eine Eingabemaske für die restlichen Parameter, die ich in meinem Fall alle frei lassen konnte, denn die Anmeldung am VOIP-Server erfolgt über die Erkennung der Leitung und damit als „anonymous“. Schliesslich muss man noch das Telefon-Endgerät an der Fritz!Box anmelden („ISDN-Basisstation“) und den Festnetz-Anschluss deaktivieren. Und dann heisst es: Warten.

Warten auf die Umstellung auf Seiten der Telekom. Ich konnte zwar sofort via VOIP herauswählen, aber die Rufe von aussen erreichten uns nicht vor späten Nachmittag. Zwischendurch hatte die Hotline einige Hinweise gegeben, die hilfreich wirkten: Nach dem ersten erfolgreichen Wählen via VOIP sei automatisch auch die Rückrichtung freigeschaltet. Wenn das nicht klappen sollte, würde zwischen 20:00 und 24:00 Uhr eine Zwangsaktualisierung vorgenommen… Nun ja, hier ging es vorher, aber nicht wie beschrieben.

Ach ja: Hinterlegte Rufumleitungen funktionierten den ganzen Tag über für sofortige Umleitungen; verzögerte Weiterleitungen scheiterten, weil die angerufene Rufnummer gar nicht erreichbar war. Diese Einstellungen haben die Migration von ISDN auf VOIP auf der Anbieterseite übrigens nicht überstanden: Sie mussten neu angelegt werden.

Mehr als zwei Gespräche lassen sich leider nicht parallel führen. Damit ist VOIP zumindest in diesem Produkt/Tarif nicht vorteilhafter als ISDN. Die Sprachqualität ist in etwa gleich, ein Echo oder eine Sprachverzögerung habe ich nur in Einzelfällen ganz leicht feststellen können, was aber auch an der bei diesem Test gesteigerten Aufmerksamkeit und ev. auch an der Gegenseite gelegen haben könnte. Der Rufaufbau ist etwas langsamer als bei ISDN, wo es quasi verzögerungsfrei stattfindet.

Die DECT-Fähigkeiten der Fritz!Box habe ich zwischenzeitlich auch mal wieder angetastet und bin von der gesteigerten Kompatibilität von z.B. den Gigaset S79H Mobilteilen beeindruckt, denn man kann (über andere als die gewohnten Tasten) mittels Softkey auf die Anruferlisten, das Telefonbuch u.a. Funktionen der Fritz!Box zugreifen.

Das einzige, was ich mir bei der Umstellung gewünscht habe ist ein Automatismus, der die Umstellung aller Festnetz-Rufnummern zu Internet-Rufnummern gemacht hätte. Solch ein Assistent hätte mir die Arbeit enorm vereinfacht. Auch die Signailisierung, ob die Anmeldung am VOIP-Server geklappt hat, ist verbesserungswürdig. Dennoch: Tolles Produkt von AVM und gute Leistung von der Telekom.

Alles OK, aber geht nicht?

Eine Festplatte konnte nicht an Mac OS X angemeldet werden (Laufwerk konnte nicht aktiviert werden). Erste Hilfe (Volume überprüfen bzw. reparieren) in Festplattendienstprogramm zeigte keine Fehler. Toll.

Erst ein Blick in die Konsole brachte Näheres zu Tage: Beim Mounten meldete einer der beteiligten Subprozesse einen Fehler 22 – dem Journal sei die Magie flöten gegangen.

11.12.13 11:48:53,000 kernel[0]: jnl: disk6s2: open: journal magic is bad (0x0 != 0x4a4e4c78)
11.12.13 11:48:53,000 kernel[0]: hfs: late jnl init: failed to open/create the journal (retval 0).
11.12.13 11:48:53,000 kernel[0]: hfs_mounthfsplus: hfs_late_journal_init returned (0)
11.12.13 11:48:53,000 kernel[0]: hfs_mounthfsplus: encountered error (22)
11.12.13 11:48:53,000 kernel[0]: hfs_mountfs: encountered failure 22
11.12.13 11:48:53,000 kernel[0]: hfs_mount: hfs_mountfs returned error=22 for device disk6s2
11.12.13 11:48:53,806 diskarbitrationd[17]: unable to mount /dev/disk6s2 (status code 0x00000001).
11.12.13 11:48:57,157 com.apple.launchd[1]: (org.macports.rsyncd[35913]) Exited with code: 2

Etwas Googeln brachte die Rettungsarbeiten in Gang: Das manuelle Mounten ohne Journaling klappte, wenn auch mit dem obskuren Hinweis, dass Jornaling nicht aktiv sei. Na, egal: Das Laufwerk konnte vom Finder (Achtung, Wortspiel) gefunden werden. Vorsichtshalber noch ein „fsck_hfs“ hinterhergeschickt: Auch ohne Befund. Anschliessend konnte auch das Journaling wieder eingeschaltet werden und alles war prima.

Ist doch schön, wenn alles wieder in Ordnung ist, als wäre nie etwas gewesen!

PS: Nein, um 14:15 und 16 Sekunden wollte ich das nicht wiederholen…

Krasser Fall von Fehleinschätzung

Ist ja nicht das erste Mal, dass die sog. „Fortschrittsbalken“ eine krasse Fehleinschätzung der noch anstehenden Arbeitslast vermitteln. Hier aber liegt der Balken insgesamt richtiger als die Zeitangabe:

Die längsten fünf Sekunden...

Die längsten fünf Sekunden…

Oder habe ich eine SSSSD verbaut, eine SuperSchnelleSolidStateDisk?

Besser wäre allerdings, alles zu beschleunigen. Zum Beispiel:

Besser nicht vom Rechner trennen...