Archiv des Autors: Daniel Weber

Telekom: IPv6 angeblich bald für All-IP-Bestandskunden aktivierbar (4 Updates)

Seit dem Herbst 2012 hat die Telekom IPv6 auf ihrer DSL-Plattform produktiv im Betrieb, bisher jedoch nur für einen kleinen Kundenkreis: Nur wer nach dem 25.09.2012 den Wechsel von einem Anschluss mit analoger Telefonie oder ISDN auf einen Anschluss mit VoIP (sogenannter All-IP-Anschluss) bestellt hat oder aber ab diesem Tag in einen anderen All-IP-Tarif gewechselt ist, bekam IPv6 aktiviert. Die Kommunkationspolitik (intern wie extern) lies wie üblich erstmal zu wünschen übrig, selbst der Community-Support schrieb Anfang 2014 noch, dass er obige „Wann wird IPv6 aktiviert?“-Regel selbst erst empirisch herausfinden musst.

Dass Analog- und ISDN-Kunden kein IPv6 bekommen haben ist verständlich, wurde der Vertrieb solcher Anschlüsse mittlerweile ja praktisch komplett eingestellt. Man hätte also das Buchungssystem für diese alten Anschlüsse anpassen müssen, damit es IPv6 provisionieren kann, obwohl dessen Nutzungsende bereits kurz bevor stand. Unschön war hier, dass man auch hier keine klare Kommunikation eingesetzt hat sondern auf ausreden gesetzt hat, dass es technisch nicht anders ginge. Dass man sich aber für All-IP-Bestandskunden keinen Migrationspfad überlegt hat (oder IPv6 einfach generell eingeschaltet hat) fand ich von Anfang an unverständlich.

Ich und auch andere IPv6-Interessierte haben über die letzten knapp 19 Monate  in der Telekom-Hilft-Community und in den Support-Foren oft die Frage gestellt, wie es denn nun weitergehen soll. Nun ist die Antwort da: Bereits Ende März tauchte bei vielen All-IP-Bestandskunden im Kundencenter ein Auftrag „Sperre IPv6“ auf. Mittlerweile haben die Hotline und auch der Community-Support die Möglichkeit, diese Sperre zu deaktivieren, ohne dass eine neue Vertragslaufzeit beginnt oder ein Tarifupgrade durchgeführt werden muss.

Ich hoffe, dass viele Telekom-Kunden von dieser Möglichkeit gebrauch machen werden und damit die Verbreitung von IPv6 weiter voran bringen.

Update 22.04.2014:

Zwischenzeitlich hat der Community-Support nachgeforscht: Man kann die „Sperre IPv6“ zwar bereits deaktivieren lassen, es wirkt sich aber noch nicht auf die Einwahlinfrastruktur aus. Erst im zweiten Halbjahr soll es sich dann tatsächlich auswirken… es dauert also leider doch noch.

Update 23.04.2014:

Aktuell sollte man auch davon absehen, die Sperre für sich deaktivieren zu lassen, weil noch unklar ist, ob das dann später „von selbst“ entsprechend wirksam wird oder erst wieder aktiviert werden müsste um dann nochmal (sauber) deaktiviert zu werden.

Update 24.04.2014:

Betroffene, bei denen die Sperre bereits deaktiviert wurde, die aber noch kein IPv6-Präfix erhalten, müssen sich Tapfer durch ein Störungsticket bis zur „Eskalationsstufe 3“ hocharbeiten. Diese kann wohl dann endlich IPv6 tatsächlich aktivieren.

Update 24.10.2014:

Es hat lange gedauert, aber jetzt können Hotline oder Telekom-Hilft-Team bei IP-Bestandskunden die Sperre tatsächlich wirksam ausbauchen. Wer sich die Sperre bereits im Frühjahr hat (unwirksam) ausbuchen lassen und sich nicht durch die Störungsmeldung hangeln wollte, für den sollte es reichen, ein kostenloses Zusatzfeature im Kundencenter hinzuzubuchen. Dadurch wird gerüchteweise der Kundendatensatz reprovisioniert, was IPv6 dann aktiviert.

Netzneutralität: Die getroffenen Hunde jaulen

