HFO Telecom bringt Ansage, dass Sprachkanäle begrenzt sind

Seit Anfang Dezember 2018 erhalte ich Beschwerden von Kunden der HFO Telecom, dass sie die Ansage hören, die maximale Anzahl von Sprachkanälen sei erreicht. Weitere Telefonate können dann nicht mehr geführt werden. Dies tritt ein, wenn zwei Leitungen belegt sind, obwohl vertraglich mehr Sprachkanäle ausgehandelt sind.

Nach Aussagen der HFO Hotline vom 10.Dezember ist dieses Verhalten auf einen Fehler zurückzuführen und sollte nun der Vergangenheit angehören.

HFO Telecom Ausfall

Seit mindestens 6 Uhr am 04.12.2018 wird mir von erheblichen Problemen bei der Erreichbarkeit von Anschlüssen berichtet, die beim SIP-Provider HFO Telecom konnektiert sind. Kunden klagen über einseitige Gespräche, abgehackte Anrufe oder auch totale Unerreichbarkeit.

Die Hotline des Anbieters konnte ich um 8 Uhr gar nicht erst erreichen.

Seit 10.21 Uhr ist der Status bei „NGN-Telefonie“ auf „schwerer Ausfall“ geändert.

Trotz Allem finde ich gut, dass der Anbieter Transparenz zeigt und die Vorfälle auf seiner Statusseite zeitnah publiziert.

Seit 13 Uhr entspannt sich die Lage. Die Kunden können wieder telefonieren.

VPN Durchsatz bei AVM’s Fritzbox

Der VPN Durchsatz der Fritzbox hat mich lange interessiert. Eben weil ich Heimzugänge mit Firmen damit gerne vernetzen wollte. Meine Erfahrungen mit dem Durchsatz waren dabei immer wieder ernüchtern. Mit dem Modell 7490 bekam ich immer nur maximal 1,2 Mbyte/s (entsprechend etwa 10MBit/s) durch die Leitung, egal ob eine weitere Fritzbox oder z.B. eine pfsense oder Linux im Rechenzentrum als Gegenstelle fungierte.

Gut, man kann einwenden, dass die Fritzbox ein Konsumer-Produkt und keine Enterprise Firewall ist. Und man darf sich darüber bewusst sein, dass nur wenige Kunden die Firewall-Funktionalität nutzen, gemessen an den gesamten Verkaufszahlen. Trotzdem dürften es sicher bestimmt einige zehn- bis hunderttausende Nutzer sein.

Recherchen zum VPN-Durchsatz blieben regelmäßig unklar. AVM vermied es, sich in irgendeiner Weise zum Durchsatz zu äußern. Tausend Meinungen in Foren, wenig kontextuelles Verständnis [1], schon gar keine brauchbaren Fakten.
Ein Datendurchsatz wie zu Modemzeiten, schrieb ein Forenteilnehmer jedoch passend im Jahr 2016.

Ebenfalls im Jahr 2016 misst ein Johannes Weber unter https://blog.webernetz.net/fritzbox-vpn-speedtests/ den Durchsatz unter professionelleren Bedingungen, und bestätigt, was ich auch immer messe: Der Durchsatz liegt üblicherweise bei höchstens um die 9 MBit/s. Unterirdisch.

Unter diesem Link schiebt der Hersteller AVM den Durchsatz sogar auf das Verhältnis von Overhead zu Payload, d.h. den Verwaltungsdaten zu Nutzdaten, das noch unter der alten Fritzbox 7390, bei der die CPU der noch limitierendere Faktor gewesen sein dürfte und noch lange nicht einmal 10 Mbit drin waren.

Ich hätte mir etwas mehr Ehrlichkeit von AVM gewünscht gegenüber den Kunden! Dass VPN immer langsamer als der native NAT-Durchsatz ist, das dürfte fast jedem klar sein. 20% Abzug, völlig normal.  Aber bei einer Diskrepanz von mehreren hundert Prozent, wenn man z.B. eine 50 oder 100 MBit Internetleitung betreibt und gerade mal 10 Mbit VPN-Durchsatz hat, da kommt man sich schon ziemlich „veräppelt“ vor, bei Hersteller-Aussagen, wie oben angeführt.

