Archiv der Kategorie: Internet

Mobiles Internet – 1&1 Notebook Flat

Mobiles Internet nutze ich an sich seit über zehn Jahren. Damals noch per GSM-Einwahl zu vergleichsweise sündhaft teuren Preisen, zwischenzeitlich per HSCSD und seit etwa 3 Jahren per GPRS/EDGE/UMTS/HSDPA. Obwohl mein Mobilfunktarif bei simyo im E-Plus-Netz zur Nutzung per Smartphone vollkommen ausreichend ist und E-Plus zwischenzeitlich EDGE großräumig und HSDPA zumindest in den Zentren ausgerollt hat, wünsche ich mir für die Nutzung am Notebook doch eine performantere Lösung mit einer größeren UMTS/HSDPA-Abdeckung.

Die Tarife der beiden großen D-Netz-Anbieter konnten mich jedoch bisher nicht überzeugen. Zum einen finde ich die Tarife nicht sonderlich verständlich, da braucht man einen Vertrag, dann eine Option für Datennutzung und dann noch einen Datentarif? Zum anderen waren die Tarife, die ich meine verstanden zu haben, einfach zu Teuer. Ein paar Versuche mit einer O2-Freikarte waren von der Performance her in Ordnung, allerdings habe ich auch da das Tarifsystem nicht auf die schnelle Verstanden. Da blieb ich gerne bei der langsameren E-Netz-Alternative.

Seit Anfang  Juli gibt es nun die 1&1 Notebook Flat, die – da im Vodafone Netz – eine brauchbare Performance verspricht, Preislich in einem interessanten Bereich ist und auch ohne Mindestvertragslaufzeit (aber mit den 1&1-üblichen drei Monaten Kündigungsfrist) angeboten wird. Vergangenen Montag Abend bestellte ich also die Notebook Flat.

Diverse Bestätigungsmails kamen von Montag Abend bis Donnerstag verteilt und kündigten mir an, dass die SIM-Karte vom Briefzusteller nur an mich persönlich und nur nach bestandener Ausweiskontrolle ausgehändigt werden würde, da ich noch kein 1&1 DSL-Kunde sei. Liebes 1&1 Team, teilt das dem Besteller doch schon bei der Eingabe der Versandadresse mit, dann kann man nämlich ggf. die Arbeitsadresse angaben, wo man auch eine Chance hat, vom Postboten angetroffen zu werden.

Die SIM-Karte war dann am Freitag im heimischen Postkasten – ohne dass die angekündigte Ausweiskontrolle durch den Briefzusteller stattgefunden hätte. Vielleicht reicht es also, wenn man bei 1&1 bereits Kunde irgendeines Produktes ist und bisher keine Zahlungsausfälle hatte. Liebes 1&1 Team, passt doch dann den Hinweis auf die Ausweiskontrolle durch den Briefzusteller an, wenn es garnicht (nur) davon abhängt, ob man DSL-Kunde bei Euch ist.

Der erste Test von zu Hause aus – bei simyo nur EDGE-Land – verlief auch gleich zufriedenstellend. Die Latenzen sind vergleichbar mit einem 1 MBit/s ADSL-Anschluß, die Übertragungsraten liegen darüber. Interessant ist der bereits in diversen Foren geschilderte Performanceunterschied zwischen den APNs mail.partner.de (voreingestellt) und web.vodafone.de. Beide terminieren in unterschiedlichen Vodafone-IP-Adressbereichen, ersterer ist hier nur 1/3 so schnell, zeigt jedoch bei ausgehenden Traceroutes alle Hops richtig an, letzterer bietet schnellere Übertragungsraten, zeigt jedoch bei Tracerouts nach dem ersten Hop immer nur die Adresse des Traceroute-Ziels an… Weitere Versuche gibt es dann nächste Woche aus der Bahn auf dem Weg von und zur Arbeit.

Mobiles Internet in Kroatien

Auf Druck der EU gibt es seit 1. Juli 2010 eine „Kostenbremse“ für das Mobilfunk-Datenroaming, also die Nutzung von Datendiensten in ausländischen Mobilfunknetzen. Diese Regelung bringt dem Kunden allerdings nur dann etwas, wenn er seinen Auslandsaufenthalt in einem anderen EU-Land verbringt, zum anderen gibt es häufig durch den Kauf einer Prepaid-Karte eines regionalen Anbieters die Möglichkeit noch deutlich günstiger Telefonieren oder auch Surfen zu können.