Kaum hatte sich das EU-Parlament am 3. April 2014 im Rahmen des Telecom-Pakets zum digitalen Binnenmarkt für ernsthafte Netzneutralität ausgesprochen, gab es auch schon die Reaktionen der deutschen Branchenverbände BITKOM und VATM.

Der Abstimmung im EU-Parlament gingen monatelange Detailarbeiten am Entwurf der Netzneutralitätsverordnung voraus, bei denen der Industrieausschuss ITRE federführend war. Die anfängliche Fassung von Pilar Del Castillo sah – vermutlich dank intensiver Lobbyarbeit europäischer Ex-Monopolisten – relativ weit gefasste „specialised services“ – ein Äquivalent zu den 2013 geplanten „managed services“ der Telekom – vor und hätte damit die Netzneutralität nicht bewahrt sondern erst ihre Umgehung ermöglicht. Die vom ITRE am 18. März 2014 verabschiedete Fassung enthielt zwar in vielen Punkten bereits Verbesserungen gegenüber der ersten Fassung, aus Sicht vieler Netzaktivisten bestanden aber noch zu viele Schlupflöcher, um die Netzneutralität auszuhebeln. Der nun vom EU-Parlament verabschiedete Text ist aber um viele dieser Schwachstellen bereinigt worden und geht in manchen Punkten sogar über Vorschläge hinaus, die Wochen zuvor noch im Ausschuss abgelehnt wurden.

Während der Beratungen im ITRE hatte ich die Gelegenheit, mit unserer Europaabgeordneten Angelika Niebler per E-Mail und auch telefonisch ausführlich über das Thema zu diskutieren. Die Aufgabe der Ausschussmitglieder war alles andere als leicht: Auf der einen Seite sollten sie das offene Internet bewahren, auf der anderen Seite aber auch QoS für Telemedizin o.ä. ermöglichen und darüberhinaus den Telekommunikationskonzernen erlauben, an der Wertschöpfung durch Content-Anbieter zu partizipieren. Letzteres ist natürlich auch ein verständliches Ziel. Der Comcast-Netflix-Deal in den USA zeigt, dass es für eine Telco auch ohne Bruch der Netzneutralität möglich ist, einen Content-Anbieter an Netzinvestitionen zu beteiligen. Ebenso sind Dienste wie Telemedizin mit der Netzneutralität vereinbar, wenn sie – wie in der nun verabschiedeten Formulierung – über eigene, logisch getrennte Kapazitäten (im All-IP-Zeitalter sozusagen der Nachfolger der klassischen Standleitung) realisiert werden.

Obwohl auch die jetzt verabschiedete Formulierung noch kleinere Ungenauigkeiten enthält, zeigt das „Geschrei“ der Branchenverbände, dass damit bereits ein grundlegender Schutz der Netzneutralität erreicht ist. Da sich die Telco-Branche im Vorfeld mit ihrer Lobby-Arbeit ganz darauf konzentriert hat, „welfare“-Dienste als Beispiele anzubringen, warum keine strenge Netzneutralität vorgeschrieben sein sollte, sind die jetzigen Proteste sogar unverständlich: Gerade solche Dienste sind von der jetzigen Fassung problemlos abgedeckt, weil sie unweigerlich eigene Kapazitäten und durchgängiges QoS erfordern. Dass nun aber doch Protest kommt, zeigt ganz klar, dass man tatsächlich eher an rein kommerziellen Diensten interessiert ist. Kommerzielle Dienste, die – ohne Netzneutralität – später wiederum zur Gefahr für „welfare“-Dienste werden könnten: Wer wird im Zweifelsfall mehr für einen „specialised service“ investieren können? Ein kommerzieller Videoanbieter für Streaming oder ein gemeinnütziges Klinikum für Telemedizin? Freilich wirbt es sich im Vorfeld weniger gut mit handfesten kommerziellen Interessen für priorisierte Dienste.

Mein Dank gilt allen EU-Parlamentariern, die sich in den Ausschüssen und im Parlament für ernsthafte Netzneutralität eingesetzt haben und ich hoffe, dass der Text, bis er endgültig in Kraft tritt, nicht ausgehöhlt wird.

Den Telcos wünsche ich, dass sie zukünftig sich und ihre Tarife an „das Netz“ anpassen und nicht umgekehrt das Netz an ihre alte, vermittlungsorientierte Denkweise. Die Kunden sind bereit, für Datentransport angemessen zu bezahlen, das heißt allerdings, dass die Kunden bestimmen wollen, mit wem sie wann und wie kommunizieren und dies nicht der Telco überlassen wollen.