Die Zeitschrift C’t kommt mit den Durchsatzmessungen in Ausgabe 21/18 zu den selben Ergebnissen, wie meinen eigenen, als auch denen von Johannes Weber.

Ich tunnele nun mit OpenVPN und AES-NI-fähigen Prozessoren, damit ist der Durchsatz praktisch Wire-Speed (abzüglich Oberhead).

Utax Drucker und die Druckwarteschlange

Wie unter „https://www.nicht-trivial.de/index.php/2018/09/13/druckwarteschlange-stuerzt-unregelmaessig-ab/“ bereits angemerkt, stürzt auf einem Windows Server Betriebssystem unregelmäßig, aber häufig, die Druckwarteschlange ab. Und zwar sowas von „ab“, dass selbst Windows den Dienst selbsttätig nicht mehr startet. In einigen Fällen war sogar der Befehl „net stop Druckwarteschlange“ wirkungslos und produzierte nur den Ereigniseintrag (Eventlog) mit EventID: 7011 „Das Zeitlimit (30000 ms) wurde beim Warten auf eine Transaktionsrückmeldung von Dienst Spooler erreicht.“

Weiterhin sind gehäuft Meldungen mit EventID 1530 aufgetaucht:
„Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. “ betreffend \Device\HarddiskVolume1\Windows\System32\spoolsv.exe .

Bisher hatte ich die UTAX Druckertreiber in Verdacht. Der Verdacht hat sich nun erhärtet, als ich den Tipp bekam, den virtuellen Druckeranschluss (Standard TCP/IP Port) von RAW auf LPR umzustellen. Seither läuft die Druckwarteschlange stabil.

 

Druckwarteschlange stürzt unregelmäßig ab

Ein neuer Druckertreiber bringt offensichtlich den Spoolerprozess alias Druckwarteschlange unter Windows Server zum Absturz. Oder genauer gesagt wird die Druckwarteschlange in einen Zustand gebracht, in der sie nicht mehr reagiert, aber nicht ordentlich beendet wird. Das hat zu Folge, dass die Druckwarteschlange von Windows nicht als nichtfunktionierend erkannt und der Dienst neu gestartet wird. Supportanrufe diesbezüglich und manuelles Starten des Dienstes  lassen schnell nach Wegen suchen, die Sache automatisiert aus der Welt zu schaffen.

Die Lösung besteht derzeit daraus, ein Batch-Skript in Endlosschlaufe laufen zu lassen. Das Skript prüft auf Existenz eines vorhandenen Druckers. Wenn dieser nicht auffindbar ist, wird die Druckerwarteschlange neu gestartet.  Da rundll32 keinen auswertbaren Errorlevel zurück gibt, muss man über den Parameter /f eine Datei anlegen, welche als Indikator für den Fehlerfall dient. Bei jedem Neuaufruf der Skriptschleife wird die Datei (bei Existenz) wieder gelöscht.
Die Verzögerung wird über Pings an’s eigene System realisiert.
Ich setze zusätzlich noch eine „1“ per zabbix_sender an mein unabhängiges Monitoring-System Zabbix ab, um die Häufigkeit des Eingriffs mitzuloggen.

das Skript chkPrter.cmd:

@echo off
cls

SET PrinterName=Rechnungsdrucker
SET TESTfile=%TEMP%\PrtExist.txt

:start

REM Delete %TESTfile% to avoid false positives
IF EXIST „%TESTfile%“ (
DEL %TESTfile% /F /Q
)

REM Try to get the printer settings into a file
RUNDLL32.EXE PRINTUI.DLL,PrintUIEntry /Xg /n „%PrinterName%“ /f „%TESTfile%“ /q

IF EXIST „%TESTfile%“ (
REM ECHO Drucker %PrinterName% existiert
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 1 > NUL
) ELSE (
REM ECHO Drucker %PrinterName% existiert NICHT!
NET START Druckwarteschlange
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 0
)

ping -n 30 localhost > NUL

goto start

1&1 PHP extended Support

1&1 will Feedback …können sie haben. Und wenn ich mir schon die Mühe mache, dann gerne auch gleich öffentlich:

Ob ich zufrieden bin mit den Produkten von 1&1:
-> Da bin ich zwiegespalten. Manche Produke sind durchaus nutzbar. Aber da ist trotzdem immer Luft nach oben. Wenn ich neue Dienstleistungen in dem Bereich benötige, dann suche ich mir mittlerweile die Konkurrenz aus. Ihr (1&1) wollt mehr wissen? Das geht dann schon schnell in Richtung einer handfesten Beratung. Und Consulting kostet Geld. Punkt.

Ob ich 1&1 weiterempfehle: NEIN!
Zum dritten Mal nun schon flattert mir eine Rechnung über einen „PHP extended Support“ ins Postfach, verbunden mit der Selbstbedienung von meinem Bankkkonto.
Wir haben uns in den letzten Jahren bereits mehrfach am Telefon über die Praktik unterhalten: Dem Kunden wird ungefragt eine nicht willentlich gebuchte Leistung in Rechnung gestellt. Dazu sogar noch eine Leistung, die man oftmals gar nicht braucht.
Nach telefonischer Beschwerde wurde mir bisher das Geld wieder gutgeschrieben, wohl wissentlich, dass diese Geschäftspraktik alles andere als seriös ist. Wahrscheinlich ist das sogar rechtlich grenzwertig . Natürlich rufe ich immer persönlich auf der Hotline an. Ich gehe davon aus, dass Konzerne wie 1&1 nichts mehr scheuen als Kunden, die sich persönlich mit ihnen unterhalten wollen, denn das produziert Kosten. Hotline-Mitarbeiter kosten leider Geld. Also ran an die Strippe, 0721-9600 anrufen!

Das Geschäftsmodell mit dieser Praktik dürfte Folgendes sein: Kunden sind meist träge. Damit kann man Zaster machen.
Bei z.B. hunderttausend Hosting-Verträgen kann man einen PHP extended Support geltend machen, von denen es dann 50% gar nicht so schnell bemerken oder gar wissen, ob sie das brauchen. Von den übrigen 50% beschweren sich dann nur 5% und ein noch kleinerer Prozentsatz ist darüber ausreichend verärgert, dass er den Vertrag kündigt, bzw. zu einem seriösen Anbieter umzieht. Macht summa summarum: ganz fette Gewinne!

Aber zurück zum Feedback: 1&1-Vorstandsabteilung, ihr habt’s geschafft. Früher habt ihr mich von Hotline-Mitarbeitern zuhause und sogar auf dem Handy genervt, wenn ihr für eure Produkte werben wolltet. Meine Willenserklärung am Telefon, das zu unterlassen, habt ihr ignoriert, bis ich endlich in euerem Control-Center die tief versteckte Checkbox gefunden habe, Werbeanrufen zu widersprechen.

Und nun wollt ihr Feedback, wo ihr sonst nie zuhört. Wirkt auf mich ehrlichgesagt etwas Schizophren.

Nein, 1&1, so schnell nicht wieder!


Nachtrag: Herr M. von der Hotline hat auch zum dritten Mal die Rechnung gutgeschrieben. Meine Rückfrage, ob sich PHP komplett deaktivieren ließe, musste Herr M. verneinen. Sinngemäß „könne man es bei der Anzahl der Kunden nicht jeden recht machen“.
Ich interpretiere das so: Die Einnahmen rechtfertigt diese Geschäftspraktik. Die Controling-Abteilung wird gewiss entsprechende Geschäftszahlen herausarbeiten und daraus ableiten können, wie viele Kunden seit Einführung des „PHP Extend Supports“ 1&1 den Rücken gekehrt haben.
Denn: Es wäre ein Klacks, eine Checkbox im Control-Center zu implementieren, in der der Kunde entweder erklären kann, dass er gar kein PHP benötigt und damit die Frage nach einer Versionierung hinfällig ist, oder in der er dem automatischen Versionsupgrade zustimmt. Aber dann würde 1&1 ja keine derzeit 5,31€ pro Monat pro Kunde, der nicht widerspricht, verdienen.

Links zu ebenfalls verärgerten Kunden:

https://skillday.de/php-extended-support-von-1und1-kuendigen-widersprechen/

http://blog.mecksite.de/2017/02/13/was-bedeutet-11-extended-support-bauernfaengerei/

Und in diesem Forum möchte ein 1&1-Mitarbeiter eine Diskussion um die rechtliche Situation der Angelegenheit ungern öffentlich führen: http://www.joomlaportal.de/off-topic/315570-1-und-1-nicht-beauftragte-kostenpflichtige-zusatzleistungen.html