Bei unserem diesjährigen Kroatienaufenthalt haben wir uns eine Prepaid-Karte der kroatischen T-Mobile besorgt. Das sogenannte „Simpa Internet“ Paket wird in Varianten mit und ohne Huawei-USB-Modem und verschiedenen Startguthaben verkauft. Wir haben ein Paket für 150 Kuna (das sind ca. 21 EUR) inkl. Huawei-USB-Modem und 50 Kuna Prepaid-Guthaben erworben. Ohne eingestellte Option kostet danach 1 MB mobiles Internet genau 1 Kuna (ca. 14 ct.) und das im Netz von T-Mobile HR. Da sollte sich T-Mobile DE mal eine Scheibe abschneiden.

Noch günstiger geht es dann mit Tagespaketen: Für jede Aufladung von mindestens 100 Kuna erhält man ein Tagespaket geschenkt (sofern man es innerhalb von 30 Tagen auf dem regulären Weg bucht). Der normale Preis des Tagespakets liegt bei 20 Kuna, dafür kann man genau 24 Stunden ab Aktivierung maximal 250 MB versurfen. Die Buchung erfolgt dabei per SMS-Dialog an die 3636. Man beginnt den Dialog mit einem „A“ und erhält als Antwort eine SMS mit den möglichen Optionen. Zwar ist diese SMS in kroatisch formuliert, jedoch findet man sich anhand der gängigen Abkürzungen „1h“ und „24h“ gut zurecht. Mit einer zweiten SMS mit dem Inhalt „2“ bucht man nun die 24h-Option und muss nun noch nach einer letzten „Wollen Sie wirklich?“-Frage mit „DA“ bestätigen. Der Preis des Tagespakets ist mit umgerechnet ca. 2,80 EUR etwas unter dem Durchschnitt der mobilen Tagespakete in Deutschland angesiedelt.

Achtung: Die Konditionen und Optionen können sich natürlich ändern, am besten informiert man sich unter www.t-mobile.hr vor dem Urlaub über die aktuellen Angebote sowie die Prozedur zur Buchung von Optionen.

Der Kampf mit dem Server-Support eines Hosters

Seit 2003 hatte ich diverse Root-Server bei einem großen deutschen Hoster angemietet – insgesamt bisher 6 (okay, einer war nur ein virtueller Server). Bei zwei aufgetretenen Defekten (Netzteil und Festplatte) und der Beantragung der IPv6-Tunnel und -Reverse-Delegationen gab es bisher nur positive Erfahrungen mit dem Server-Support dieses Hosters.

Den letzten Monat bemühte sich der Server-Support jedoch, dass sich dieses Bild wandelt, doch von Anfang an:

Anfang März 2010 wurde eine neue Servergeneration mit neuen Preisen angeboten und ich nutzte die Gelegenheit und bestellte einen Nachfolger für einen im Juni auslaufenden Root-Server. Da ich Einrichtungszeiten von mindestens einigen Tagen gewohnt war, überraschte mich die Bereitstellungszeit von nur 2 Stunden. Außerdem überraschte mich, dass die zugeteilte IP-Adresse aus einem Bereich war, der meines Wissens nach bisher nicht für Root-Server verwendet wurde. Aber egal, Adresse ist Adresse, sollte man meinen… Für diverse NNRPD-Instanzen waren noch weitere IP-Adressen notwendig, die dann allesamt wieder aus den bisher „typischen“ Adressbereichen für Root-Server kamen.

Anfang April 2010 stand dann der Umzug meines Primary-DNS auf den neuen Server an. Komischerweise scheiterten diese Umzugsversuche jedoch daran, dass der Secondary-DNS – auch im Netz das großen Hosters befindlich – die Zone-Files nicht von meinem neuen Primary-DNS abrufen konnte.