Optimierung der Hausverkabelung für xDSL

Neulich hatte ich vom Umstieg auf einen VDSL-All-IP-Anschluss der Telekom gebloggt. Im Nachgang zur Umstellung zeigten sich kleinere Stabilitätsprobleme der Leitung, da ein- bis zweimal am Tag die Synchronisation verloren ging. Bevor man solche Probleme dem Anbieter als Störung meldet, sollte man sich zuerst die eigene Haus- bzw. Wohnungsverkabelung vornehmen und sicherstellen, dass das DSL-Modem bzw. der DSL-Router an der ersten TAE-Dose angeschlossen ist und keine parallelen Abzweige existieren.

Der parallele Abzweig war das entscheidende Stichwort: Wir haben tatsächlich neben der ersten TAE-Dose im Wohnzimmer eine weitere, ungenutzte TAE-Dose im Kinderzimmer. Am APL im Keller fand sich der Abzweig nicht, allerdings fand ich im Keller an einer anderen Stelle den entscheidenden Hinweis darauf, dass sich der Abzweig bei unserer ersten TAE-Dose befinden müsse. Dort wurde dann „maximaler Pfusch“ sichtbar: Der a-Draht zur zweiten Dose war korrekt am Anschluss a2 der ersten Dose angeschlossen, der b-Draht hingegen war am Anschluss Lb angeschlossen und somit als Abzweig noch vor der ersten TAE-Dose. Nachdem auch der b-Draht korrekt am Anschluss b2 angeschlossen war stabilisierte sich die VDSL-Leistung schlagartig, der Störabstand stieg an und die nicht behebbaren Fehler gingen zurück.

Hier die Statistiken aus der Fritzbox, links vor der Korrektur und rechts danach:

Statistik vorher Statistik nachher

Bei den Verbindungseigenschaften sieht man den Anstieg beim Störabstand und die höhere Leitungskapazität nach der Korrektur:

Verbindungseigenschaften vorher Verbindungseigenschaften nachher

Und noch die Spektrumsanzeige vor und nach der Korrektur:

Spektrum vorher Spektrum nachher

Vor dem Hintergrund der doch deutlichen Verbesserung erstaunt mich, dass die vorherige ADSL2+-Verbindung praktisch jahrelang nicht die geringsten Probleme gemacht hat.

Als nächster Schritt steht nun noch ein Versuch mit einer neuen TAE-Dose an, da ich von verschiedensten Stellen vor oxidierten Kontakten oder integrierten Prüfwiderständen bei älteren TAE-Dosen gewarnt wurde.

Umstieg auf VDSL mit IPv6 und VoIP statt ISDN

Seit mittlerweile 16 Jahren bin ich an die Vorzüge eines ISDN-Anschlusses (oder Universal-Anschlusses, wie er bei der Telekom die letzten Jahre heißt) gewöhnt. Vor 9 Jahren gesellte sich dann (endlich) auch ein DSL-Anschluss dazu, den ISDN-Anschluss habe ich aber behalten, da ich zu Fernwartungszwecken ISDN-Datenverbindungen benötigt habe.

Nachdem die Telekom dann aber im Herbst 2012 damit begann, IPv6 nur für Neuverträge mit VoIP-Telefonie (statt ISDN oder analoger Telefonie) anzubieten, habe ich gezielt darauf geachtet, ob ich die ISDN-Datenverbindungen wirklich brauche. Im ersten Schritt habe ich mir für das Fernwartungsziel ein „Hintertürchen“ für SSH eingerichtet (zweiter, bereits vorhandener DSL-Anschluss über anderen ISP mit eigener Technik) und daraufhin auf meiner Seite den ISDN-Router abgeschaltet (damit ich nicht aus Gewohnheit doch wieder die ISDN-Datenverbindung nutze). Das Ergebnis war wie erwartet: Eigentlich brauche ich keine ISDN-Datenverbindungen mehr.