Warum wohl?

vi und Pagedown innerhalb SSH Session in osx-Terminal

PageUp und PageDown steht innerhalb von SSH-Sessions auf OSX leider nicht zur Verfügung. Das macht das Navigieren in Dateien sehr unkomfortabel. Speziell beim Editieren mit vi oder vim unter Linux ist das mehr als nervig.

Eine Abhilfe in vi ist der Shortcut STRG+f für Seitensprung vor und STRG+b für einen Rücksprung.

IPv6-Routing im Telekom-Netz

Bisher bin ich davon ausgegangen, dass die Telekom als ausgewachsener Carrier im Jahr 2018 bereits ausreichend Erfahrung mit IPv6 gesammelt hat. Und dass die Telekom Routing-Fehler in ihrem Netz mittels vorhandener Tools schnell und effizient beheben kann. Weit gefehlt.

Ein Kunde hatte die letzten drei Jahre als Glasfaser Internetanschluss „Company Connect 34MBit“ für 899€/Monat am laufen, inklusive IPv6 Netz in der Größe /48, was auch funktionierte.

Nun kam es dazu, dass der Anschluss zu „DeutschlandLAN Connect IP“ 100Mbit (für knapp 800€/Monat) umgeschaltet wurde. Neue Glasfaser beleuchtet, Router und Netzabschluss ausgetauscht, Routen auf die neue Schnittstelle umgeschaltet. IPv4-Netze sind nach dem Umschalten nach ein paar Minuten da, es scheint alles ok soweit. IPv6 an der WAN-Schnittstelle ist  erreichbar, sieht auch gut aus.

Nebenbei wurden die Firewalls beim Kunden hochgepatcht, weil ein Update verfügbar war.

Nun kam es jedoch, dass interne Rechner nicht mehr per IPv6 ins große weite Netz kamen, pings endeten an der Firewall. Lange doktere ich herum, verfluche die Firewall, die letztendlich unschuldig war. Pings funktionieren von A nach B, von B nach C, aber nie von A nach C. Wobei B die Firewall ist. TCPDump zeigt auch, dass Pakete rausgehen, aber nicht zurück kommen. Ich suche nach dem Fehler, warum die IPv6 Paket an der WAN-Schnittstelle gar nicht erst zu sehen sind,  während Pings, die von der Firewall selbst abgesetzt werden, einwandfrei zurück kommen. Ich bin erstmal ratlos. Von dem /48 Netz nutze ich als Transfernetz zwischen Telekom-Router und der Kunden-Firewall allerdings nur ein /64-Netz. Und genau dieses ist auch erreichbar. Es kann nur noch eine Erklärung für das Phänomen geben: Die Ursache muss extern liegen.

Alles deutet darauf hin, dass nur noch ein /64 geroutet wird, die Firewall ist außen erreichbar, nicht jedoch dahinter liegende Netze. Anruf bei der Telekom Business-Hotline. Der Mitarbeiter bestätigt, dass irgendetwas faul ist, ich soll den Fall per Email schildern. Schreibe Email an die Telekom mit detaillierter Beschreibung.

Sehr geehrte Damen und Herren,

