Es ist (hoffentlich) geschafft

Heute rief mich ein T-Com Techniker an. Er habe nun die Leitung zum Verteilerkasten bei mir in der Nähe getauscht. Auf der alten läge ja auch zuviel, sagte er.
Er habe dann mehrfach gemessen und eine Rauschunterdrückung von 14 dB gemessen.
Und siehe da, meine Statistik bringt folgendes Bild:

Das sieht doch mal vertrauenserweckend aus. Ich hoffe, dass das Problem nun gelöst ist.

 

Fehler bei der Fehlermeldung …

Manchmal geht ja wirklich alles schief. Ihr ein weiterer Fall dazu:
Gestern war meine T-DSL-Leitung kaum zu gebrauchen. Bis abends gab es mindestens 6 außerplanmäßgie Wiedereinwahlen. Zum Teil musste ich die DSL-Leitung manuell trennen.
Dafür kam dann abends der neue Splitter. Ich habe diesen dann angeschlossen. In den darauffolgenden zwei Stunden war die Leitung auch noch mindestens zweimal weg.
(Ich spreche hier jeweils von mindestens, weil ich diese Zahlen aufgrund der Änderungsmeldungen an dyndns.org ermittle. Dieses Skript läuft aber erst nach einiger Zeit nach Wiedereinwahl. Wenn also vorher die Verbindung weg ist, wird das nicht gezählt …)

Also habe ich mal wieder eine Störungsmeldung bei der T-Com aufgeben wollen. Es ist beim Wollen geblieben. Als ich das Formular abschicken wollte, hagelte es MySQL-Fehlermeldungen
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /www/m7/ebusiness/kundendienst/inc/class_analyzeformular.php on line 634

Notice: Undefined variable: email in /www/m7/ebusiness/kundendienst/inc/class_analyzeformular.php on line 655
Dann wollte ich meinen Frust über diesen ganzen Ärger hier protokolieren – und siehe da, ein Einloggen war auch hier nicht möglich. Es kam immer nur eine leere, weiße Seite ….

nö, hier ist kein Splitter bestellt ….

Der Telekom Techniker, mit dem ich am Samstag sprach, wollte mir ja einen Splitter zu schicken. Noble Vorsätze, aber dabei blieb es…
Heute, Mittwoch Abend, ist weit und breit kein neuer Splitter in Sicht.
Da telefonierte ich mal wieder mit der T-Com und erfuhr, dass da kein Splitter bestellt sei.
Jetzt soll mir aber einer zugeschickt werden. Wer möchte mit mir wetten ??

DSL-Modem Statistiken

Mittlerweile bin ich soweit, dass ich Statistiken meines Teledat 302 abrufen kann. Ich habe festgestellt, dass es sich dabei gar nicht um ein reines DSL-Modem handelt. Es ist vielmehr ein kastrierter Router, mit DHCP-Server etc.
Nun gut. Ich beschreibe demnächst mal, wie ich an die Daten kam. Wichtig erscheint mir aber zunächst die Erkenntnis, dass meine Leitung wohl nicht so prickelnd ist. So zeigt mir mein Modem eine SNR zwischen 1.0 und 4.0 an. Wenn ich nun den Text
Fällt der SNR bei laufendem DSL-Betrieb unter 3-6 dB (je nach Modem/DSLAM) bricht die Verbindung ab und es wird neu verhandelt.
beachte, so sollte ich keine Verbindung erhalten …