Blieb noch mein Misstrauen gegenüber VoIP-Telefonie, das mich vor einem Wechsel auf einen solchen Anschluss zurückschrecken lies. Das änderte sich im Laufe des vergangenen Jahres: Bei einem Verwandten – bisher per EDGE im Internet – kam der Wunsch auf, endlich einen „vernünftigen“ Anschluss zu haben, der allerdings so wenig wie möglich kosten sollte. Die Wahl fiel auf einen besonders günstigen DSL-Anschluss (auf Telekom-Technik basierend) mit VoIP-Telefonie und die Folgemonate zeigte sich, dass die VoIP-Telefonie problemlos funktioniert. Echos und Verzögerungen, wie ich sie früher kannte, traten nicht mehr auf. Im Herbst kam VoIP auch gelegentlich am eigenen Anschluss zum Einsatz, als ISDN zeitweise gestört war (DSL jedoch nicht) und die Fritzbox automatisch auf Sipgate umschaltete.

Nachdem dann am 5. Dezember die Drosselklausel der Telekom wieder gestrichen wurde, war der letzte Grund, den bisherigen Anschluss so lange wie möglich zu behalten, weggefallen und die Überlegung, ob es weiterhin ein ADSL2+-Anschluss oder ein VDSL-Anschluss sein soll, begann. Der VDSL-Anschluss hat als unschlagbaren Vorteil den deutlich erhöhten Upstream und wird in einigen Jahren dank Vectoring vermutlich nochmals beschleunigt werden. Blieb noch die Suche nach einem geeigneten Termin für den Wechsel, schließlich erfordert der Wegfall von ISDN doch auch ein paar Veränderungen an der Verkabelung.

12.01.2014 15:43

Die Bestellung des Wechsels ist erledigt, als Wunschtermin wurde der Vormittag des 31.01.2014 angegeben und bei der Gelegenheit auch gleich weitere Rufnummern (meine Frau benötigt eine separate geschäftliche Nummer und unsere Tochter wird sich irgendwann auch über eine eigene Nummer freuen) bestellt und durch die automatische Bestelleingangsbestätigung auch entsprechend bestätigt. Nun sind wir gespannt auf die postalische Auftragsbestätigung.

14.01.2014 16:50

Per E-Mail wird der Eingang des Auftrags bestätigt, um Kundencenter ist der Auftrag nun auch detailliert zu sehen, allerdings ist dort nicht das Wunschdatum (Freitag, 31.01.2014) aufzufinden sondern der Tag darauf (Samstag, 01.02.2014), was mich aber nicht weiter stört.

17.01.2014 17:40

Im Briefkasten fand sich heute die schriftliche Auftragsbestätigung. Auch diese nennt den 01.02.2014 als Bereitstellungstermin und nennt Wegfall und Zugang der richtigen Produkte. Seltsam ist jedoch, dass die im Rahmen der Bestellung ausgewählten Wunschrufnummern (eine einzelne und 6 am Stück) es nicht geschafft haben. Stattdessen sind es nun 2-mal 2 aufeinanderfolgende ein eine einzelne… Eine der neuen Nummern habe ich vorab in der Fritzbox eingetragen, dann sehe ich an deren Registrierungszustand am Schaltungstag, ab wann ich die restlichen Nummern umstellen kann.

24.01.2014 17:15

Wieder Post von der Telekom, diesmal die Bestätigung, dass kein Eintrag in den „Auskunftsverzeichnissen“ (Telefonbuch, Telefonauskunft, …) gewünscht wurde. Das ging beim letzten Tarifwechsel 2012 noch schief.

27.01.2014 16:15

Das letzte Schreiben der Telekom hat mich daran erinnert, dass ich mir noch ein sogenanntes „DSL-Kabel für den IP-basierten Anschluss“ (beim Vertrieb kurz „IP-Anschlusskabel“, bei der Technik kurz „Signaturkabel“) besorgen wollte, also mache ich nach der Arbeit noch einen kurzen Abstecher beim Telekom-Shop zwischen Hauptbahnhof und Stachus in München und bekomme dort das passende Kabel.

27.01.2014 18:45

Erneut findet sich ein schreiben von der Telekom im Briefkasten, diesmal eine knappe Einrichtungsanleitung, wie ich am Schaltungstag die Verkabelung ändern sollte. Nicht dass ich sie brauchen würde – Splitter und NTBA abzuklemmen ist nun ja nicht so schwer – aber angesehen habe ich sie mir trotzdem.

29.01.2014 16:00