wir bitten um Überprüfung der IPv6-Konnektivität auf dem /48-Netz [2003:58:802A:0:0:0:0:0].
Seit Umstellung der Leitung auf DeutschlandLAN Connect IP kann nur noch das /64 Netz (z.B. [2003:58:802A::8] erreicht werden. „Dahinter“ liegende Netze werden ab Router [2003:0:8400:e800::1] nicht weiter geleitet.
Zum Testen läuft IP:[2003:58:802A:2:250:56af:fea7:8e7c], welcher per ICMPv6 erreichbar sein sollte.

Es folgt gegen 17:30 Uhr ein Anruf der Business-Hotline. Der Mitarbeiter gibt zu Wort, dass das Problem in der Tat so bestätigt werden kann. Leider könne er die Routen derzeit nicht korrigieren, da die benötigten Tools (noch) nicht zu Verfügung ständen. Wir sollten eine Änderungsauftrag über den entsprechenden Vertriebsmitarbeiter eingeben.

Ich schicke die Email mit erweiterter Erklärung an unseren Vertrieb’ler und seinen Mitarbeiter im Office. Mir schwant schon, dass das eine längere Sache wird, da ich von Vertrieb’lern bisher wenig zufriedenstellende Antworten bekommen habe. Die Antwort kommt prompt in Form einer fehladressierten Emaill, die eigentlich an den Vertrieb’er gehen sollte:

Hallo Cheffe,

ist dir bekannt, was hier zu tun ist?
So ein Thema hatte ich noch nicht.

Da IPv6 glücklicherweise nicht geschäftskritisch ist und die IPv4-Netze funktionieren, lasse ich dem Vertrieb freundliche drei Tage Zeit, bis ich per Anruf nachharke. Der Vertriebsmitarbeiter, hörbar bemüht, möchte seinerseits nachharken. Mich erreicht eine Information, die „IP-Adressänderung sei über den Innendienst angewiesen“.
<zyn on>Wie ab die doch gehen.<zyn off>

Fünf Tage später ist alles noch beim Alten. Zur Abwechslung rufe ich wieder die Business-Hotline an. Die Dame am andere Ende der Leitung ruft sich den Fall auf und entscheidet sofort, die Angelegenheit an ihren Kollegen weitergeben zu müssen, er wird sind melden.
Am nächsten Tag erreicht mich morgens folgende Email:

bei der Übernahme von Company Connect (CoCo) auf Deutschland LAN IP (DCIP) ist auf dem RD eine statische Route vergessen worden.
Diese Route wurde nun im RD-Profil zugefügt.

Sollten Sie in einer verkehrs-schwachen-Zeit Ihren RD neu starten, sollte die IPv6-Connectivity wie gewohnt funktionieren.

Ich möchte Sie jedoch bitten, sich an Ihren vertrieblichen Ansprechpartner zu wenden und über ihn, einen Korrekturauftrag (IP-Adressauftrag einzustellen).

Ich wünsche Ihnen noch eine angenehme Restwoche und verbleibe mit freundlichen Grüßen

Aha, aha. Professionell wurden Abkürzungen für die Produktnamen in Klammern eingefügt (wozu?), aber RD nicht erklärt. Glücklicherweise ist aus dem Kontext ableitbar, dass es sich um unseren Telekom-Router handeln muss. Aber was um Himmels willen soll ich mit dem letzten Absatz anfangen? Klappt’s nun, wenn die den Router neu starte, oder soll ich nun wiederholt einen IP-Korrekturauftrag an den vertrieblichen Ansprechpartner stellen? Und wenn ja, warum?

Ich wähle wieder die Hotline-Nummer. Wer logisch inkonsistente Informationen sendet, darf sich gerne erklären.
Der Mitarbeiter am Telefon ist gleich im Bilde – noch bevor ich unsere Kundennummer nennen darf. Ich bin verblüfft. Üblicherweise darf ich erstmal alles erklären, unsere Kundennummer nennen, ggf. ein Password und noch eine Leitungsbezeichnung, um dann drei mal hin- und herverbunden zu werden und stets die selbe „Geschichte“ von Neuem zu erzählen. Und dieser Mitarbeiter weiß sofort bescheid.
Ich frage nach dem tieferen Sinn, speziell des letzten Absatzes in der letzten Email. Er bestätigt, dass man das nicht so ganz verstehen kann. Aber letzten Endes müsse diese „quick&dirty“-Änderung noch dokumentiert werden, und dafür sei wiederum der Vertrieb zuständig. Ich erspare ihm meine Frage, warum ICH das nun machen solle, denn die Antwort kann ja eigentlich nur lauten: „weil wir’s einfach nicht drauf haben“.
Ich erkundige mich allerdings noch danach, ob die Änderung in unserem Telekom-Router ausreiche, da meine Diagnose darauf hindeute, dass die Route auch im tiefer liegenden Netz korrigiert werden müsse. Die Antwort fällt wie erwartet aus: „Das sehe man ja dann, wenn es immer noch nicht funktioniere“.

Für 21 Uhr habe ich von entfernt über das Outlet-Segment der USV, an welcher der Router hängt, einen Hard-Reset programmiert. Nachdem die Internetverbindung wieder online war, funktionierte IPv6 tatsächlich wieder im kompletten /48-Raum.