Dafür war es heute abend wieder soweit, dass nichts mehr ging.
Ich habe diesmal auch einen alternativen Provider ausprobiert — ohne Erfolg. Es scheint wirklich ein Leitungsproblem zu sein.
Ich habe mich dann in den Logfiles des Modems mal umgesehen und die folgenden Zeilen gefunden:
0000-00-00 00:00:01 E |System               |Current Mode: Bridge
0000-00-00 00:00:01 E |DSL                  |DataPump Version – 01.01.10.00
0000-00-00 00:00:01 E |DSL                  |State: WAITING
0000-00-00 00:00:02 E |Ethernet             |Link 1 Up – 100Base-TX Full Duplex
0000-00-00 00:00:05 E |DSL                  |State: INITIALIZING
0000-00-00 00:00:16 E |DSL                  |State: WAITING
0000-00-00 00:00:19 E |DSL                  |State: INITIALIZING
0000-00-00 00:00:27 E |DSL                  |HYBRID 2
0000-00-00 00:00:27 E |DSL                  |Link up 1 US 640 DS 6656 (FAST:G.DMT)
0000-00-00 00:43:29 E |DSL                  |State: DROP
0000-00-00 00:43:29 E |DSL                  |DataPump Version – 01.01.10.00
0000-00-00 00:43:29 E |DSL                  |Link Down
0000-00-00 00:43:29 E |DSL                  |State: WAITING
0000-00-00 00:43:37 E |DSL                  |State: INITIALIZING
0000-00-00 00:43:48 E |DSL                  |State: WAITING
0000-00-00 00:44:00 E |DSL                  |State: INITIALIZING
0000-00-00 00:44:07 E |DSL                  |HYBRID 2
0000-00-00 00:44:07 E |DSL                  |Link up 2 US 640 DS 6656 (FAST:G.DMT)
0000-00-00 44:32:20 E |Administration       |User ‚admin‘ authenticated
0000-00-00 93:46:53 E |DSL                  |State: DROP
0000-00-00 93:46:53 E |DSL                  |DataPump Version – 01.01.10.00
0000-00-00 93:46:54 E |DSL                  |Link Down
0000-00-00 93:46:54 E |DSL                  |State: WAITING
0000-00-00 93:47:02 E |DSL                  |State: INITIALIZING
0000-00-00 93:47:13 E |DSL                  |State: WAITING
0000-00-00 93:47:16 E |DSL                  |State: INITIALIZING
0000-00-00 93:47:24 E |DSL                  |HYBRID 2
0000-00-00 93:47:24 E |DSL                  |Link up 3 US 640 DS 6656 (FAST:G.DMT)
0000-00-00 94:03:15 E |Administration       |User ‚admin‘ authenticated
0000-00-00 94:04:26 E |DSL                  |Link Down
0000-00-00 94:04:26 E |DSL                  |State: WAITING
0000-00-00 94:05:48 E |DSL                  |State: INITIALIZING
0000-00-00 94:05:59 E |DSL                  |State: WAITING
0000-00-00 94:06:07 E |DSL                  |State: INITIALIZING
0000-00-00 94:06:14 E |DSL                  |HYBRID 2
0000-00-00 94:06:14 E |DSL                  |Link up 4 US 640 DS 6656 (FAST:G.DMT)
0000-00-00 94:15:26 E |DSL                  |Link Down
0000-00-00 94:15:26 E |DSL                  |State: WAITING
0000-00-00 94:15:52 E |DSL                  |State: INITIALIZING
0000-00-00 94:15:59 E |DSL                  |HYBRID 2
0000-00-00 94:15:59 E |DSL                  |Link up 5 US 640 DS 6656 (FAST:G.DMT)
Mit der Zeile
0000-00-00 93:46:53 E |DSL                  |State: DROP
fing das Elend heute an. Ich habe mal wieder das Kabel getauscht – ohne Erfolg auf eine bessere SNR. Die Verbindung kam dann aber wieder. Von alleine hat sich das System aber nicht berappelt…

Ein neuer Splitter soll es richten

Heute hätte ein T-Com Techniker vorbei kommen sollen. Er rief aber vorher an, und ich erzählte ihm von meiner Leidensgeschichte. (Bald verweise ich hier nur noch auf mein Blog …). Als ich ihm erzählte, dass ich bei mir schon alles getauscht habe bis auf den Splitter, sagte er mir, dass er mir einen neuen Splitter zuschicken wolle. Wenn ich wetten müsste, würde ich sagen, dass es daran wohl nicht liegen wird….

 

Eine weitere Runde im DSL-Modem Roulette

So, es gibt eine weitere Runde im DSL-Modem-Roulette zu berichten:
Ich habe nun ein weitere Teledat 302 und ein Teledat 430 ausprobiert. Ich schloss gestern abend das 302er an. Damit hatte ich nach 8 Minuten den ersten Verbindungsabbruch. Es gab wieder die Meldungen
2006:06:06-20:44:21 (none) pppd-pppoe[5054]: No response to 5 echo-requests
2006:06:06-20:44:21 (none) pppd-pppoe[5054]: Serial link appears to be disconnected.
2006:06:06-20:44:21 (none) pppd-pppoe[5054]: Script /etc/ppp/ip-down started (pid 5453)
2006:06:06-20:44:21 (none) pppd-pppoe[5054]: sent [LCP TermReq id=0x2 "Peer not responding"]
2006:06:06-20:44:21 (none) pppd-pppoe[5054]: Script /etc/ppp/ip-down finished (pid 5453), status = 0x0
2006:06:06-20:44:24 (none) pppd-pppoe[5054]: sent [LCP TermReq id=0x3 "Peer not responding"]
2006:06:06-20:44:27 (none) pppd-pppoe[5054]: Connection terminated.
Nun gut. Das Modem nochmal resetet und dann stand die Leitung – für 93 Minuten. Die sofortige Wiedereinwahl scheiterte mit den Meldungen
2006:06:06-22:19:50 (none) pppd-pppoe[7240]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x869bffed> <pcomp> <accomp>]
Danach ging die Wiedereinwahl. Gegen 23:00 Uhr habe ich dann das 430er angeschlossen und über Nacht laufen lassen. Dieses Modem lief problemlos.
Heute morgen stellte ich dann wieder auf mein eigenes Teledat 302 um, da es mir doch gestern zu denken gab, dass das zweite 302er nicht gescheit lief. Und was brachte das?