Ich erhalte einen Anruf von der Telekom auf dem Handy, bei dem der Schaltungstermin am 01.02.2014 nochmals bestätigt wird, außerdem wird mir nochmals erklärt, dass ich meine Verkabelung anpassen muss und im Router die VoIP-Nummern einrichten muss. Ebenso wurde ich nach meinem Router gefragt (Fritzbox 7390) und erstaunlicherweise folgte kein Versuch, mich zu einem Speedport-Router zu überreden. Danach folgte noch die Anweisung, nach der Umschaltung ein abgehendes Telefonat am besten zum eigenen Handy zu führen und dieses mindestens 10 Sekunden zu halten. Der Anrufer war erstaunt, dass ich wusste, dass damit die Portierung der Rufnummern auf die VoIP-Plattform angestossen würde.

30.01.2014 18:05

Ich bekomme nochmals eine Bestätigung des Schaltungstermins per E-Mail.

31.01.2014 18:45

Ich erhalte erneut einen Anruf von der Telekom, diesmal vom Techniker selbst, der morgen die Schaltung vornehmen wird. Er wollte uns lieber bereits am Abend über das Zeitfenster Bescheid geben, anstatt uns in der früh „aus dem Bett“ zu klingeln. Sehr nett!

31.01.2014 23:05

Ich deaktiviere vorab den IPv6-Tunnel zu HE.NET und stelle die Konfiguration auf natives IPv6 um, damit die nächtliche Zwangstrennung uns dann bereits natives IPv6 beschert.

01.02.2013 03:34

Nein, ich war nicht wach, ich habe die Uhrzeit aus dem Protokoll der Fritzbox. Die nächtliche Zwangstrennung hat uns wie erwartet endlich natives IPv6 ins Haus gebracht:

Fritzbox-Protokoll mit IPv4 und IPv6 von der Telekom

Noch hängen wir am gleichen BRAS (Broadband Remote Access Server, „MUNR71-se800“) und noch funktioniert unser ISDN, d.h. das gerne gestreute Gerücht, IPv6 funktioniere technisch nur an Anschlüssen mit VoIP-Telefonie wird – wieder einmal – wiederlegt.

01.02.2013 07:10

Die probehalber eingerichtete, zusätzliche Rufnummer erscheint in der Fritzbox nun als angemeldet, also kann ich damit beginnen, die alten Festnetznummern zu löschen und alle Nummern neu als „Internetrufnummern“ anzulegen. Danach führe ich den ersten, rausgehenden Anruf durch, um die Portierung auszulösen und wenige Minuten später funktioniert auch schon der reinkommende Anruf.

01.02.2013 08:13

Die Fritzbox hat die Synchronisation verloren, also hat der Techniker wohl im Hauptverteiler mit der Umstellung vom ADSL2+-Port auf den VDSL2-Port begonnen. Ich nutze die Zeit um Splitter und NTBA aus der Verkabelung zu nehmen. Nach knappen 9 Minuten steht die VDSL2-Verbindung mit 25.080 KBit/s im Downstream und 4.320 KBit/s im Upstream.

Fazit: Die Umstellung hat gut geklappt, aber ein paar weniger Bestätigungsbriefe und ein Bestätigungsanruf weniger hätten auch ausgereicht.

MS-SQL-Server: Schlechte DELETE-Performance

Ein Kollege meldete sich vor einigen Wochen mit einem interessanten Problem: Beim Löschen von Objekten aus einem komplexeren und gut befüllten Datenmodell liefen alle DELETEs in den Subtabellen und Kreuzreferenzen mit der erwarteten Geschwindigkeit (also im niedrigen Millisekundenbereich) ab, aber die DELETEs auf der Haupttabelle benötigten je Objekt dann plötzlich einige Sekunden.

Mehrere Stunden brüteten wir zusammen mit Kollegen über dem Problem, untersuchten den Ausführungsplan der DELETE-Anweisung, misteten Indizes aus, erstellten andere Indizes neu, reorganisierten die betroffene Tabelle… alles ohne Ergebnis.

Erst ein weiterer Blick auf den Ausführungsplan, diesmal ohne Beachtung der angeblichen Aufwandsverteilung, führte dann zur Lösung: In einer anderen Tabelle mit mehreren Millionen Einträgen befand sich eine Fremdschlüsselspalte, die jedoch nicht Indiziert war. Folglich musste für jedes DELETE eine Full-Table-Scan ausgeführt werden um eventuelle Abhängigkeiten auszuschließen.