Verwunderte stellte ich fest, dass von der primären IP-Adresse des Systems aus (die aus dem mir ungewöhnlich erscheinenden IP-Adressbereich) tatsächlich keinerlei Kontakt zum Secondary-DNS (wohlgemerkt auch beim selben Hoster befindlich) möglich war. Auch weitere „neben“ dem Secondary-DNS stehende Hosts und der Router direkt „davor“ waren nicht erreichbar. Von jeder der zusätzlich bestellten IP-Adressen aus funktionierte es jedoch problemlos. Ich dachte mir also: „Okay, liegt halt eine temporäre Routingstörung zu dem einen Adressbereich vor, aber ich hab’s nicht eilig, warten wir mal ein paar Tage ab.“

Am 18. April lag das Problem noch immer vor. Ich entschloss mich, nun den bisher guten Server Support einzuschalten. Kann ja nur eine Kleinigkeit sein… denkste. Zwei Versuche mit dem Kontaktformular scheiterten, weil das System trotz ausgewähltem Thema darauf bestand, dass man ein Thema auswählt, also das ganze nochmal per Mail geschildert und zwei Traceroutes – einmal nicht funktionierend von der primären IP-Adresse und einmal funktionierend von einer zusätzlichen IP-Adresse – angehängt. Der Übersichtlichkeit halber habe ich den Hopcount bei den Traceroutes auf 10 beschränkt, da bereits mit Hop 5 das Problem deutlich wird… erster Fehler.

Am 22. April kam die erste Antwort, ich solle doch Traceroute nicht auf 10 Hops limitieren sondern bei 30 Hops belassen, dann würde es funktionieren. Okay, schicken wir das Ganze halt nochmal mit unbegrenzten Traceroutes. Natürlich hilft es nichts, 30 Hops zuzulassen.

Am 29. April kam die zweite Antwort, ich solle doch ICMP statt UDP verwenden. Hm, das mag dem Supporter geholfen haben, von sich aus per Traceroute Kontakt zu meinen Secondary-DNS aufzunehmen. Ich kann ihn von der primären IP-Adresse aus gar nicht erreichen, und selbst wenn ICMP funktionieren würde: Wie soll man einen DNS-Zone-Transfer per ICMP machen? Also habe ich das Problem in der Antwort nochmal genau geschildert, ich wurde ja wohl falsch verstanden…

Leider habe ich die nun folgende Antwort vom 30. April mit der Bitte um einen Shell-Zugang, um das Problem nachvollziehen zu können, erst am 18. Mai, als die Bitte wiederholt wurde, gesehen und selbigen Zugang sofort eingerichtet, da ich nun Hoffnung hatte, dass man das Problem endlich offensiv angehen möchte.

Am 19. Mai erhielt ich die Antwort, dass man das Problem von meinem System aus nicht nachvollziehen könne. Die mitgeschickten Ausgaben von Ping und Traceroute zeigten jedoch, dass sich der Supporter um eine Stelle in der IP-Adresse vertan hatte. Ich antwortete ihm nochmal, welche genauen Adressbereiche betroffen wären.

Am 20. Mai erhielt ich die Antwort, dass die Ursache für das Problem sei, dass ich keine Routen für 127/8 und 169.254/16 definiert hätte. Okay, diese Routen bringen zwar absolut nichts, aber sie schaden auch nichts (sollte man meinen). Also lege ich sie an, probiere es sicherheitshalber nochmal aus und teile dem Supporter mit, dass es auch mit den gewünschten Routen (natürlich) nicht geht.

Am 21. Mai erhielt ich nun die Antwort, dass man nochmals nach der Ursache gesucht habe, aber leider das Problem weiterhin nicht nachvollziehen könne. Ich solle das System doch neu installieren, um eventuelle Konfigurationsfehler auszuschließen und mich – wenn es danach wieder auftritt – erneut melden. Da es bei allen zusätzlichen IP-Adressen kein Problem gibt, nur bei der primären IP-Adresse, ist für mich klar, dass es nicht an der Konfiguration liegen kann. Insbesondere, da die Netzkonfiguration im wesentlichen identisch zu meinen anderen Servern beim selben Hoster ist. Ich antworte dem Support also, dass die Fehlersuche auf meinem Server nichts bringen wird, da aus den bisherigen Analysen bereits erkennbar sei, dass das Problem nicht auf dem Server zu suchen ist und bitte ganz konkret darum, auf dem Router direkt vor den nicht erreichbaren IP-Bereichen (der selbst über die primäre IP-Adresse auch nicht anpingbar ist) nach der Ursache zu suchen. Wahrscheinlich erschlägt man damit alle Probleme auf einmal.