Ich erhielt plötzlich keine Einwahl. Im pppoe.log meiner Astaro sah man, wie es mehrere Login-Versuche bei meinem Provider gab. Alle waren erfolglos.
Also habe ich die Astaro durchgestartet, da das schon öfters das Problem behoben hat und bin ins Büro. Die Einwahl klappte.
Um 13:43 Uhr ging die Verbindugn wieder down (die übliche No response to 5 echo-requests Meldung)..
Die folgenden Einwahlversuche scheiterten mit den Meldungen
2006:06:07-13:47:53 (none) pppd-pppoe[6306]: pppd 2.4.2 started by root, uid 0
2006:06:07-13:47:53 (none) pppd-pppoe[6306]: using channel 3
2006:06:07-13:47:53 (none) pppd-pppoe[6306]: Using interface ppp0
2006:06:07-13:47:53 (none) pppd-pppoe[6306]: Connect: ppp0 <–> /dev/ttyp0
2006:06:07-13:47:53 (none) pppoe[6307]: PADS: Service-Name: “
2006:06:07-13:47:53 (none) pppoe[6307]: PPP session is 1515
2006:06:07-13:47:54 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:47:57 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:00 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:03 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:06 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:09 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:12 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:15 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:18 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:22 (none) pppd-pppoe[6306]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x73cd13aa> <pcomp> <accomp>]
2006:06:07-13:48:25 (none) pppd-pppoe[6306]: LCP: timeout sending Config-Requests
So war der Stand heute abend, als das große Tauschen wieder losging.

  • Zunächst tauschte mal das LAN Kabel von Astaro zu Modem. — ohne Erfolg
  • Dann tauschte ich das recht lange Kabel von Modem zu Splitter — Die Einwahl ging und dann mal wieder nicht.
  • Das andere 302er brachte überhaupt nichts.
  • Nun hatte ich langsam meine Astaro im Verdacht. Vielleicht ist es dort die Netzwerkkarte. Also habe ich die Einwahl über meinen NETGEAR WGT624 versucht. Sie klappte problemlos über mein 302er.
  • Daraufhin habe ich das lange Kabel von Splitter zu Modem zurückgetauscht. – Die Verbindung stand.
  • Das Modem wieder an die Astaro – Verbindung steht.

Mit fielen dann auf einmal Paketverluste auf. Ich pingte daraufhin den ersten hop an, der sich beim traceroute zeigte. In der Tat gab’s dort erheblich Paketverluste um die 5-10%.
Ich schoss den pppoe-Prozess ab, um zu sehen, ob die Wiedereinwahl klappt und siehe da, es ging zunächst nicht. Fehlermeldungen:
2006:06:07-19:43:17 (none) pppd-pppoe[5787]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0x54e6ae77> <pcomp> <accomp>]

Jetzt läuft neben meinem cacti auch noch ein Smokeping auf die ersten hops in diverse Richtungen, um zu sehen, ob sich die Verbindungsabbrüche irgendwie durch schlechte Ping-Zeiten oder Paketverluste ankündigen.
Evtl. liegt’s ja auch am Fastpath, das ich nutze. Auf der anderen Seite sage ich mir, dass die Telekom die Leitung durchgemessen hat und gesagt hat, dass das okay ist. Zum anderen zahle ich dafür!

„Kampf um Enigma“ von Stephen Harper

Ich habe die Tage das Buch Kampf um Enigma mit dem Untertitel Die Jagd auf U-559 von Stephen Harper gelesen. Ich hatte mir diese Buch vor einigen Monaten bei Amazon bestellt, weil es dort im Zusammenhang mit diversen Kryptografie-Büchern genannt wurde. Allerdings muss ich sagen dass ich doch eher enttäuscht von dem Buch wurde.
Es handelt eigentlich von der HMS Petard, einem Zerstörer der Royal Navy, die im Mittelmeer das deutsche U-Boot U-559 versenkt hat und kurz vor deren Untergang die Unterlagen zur Codierung von Wettermeldungen erbeutete. Damit konnte dann in Bletchley Park der Enigma Code der deutschen U-Boot Flotte geknackt werden.
Die Details bleiben aber unerwähnt. Vielmehr geht es darum, zu beschreiben, an welchen Geleitzügen und sonstigen Unternehmungen das Schiff teilgenommen, zur Hälfte des Buches auch im Kampf in Fernost.
Wer sich für die Kryptanalyse interessiert, sollte dieses Buch liegen lassen.