Daher nun die kurze Merkregel:

Lege auf einer Fremdschlüsselspalte immer auch einen Index an (sofern sie nicht schon führend in einem anderen Index enthalten ist). Sind in der Tabelle nur wenig Daten, dann tut der zusätzliche Index nicht weh, sind in der Tabelle jedoch viele Daten, dann wird man spätestens beim DELETE in der referenzierten Tabelle froh um den Index sein.

Und wie immer: Trotz Merkregel kann es in Einzelfällen gute Gründe geben, sich anders zu verhalten.

Überwachung, Shitstorms und Nerds

In seinem Blog kritisiert Peter Tauber dass „unsere Freiheit durch Trolle und böse Menschen im Netz weit mehr eingeschränkt [wird], als durch die vermeintlichen Aktivitäten der Geheimdienste“. Er bezieht sich dabei auf diesen Tweet von Buschsalat:

Nur sind die ausufernde Überwachung durch Geheimdienste und das Verhalten von Trollen im Netz nicht sonderlich gut zu vergleichen:

  1. Die Menge der betroffenen Menschen unterscheidet sich wesentlich:
    Die ausufernde Überwachung durch Geheimdienste betrifft jeden, der telefonisch oder über das Internet kommuniziert, selbst wenn er dabei nur Inhalte konsumiert, recherchiert etc. und selbst nicht als Inhalts- oder Dienstanbieter bzw. „Sender“ (Blog, Twitter, Foren, Usenet, etc.) auftritt.
    Angriffe durch Trolle hat hingegen nur derjenige zu befürchten, der selbst als Inhalts- oder Dienstanbieter auftritt, weil er dadurch erst für andere (außer die vorgenannten Dienste) im Netz „sichtbar“ wird.
  2. Die damit verbundenen Nachteile unterscheiden sich wesentlich:
    Aktionen einen Trolls können ohne Zweifel sehr belasten, allerdings kann man sich ggf. durch die Möglichkeiten des Rechtsstaats dagegen zur Wehr setzen.
    Von der Überwachung durch einen Geheimdienst erfährt der Betroffene nichts, kann also auch keine Gegenmaßnahmen ergreifen und selbst wenn, hat der eigene Rechtsstaat gegen einen fremden Dienst keine Handhabe (Stichwort Merkelphone) und für einen eigenen Dienst „geeignete“ Schlupflöcher geschaffen (Stichwort G10-Gesetz).

Nun noch ein paar Worte zu Peter Taubers Sicht des Nerds: Ein richtiger Nerd bezeichnet niemanden als „gestrig“ oder „dumm“, nur weil er die neuen Medien nicht so gut wie seine eigene Westentasche kennt. Jeder hat sein Spezialgebiet und das ist auch gut so. Ein Nerd reagiert erst dann ungehalten, wenn sich jemand ohne entsprechende Kenntnisse in das Fachgebiet des Nerds einmischen möchte.

Cyrus: „SASL(-1): generic failure: checkpass failed“

Nachdem es mir bei fast jedem Serverumzug wieder passiert, schreibe ich es doch mal so auf, dass ich mich beim nächsten Mal erinnere, es finde oder zumindest Google es findet:

Gegeben ist ein Debian/Postfix/Cyrus-Virtual-User-Setup mit MySQL-Datenbank und Authentifikation über saslauthd. Dass Debian in einem „chroot jail“ läuft und man daher das saslauthd-Socket in /etc/default/saslauthd von /var/run/saslauthd nach /var/spool/postfix/var/run/saslauthd umbiegen muss (und die entsprechenden Verzeichnisse mit passenden Berechtigungen auch anlegen sollte), daran habe ich mich mittlerweile gewöhnt. Was ich jedoch regelmäßig vergesse, ist, dass man dann auch /var/run/saslauthd als Symlink auf /var/spool/postfix/var/run/saslauthd anlegen sollten… sonst kann man sich herrlich lang die Finger wund suchen.

Für elegantere Lösungen bin ich jederzeit offen.

Update 02.03.2014:

Bei Debian Wheezy ist der Symlink von /var/run/saslauthd nach /var/spool/postfix/var/run/saslauthd nach jedem Reboot wieder weg, weil /var/run seinerseits nur noch ein Link auf /run ist, was wiederum als tmpfs nach jedem Neustart leer ist. Am besten legt man sich in /etc/rc.local eine Zeile an, die den Symlink wiederherstellt.

Für elegantere Lösungen auch dafür bin ich offen.

Erste Fahrt mit einem Stadler Flirt 3

Vor etwa drei Jahren schrieb ich darüber, dass Veolia Verkehr die Ausschreibung des E-Netz-Rosenheims gewonnen hat. Seit vergangenen Sonntag 15.12.2013 fährt die Bayerische Oberlandbahn – Tochter von Veolia Verkehr – unter dem Markennamen Meridian die Regionalzüge im E-Netz-Rosenheim, muss dabei aber leider noch auf Ersatzgarnituren diverser Bahnen (DB-N-Wagen, ÖBB-CityShuttle, ODEG-KISS, OLA-Talent, FLEX, …) zurückgreifen, da Stadler leider noch nicht alle Flirt 3 Triebzüge fertiggestellt hat. Selbst die Zulassung für die bereits ausgelieferten Züge wurde erst am 13.12.2013 erteilt, also quasi in letzter Sekunde.

Die ersten Betriebstage sorgte der Meridian hauptsächlich für schlechte Presse: Mit den eigenen Neufahrzeugen traten wohl diverse Kinderkrankheiten auf aber auch die älteren, ausgeliehenen Fahrzeuge haben ihre Altersleiden demonstriert. Vor dem Hintergrund war ich gespannt, wie meine heutige „Probefahrt“ mit dem M 79039 von München Hbf ab 18:44 nach Grafing Bf an 19:06 verlaufen (planmäßig mit einem neuen Flirt) würde.

Zuerst zum Fahrzeug: Der Innenraum war sauber, der Sitzabstand sowie die Form und Polsterung der Sitze für mich angenehm, die Gepäckablage ist ausreichend groß dimensioniert um meinen gut gefüllten Rucksack zu verstauen. Erstaunlicherweise waren sogar einige weitere Fahrgäste im Zug, die die Gepäckablagen genutzt haben. In den S-Bahn-Zügen oder SOB-Triebwagen werden diese aus mir nicht nachvollziehbaren Gründen eher gemieden. Ich fand am Platz sogar zwei zugängliche Steckdosen, der Zug ist also Nerd-kompatibel. Erstmal in Fahrt fallen jedoch noch Kinderkrankheiten auf: Selbst bei kleinsten Kurven noch in der Haupthalle des Münchner Hbf sind deutliche „Atemgeräusche“ – ich vermute von den Schlingerdämpfern – zu hören. Bei höheren Geschwindigkeiten ist ein deutliches Schlingern des Fahrzeugs mit Wanken des Wagenkastens zu spüren.

Zur Fahrt: Los ging es am Hauptbahnhof bereits mit +7, wobei die BOB dafür nichts konnte: Ein ÖBB-Railjet wurde vor unserer Nase – die Fahrstrasse kreuzend – gemütlich in die Abstellung geschoben. Ab München Ost standen dann tatsächlich einige Fahrgäste, wobei mindestens 1/3 der Sitzplätze frei war… aber manche Leute stehen scheinbar lieber, wenn sie eine Zweierbank nicht für sich alleine haben können. Nachdem die bisherigen 6-N-Wagen-Garnituren nur 540 Plätze boten, eine Flirt-3-Doppeltraktion nun aber 666 Plätze bietet, wäre es auch verwunderlich. Die Verspätung haben wir bis Grafing Bahnhof nicht aufgeholt, aber mein Übergang zur S-Bahn war ausreichend dimensioniert.

Fazit: Ich hoffe, dass Stadler am Schlingern der Fahrzeuge noch etwas verbessern kann und ich drücke der BOB die Daumen, dass die Kinderkrankheiten mit den neuen Fahrzeugen schnell vergehen und die fehlenden Fahrzeuge ausgeliefert werden, damit die Nachteile der Leihgarnituren sich nicht allzulange bemerkbar machen.

Heap-Corruption mittels „gflags“ untersuchen