Am 22. und 24. Mai erfolgten weitere Shell-Logins vom Server-Support und .bash_history zeigte, dass man sich jeweils die Routing-Tabelle auf dem Server ansah. Dann folgte wieder eine E-Mail, mit dem Hinweis darauf, dass ich die Routing-Tabelle auf dem Server verändert hätte (ich wurde ja am 20. Mai darum gebeten, diese zu verändern) und ich solle doch den Server neu installieren, damit ein Konfigurationsfehler ausgeschlossen werden kann. Wenn das Problem dann immernoch bestehe, würde man die Sache an die Netzwerker übergeben.

Aha, aus den bisherigen Antworten konnte man erahnen, dass ich nicht mit Netzwerkern zu tun hatte, aber nun gaben sie es offen zu.

Ich wollte mir natürlich die unnötige Neuinstallation – die keinerlei Änderung herbeiführen würde – sparen, daher habe ich testweise in das Rescuesystem (das ja richtig konfiguriert sein müsste) gebootet und dort die Verbindung zum Secondary DNS geprüft – natürlich auch mit negativem Ergebnis. Hoffentlich gibt sich der Support nun damit zufrieden und eskaliert das Problem endlich an jemanden, der tatsächlich Ahnung von Routing hat.

Am 25. Mai dann wieder eine Mail vom Support, ich solle doch bitte Traceroutes aus dem Rescue-System heraus machen und schicken. Blöd, dass Traceroute beim Rescue-System nicht installiert ist, aber das kann ich mir ja von einem anderen System per SCP holen. Sicherheitshalber machte ich die Traceroutes mit UDP und auch noch ICMP, damit man mir nicht – wie ganz zu Anfang – einfach rät, ICMP statt UDP zu benutzen.

Am 26. Mai stellte ich mittags fest, dass sich zweimal ein Support-Mitarbeiter auf dem Server eingeloggt hat. Dabei hat er sich die Routingtabelle und die Ausgabe von ifconfig angesehen, die beiden dort erscheinenden IPv6-Tunnel (zum IPv6-Gateway des Hosters und zu mir nach Hause) heruntergefahren, per traceroute verfiziert, dass das Routingproblem weiterhin besteht, und dann die beiden IPv6-Tunnel wieder gestartet. Am Abend des 26. erhielt ich eine Mail, in der nach den Ausgaben von route -n und ifconfig gefragt wird (hm, hat man sich doch mittags schon selbst angesehen), da diese sich augenscheinlich verändert hätten. Ja, natürlich haben die sich verändert, schließlich wurde ich am 20. gebeten, unnütze Änderungen vorzunehmen, und habe diese nach der Mail vom 24. wieder rückgängig gemacht.

Am 27. Mai fand noch vor 9 Uhr morgens erneut ein Login eines Support-Mitarbeiters auf dem Server statt. Es wurden erneut die IPv6-Tunnel heruntergefahren, ein traceroute versucht und dann die IPv6-Tunnel wieder hochgefahren. Nach 11 Uhr fand erneut ein Login statt, den ich erst gegen halb 12 bemerkt habe. Diesmal hat der Support-Mitarbeiter mittels mtr ein paar Ziele zu erreichen versucht, und siehe da: Plötzlich funktioniert alles einwandfrei. Nach 14 Uhr bekam ich dann eine E-Mail vom Support, in der man mir nun endlich nach nochmaliger Untersuchung die Behebung des Problems meldete und – ich hätte das nicht mal erwartet – eine angenehme Gutschrift ankündigte.

Liebes Server-Support-Team, es freut mich, dass das Problem dann doch noch gelöst werden konnte. Ich war schon kurz davor aufzugeben und meinen DNS-Kram auf einen anderen Root-Server (von einem anderen Anbieter) umzuziehen. Schön wäre es natürlich, wenn andere mit einer solch konkreten Problemmeldung sich zukünftig nicht erst wochenlang über viele hingehaltene Stöckchen kämpfen müssten. Ich wette, die eigentliche Problembehebung war, nachdem meine Meldung endlich an die richtige Stelle weitergegeben wurde, vergleichsweise schnell erledigt.