Heap-Corruption-Fehler (Buffer-Overruns, Double-Frees, …) sind naturgemäß sehr schwer zu debuggen, da der eigentliche Fehler i.d.R. lange vor dem tatsächlichen Programmabsturz stattgefunden hat. Windows bietet für diesen Fall jedoch eine Hilfestellung an, sofern man das Programm „gflags“ aus den „Debugging Tools“ installiert hat:

gflags.exe -p /enable binary.exe [/full]

Das Programm binary.exe wird von nun an in einem Modus ausgeführt, bei dem jede unerwünschte Veränderung des Heaps sofort zu einem Absturz führt. Dadurch kann man der Ursache per Debugger oder Dump-Analyse deutlich schneller auf den Grund gehen.

Der Speicherverbrauch ist in diesem Modus etwas höher und die Arbeitsgeschwindigkeit etwas geringer. Beendet wird dieser Modus wieder mit folgendem Befehl:

gflags.exe -p /disable binary.exe

How-To: IPv6-Adressen der Telekom-DNS-Resolver ermitteln (Update am 27.12.2013)

Bei Twitter tauchte neulich die Frage nach den IPv6-Adressen der Telekom-DNS-Resolver auf. Zufälligerweise habe ich mir die Liste der Resolver wenige Wochen zuvor selbst zusammengesucht. Da die Liste nicht offiziell ist und sich auch möglicherweise ab und an ändert, hier eine kleine Anleitung, wie man sich die Liste selbst ermitteln kann.

Vorab sollte man sich anschauen, wie es mit den IPv4-Resolvern aussieht: Diese sind identisch mit den regionalen HTTP-Proxy-Servern, d.h. wenn man sich die IP-Adressen zu www-proxy.t-online.de ermittelt, hat man die Liste der IPv4-Adressen der Resolver. Per Reverse-Lookup kann man zu jedem Resolver auch recht gut den Standort bestimmen. Das Namensschema der Server ist hier sehr aussagekräftig.

Genauso kann man sich über www-proxy.t-online.de die Liste der IPv6-Adressen der Resolver ermitteln, allerdings kann man dazu nicht einfach per Reverse-Lookup die Standorte bestimmen… mit einem Trick geht es aber doch:

Man nehme einen Webserver mit IPv6-Anbindung und führe nun von einem Telekom-Anschluss aus über die IPv4-Proxy-Adressen Aufrufe auf den Webserver mit IPv6-Anbindung durch. Da die Proxies ihrerseits Dualstack-konform ausgehend wenn möglich IPv6 verwenden, kann man nun im Logfile des Webservers bequem die IPv6-Adresse zum jeweiligen regionalen Proxy zuordnen (genaugenommen sind es je Standort mehrere, da vermutlich ein Load-Balancing zum Einsatz kommt). Leider entsprechend die abgehenden IPv6-Adressen der Proxies nicht 1:1 der hinter www-proxy.t-online.de stehenden Adressen, jedoch kann man über das /64-Prefix den richtigen finden.

Update am 27.12.2013

Zwischenzeitlich hat die Telekom die DNS-Resolver wohl von den HTTP-Proxies getrennt, als DNS-Resolver für IPv6 gelten nun folgende Server:

  • b-dnslb-a01.isp6.t-ipnet.de [2003:180:2::53]
  • d-dnslb-a01.isp6.t-ipnet.de [2003:180:2:1000::53]
  • do-dnslb-a01.isp6.t-ipnet.de [2003:180:2:2000::53]
  • hh-dnslb-a01.isp6.t-ipnet.de [2003:180:2:3000::53]
  • h-dnslb-a01.isp6.t-ipnet.de [2003:180:2:4000::53]
  • k-dnslb-a01.isp6.t-ipnet.de [2003:180:2:5000::53]
  • l-dnslb-a01.isp6.t-ipnet.de [2003:180:2:6000::53]
  • m-dnslb-a01.isp6.t-ipnet.de [2003:180:2:7000::53]
  • f-dnslb-b01.isp6.t-ipnet.de [2003:180:2:8000::53]
  • f-dnslb-a01.isp6.t-ipnet.de [2003:180:2:8100::53]
  • n-dnslb-a01.isp6.t-ipnet.de [2003:180:2:9000::53]
  • s-dnslb-a01.isp6.t-ipnet.de [2003:180:2:a000::53]
  • ul-dnslb-a01.isp6.t-ipnet.de [2003:180:2:b000::53]