DSL für Dresden
http://www.dslfuerdresden.de/phpbb/

Guru talk ;-) und Netzwerk - Interna
http://www.dslfuerdresden.de/phpbb/viewtopic.php?f=14&t=537
Seite 2 von 5

Autor:  hasienda [ 27.10.2007, 23:26 ]
Betreff des Beitrags:  Netzwetterbalon - der Blick von oben

attrib hat geschrieben:
ich habe mir überlegt, das was hasienda macht, umgedreht zu machen.
daher auf meinen server nen script zu machen, was mein router anpingt. [...]

Scheinbar trivial, aber unumgänglich: Der Server muß die IP des Routers kennen. D.h. bei jedem Verbindungsaufbau muß der Router die dann aktuelle IP zum Server senden. Um das gut zu machen, sollte die Information eine einzigartige Signatur tragen, die den Router als Absender identifiziert. GnuPG wäre bei Verfügbarkeit meine 1. Wahl zur Erstellung der Signatur, aber es geht auch viel einfacher mit einer langen Zufalls-Zeichenkette, die nur Router und Server kennen.

Spannend ist die Art der Datenübertragung, je nach verfügbaren Diensten auf Server und Router. Webserver: Zuerst kommt mir die HTTP-POST-Methode in den Sinn, wie z.B. hier >>http://www.php-faq.de/q/q-code-post.html<<, Webserver mit Perl: Etwas wie hier >>http://aktuell.de.selfhtml.org/artikel/cgiperl/file-upload/<< sollte gehen.

Autor:  attrib [ 28.10.2007, 02:34 ]
Betreff des Beitrags: 

Ich habe es jetzt anders gemacht, gefällt mir aber noch nicht 100%ig, aber war erstmal am einfachsten :P

Ich habe mich bei einem dyndns provider angemeldet. Aller 5min führt der cron jetzt ein php Script aus. Das Script versucht ne Verbindung mit meiner dyndns adresse aufzubauen, wenn das klappt alles in ordnung. Falls nicht merkt der sich die Zeit. Wenn dann die Verbindung wieder geht, schreibt der das ins Ausfalllog (zurzeit als Comment: "AutoPing Test - Bitte bestätigen.").

Eigentlich gefällt mir dabei nicht, das der cron nen php script ausführt. ich weiss net so genau ob das so perfekt ist.

Mit meiner jetztigen Methode könnt ich ohne Probleme noch paar Adressen einfügen, die er auch anpingt. Hat die normale Routersoftware die dyndns Funktion? Das mit der IP Aktualiserung übernimmt für mich der Router komplett, daher habe ich mir noch keine weiteren Gedanken gemacht, wie man das anders und vllt komplett über meinen Server machen könnte?

Autor:  Gizmo [ 29.10.2007, 18:10 ]
Betreff des Beitrags: 

Die Original WRT54GL-Firmware hat auch einen DynDNS-Client Funktion (unterstützt DynDNS.org und TZO.com). Also wenn du 'meinen' Router noch als weitere Adresse zum anpingen gebrauchen kannst, sag Bescheid.

Bild

Autor:  attrib [ 29.10.2007, 19:54 ]
Betreff des Beitrags: 

ja gut, im prinzip würd ich das machen, wäre kein problem.

aber ich habe erstmal nen problem:
Code:
traceroute auf mich von meinem Server aus:
[...]
 4  core-decix-peer.access.mainz-kom.net (80.81.192.126)  4 ms  4 ms  4 ms
 5  dbd-fra-bbrt02.dbd-breitband.de (89.199.253.10)  4 ms  5 ms  4 ms
 6  dbd-fra-acs02.dbd-breitband.de (89.199.253.22)  5 ms  5 ms  5 ms
 7  dbd-fra-acs01.dbd-breitband.de (89.199.253.18)  5 ms  5 ms  5 ms
 8  dbd-berlin-lex02.dbd-breitband.de (89.199.253.46)  29 ms  28 ms  28 ms
 9  dbd-fra-acs01.dbd-breitband.de (89.199.253.18)  29 ms  30 ms  28 ms
10  dbd-berlin-lex02.dbd-breitband.de (89.199.253.46)  53 ms  52 ms  54 ms
11  * dbd-fra-acs01.dbd-breitband.de (89.199.253.18)  55 ms  55 ms
12  dbd-berlin-lex02.dbd-breitband.de (89.199.253.46)  81 ms *  81 ms
[...]


Seit gestern abend geht der Test nicht mehr, weil die Ping nicht erfolgreich ist. Das liegt aber nicht an mir, sonder weil der einfach hin und her springt im dbd netzwerk... (sind wir wieder da, wo alles anfing :P)
Kommt anscheined drauf an, von wo man kommt. Aus der Uni ging es heute, vom meinem Server ging es ja auch mal. Jetzt bin ich überfragt, wie man das weitermachen kann.

Ich wollte damit ja nur ne Methode schaffen, wie man teste ob eine Verbindung besteht und das man seinen Rechner nicht anhaben muss, sondern nur seinen Router...

Autor:  attrib [ 30.10.2007, 13:53 ]
Betreff des Beitrags: 

Heute gehts wieder... sehr merkwuerdig...

Also 2-3 Leute würd ich gern erstmal zum testen noch mit aufnehmen :)
Erstmal schauen wie genau das klappt, nicht das ich ständig am Löschen der Autoping sachen bin, im Ausfalllog...

Wer will, PM an mich, mit Host (irgendnen dyndns), Port, nick und Strasse (was dann beim Ausfalllog dastehen soll)

Zum Port, am besten wäre ein Routerport, der nicht weitergeleitet wird und wo keine Dienste drauf laufen.
telnet/putty auf router
dort dann folgendes eingeben: {PORT} durch Port ersetzen
Code:
/usr/sbin/iptables -I INPUT -p tcp --dport {PORT} -j ACCEPT

Autor:  bigalex [ 30.10.2007, 20:20 ]
Betreff des Beitrags: 

Kleine Frage zum Versuchsaufbau: Wie willst Du bei DynDNS sichergehen, dass der angepingte auch tatsächlich der ist den Du erreichen willst? DynDNS selbst prüft nicht ob Du noch da bist und ändert den Eintrag erst bei der nächsten Anmeldung. Szenario:
Nutzer Joe Sixpack hat bei DynDNS den Alias joesixpack.dyndns.org, bekommt von der DBD die IP x.y.z.123 zugewiesen, Router meldet sich sich bei DynDNS an.
Soweit kein Problem, dann fliegt aber Joe aus der Leitung und bekommt keine Verbindung mehr. Dafür bekommt jemand anders die IP zugewiesen die Joe vorher hatte. Wenn es dumm kommt liefert dir ping joesixpack.dyndns.org eine stehende Verbindung obwohl die Leitung zu Joe schon tot ist.
... just my 0,02€

Autor:  attrib [ 30.10.2007, 20:29 ]
Betreff des Beitrags: 

aber dann hiesse es das dbd irgendwo noch geht, weil die ip die er dann hatte gehoert zu dbd (die haben festen ip pool und jeder bekommt per zufall eine, soweit ich das gesehen habe)

aber das aendert nix am problem.
also muesste ich nen auth paket mit schicken und fuer den router nen programm schreiben, welches dann auf den port dieses paket annimmt und bestätigt. möglich wäre das. das c programm dazu sollte nicht so gross sein und damit auf den router passen, da der linux hat, sollte man das auch dort zum laufen bekommen. es ist aber viel arbeit und fuer mich mit wenig c und wenig linux kenntnissen erstmal schwierig zu realiseren.

bessere ideen wie man das testen könnte?

Autor:  bigalex [ 30.10.2007, 21:01 ]
Betreff des Beitrags: 

Eine einfache und 100%ig sichere Lösung ohne irgendwelchen clientseitigen Installationsaufwand bzw. zusätzliche Hard- oder Software fällt mir spontan nicht ein. Ich denke mal als quick-and-dirty-Lösung geht das schon. Wenn man annimmt dass fast alle Router so eingestellt sind dass sie von außen kommende Pakete verwerfen und man den Router nur auf Pings an wirklich selten genutzten und ungewöhlichen Ports antworten lässt und die auch noch bei den Testteilnehmern eindeutig belegt sind sollte Dein Ansatz schon funktionieren.
Im Endeffekt bekommt man schlimmstenfalls ein falsch positives Ergebnis. Falsche Negativ-Ergebnisse sollten durch Wiederholung des Tests im Fehlerfall minimiert werden. Ausfälle wenn möglich zeitlich gruppieren (im Fall instabiler Verbindungen). Wechselnde IPs zumindest festhalten (seltene Wechsel sind o.k., häufige Wechsel deuten auf Probleme durch ständige Reconnects hin)
Ich würde mich als Teilnehmer schonmal anmelden, will aber abwarten bis die DBD das Problem mit den ständigen CPE-Restarts gelöst hat. Der Support hat sich bei mir gemeldet und das Problem bestätigt, es ist aber noch unklar ob es an der CPE-Firmware liegt.

Autor:  hasienda [ 06.11.2007, 01:16 ]
Betreff des Beitrags:  PC-Fingerprint

bigalex hat geschrieben:
Eine einfache und 100%ig sichere Lösung ohne irgendwelchen clientseitigen Installationsaufwand bzw. zusätzliche Hard- oder Software fällt mir spontan nicht ein. [...]

Hmm. Hier ist ein PC-Fingerprinting erforderlich. Innerhalb direkt verbundener Systeme sollte das über die MAC-Adresse möglich sein. Die ist mit sehr hoher Wahrscheinlichkeit nicht gleich, wenn die IP zwischenzeitlich an den Router eines anderen Kunden vergeben wurde. So sollten "false-positive" Ergebnisse auszuschließen sein. Nur leider funktioniert das nicht über einen oder mehrere Router hinweg, also Subnetz-übergreifend.

Autor:  hasienda [ 13.11.2007, 01:44 ]
Betreff des Beitrags:  CPE-Instabilität

Was ist das für eine Art Fehlfunktion, die zu derartiger Verbindungsinstabilität führen kann (durch Geräteneustart behoben >>http://www.dslfuerdresden.de/phpbb/viewtopic.php?p=6960#6960<<):

    Zusammenfassung:
      1. Versuch
      Code:
      --- heise.de ping statistics ---
      100 packets transmitted, 45 received, 55% packet loss, time 99029ms
      rtt min/avg/max/mdev = 64.582/199.788/635.887/118.342 ms
      1. Wiederholung (vor CPE-Neustart)
      Code:
      100 packets transmitted, 38 received, 62% packet loss, time 99011ms
      rtt min/avg/max/mdev = 61.194/177.404/988.404/151.587 ms
      2. Wiederholung (nach CPE-Neustart)
      Code:
      100 packets transmitted, 97 received, 3% packet loss, time 99017ms
      rtt min/avg/max/mdev = 68.489/152.441/1140.208/125.668 ms, pipe 2

Details (Konsolen-Log):
Code:
user@local_workstation.lan:/$ ping -c 100 heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=247 time=81.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=6 ttl=247 time=79.2 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=7 ttl=247 time=349 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=11 ttl=247 time=208 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=12 ttl=247 time=190 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=17 ttl=247 time=159 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=18 ttl=247 time=118 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=19 ttl=247 time=335 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=20 ttl=247 time=463 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=21 ttl=247 time=273 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=23 ttl=247 time=241 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=24 ttl=247 time=378 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=25 ttl=247 time=147 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=26 ttl=247 time=238 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=29 ttl=247 time=98.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=31 ttl=247 time=260 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=32 ttl=247 time=137 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=33 ttl=247 time=110 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=34 ttl=247 time=117 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=35 ttl=247 time=77.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=36 ttl=247 time=117 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=37 ttl=247 time=136 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=43 ttl=247 time=129 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=44 ttl=247 time=635 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=45 ttl=247 time=214 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=46 ttl=247 time=296 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=47 ttl=247 time=385 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=54 ttl=247 time=136 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=64 ttl=247 time=127 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=68 ttl=247 time=198 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=69 ttl=247 time=123 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=71 ttl=247 time=103 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=77 ttl=247 time=102 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=78 ttl=247 time=64.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=82 ttl=247 time=98.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=83 ttl=247 time=174 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=85 ttl=247 time=175 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=87 ttl=247 time=132 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=88 ttl=247 time=255 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=90 ttl=247 time=443 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=96 ttl=247 time=226 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=97 ttl=247 time=144 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=98 ttl=247 time=114 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=99 ttl=247 time=169 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=100 ttl=247 time=214 ms
--- heise.de ping statistics ---
100 packets transmitted, 45 received, 55% packet loss, time 99029ms
rtt min/avg/max/mdev = 64.582/199.788/635.887/118.342 ms

user@local_workstation.lan:/$ ping -c 100 heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=247 time=988 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=247 time=377 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=5 ttl=247 time=269 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=7 ttl=247 time=176 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=8 ttl=247 time=178 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=9 ttl=247 time=206 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=10 ttl=247 time=106 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=19 ttl=247 time=139 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=29 ttl=247 time=145 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=35 ttl=247 time=121 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=36 ttl=247 time=171 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=37 ttl=247 time=72.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=38 ttl=247 time=94.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=44 ttl=247 time=61.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=45 ttl=247 time=192 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=46 ttl=247 time=172 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=55 ttl=247 time=172 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=56 ttl=247 time=283 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=57 ttl=247 time=152 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=58 ttl=247 time=175 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=59 ttl=247 time=273 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=60 ttl=247 time=133 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=61 ttl=247 time=137 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=62 ttl=247 time=81.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=77 ttl=247 time=176 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=78 ttl=247 time=114 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=79 ttl=247 time=101 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=80 ttl=247 time=80.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=83 ttl=247 time=145 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=84 ttl=247 time=131 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=86 ttl=247 time=155 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=87 ttl=247 time=349 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=89 ttl=247 time=132 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=91 ttl=247 time=95.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=92 ttl=247 time=81.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=93 ttl=247 time=114 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=95 ttl=247 time=100 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=97 ttl=247 time=79.2 ms
--- heise.de ping statistics ---
100 packets transmitted, 38 received, 62% packet loss, time 99011ms
rtt min/avg/max/mdev = 61.194/177.404/988.404/151.587 ms

user@local_workstation.lan:/$ ping -c 100 heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=246 time=182 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=246 time=110 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3 ttl=246 time=184 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=246 time=114 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=5 ttl=246 time=151 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=6 ttl=246 time=80.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=7 ttl=246 time=169 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=8 ttl=246 time=141 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=9 ttl=246 time=134 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=10 ttl=246 time=84.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=11 ttl=246 time=81.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=12 ttl=246 time=182 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=13 ttl=246 time=79.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=14 ttl=246 time=69.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=15 ttl=246 time=182 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=16 ttl=246 time=119 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=17 ttl=246 time=70.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=19 ttl=246 time=150 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=20 ttl=246 time=80.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=21 ttl=246 time=181 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=22 ttl=246 time=171 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=23 ttl=246 time=89.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=24 ttl=246 time=99.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=25 ttl=246 time=122 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=26 ttl=246 time=82.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=27 ttl=246 time=91.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=28 ttl=246 time=183 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=29 ttl=246 time=179 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=30 ttl=246 time=79.6 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=31 ttl=246 time=109 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=32 ttl=246 time=101 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=33 ttl=246 time=82.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=34 ttl=246 time=109 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=35 ttl=246 time=91.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=36 ttl=246 time=72.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=37 ttl=246 time=138 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=38 ttl=246 time=183 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=39 ttl=246 time=122 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=40 ttl=246 time=185 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=41 ttl=246 time=149 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=42 ttl=246 time=125 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=43 ttl=246 time=484 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=44 ttl=246 time=181 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=45 ttl=246 time=181 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=46 ttl=246 time=110 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=47 ttl=246 time=149 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=48 ttl=246 time=119 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=49 ttl=246 time=180 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=51 ttl=246 time=231 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=52 ttl=246 time=171 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=53 ttl=246 time=128 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=55 ttl=246 time=121 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=56 ttl=246 time=100 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=57 ttl=246 time=178 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=58 ttl=246 time=92.9 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=59 ttl=246 time=129 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=60 ttl=246 time=177 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=61 ttl=246 time=82.2 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=62 ttl=246 time=120 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=63 ttl=246 time=178 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=64 ttl=246 time=88.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=65 ttl=246 time=78.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=66 ttl=246 time=178 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=67 ttl=246 time=68.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=68 ttl=246 time=90.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=69 ttl=246 time=178 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=70 ttl=246 time=129 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=71 ttl=246 time=88.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=72 ttl=246 time=88.6 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=73 ttl=246 time=178 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=74 ttl=246 time=177 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=75 ttl=246 time=78.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=76 ttl=246 time=107 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=77 ttl=246 time=157 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=78 ttl=246 time=179 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=79 ttl=246 time=178 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=80 ttl=246 time=177 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=81 ttl=246 time=102 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=82 ttl=246 time=179 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=83 ttl=246 time=176 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=84 ttl=246 time=76.9 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=85 ttl=246 time=157 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=86 ttl=246 time=127 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=87 ttl=246 time=179 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=88 ttl=246 time=126 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=89 ttl=246 time=81.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=90 ttl=246 time=176 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=91 ttl=246 time=148 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=92 ttl=246 time=214 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=93 ttl=246 time=1140 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=94 ttl=246 time=649 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=95 ttl=246 time=166 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=96 ttl=246 time=90.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=97 ttl=246 time=76.6 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=98 ttl=246 time=116 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=99 ttl=246 time=164 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=100 ttl=246 time=164 ms
--- heise.de ping statistics ---
100 packets transmitted, 97 received, 3% packet loss, time 99017ms
rtt min/avg/max/mdev = 68.489/152.441/1140.208/125.668 ms, pipe 2

Autor:  hasienda [ 18.11.2007, 01:39 ]
Betreff des Beitrags:  empfohlene Lektüre

Als Referenz weise ich hier auf den folgenden Beitrag im WiMAXtalk hin:
http://www.wimaxtalk.de/wimaxforum/fh-lippe-und-hoexter-abschlussbericht-wimax-auf-dem-land-t870.html#10480

Der dort verlinkte Bericht enthält eine Vielzahl Informationen, die ich so gebündelt, wenn überhaupt, vorher noch nicht gesehen habe. Das Lesen war für mich sehr gewinnbringend und erhellend, auch in Bezug auf die Dresdner Situation und das bevorstehende Gespräch mit DBD. Da lassen sich gut einige Fragen daraus ableiten.

Autor:  hasienda [ 22.11.2007, 00:21 ]
Betreff des Beitrags:  Was kostet die Welt? ;-)

An anderer Stelle habe ich von der Aussage eines DBD-Technikers berichtet, eine flächige Überwachung der Netzqualität beim Kunden erfolge nicht und sei gar nicht machbar (vgl. http://www.dslfuerdresden.de/phpbb/viewtopic.php?p=7136#7136).

Nun, ich widerspreche, und möchte das auch kurz begründen.
    Mein Werkzeug der Wahl ist SmokePing, eine GNU/Linux-Server-Lösung, die aller 5 min 20 Pings an x-beliebige IP-Adressen ausstößt, die Antworten sammelt, speichert und auf Anforderung schick zusammenstellt.
    Dazu nehme ich eine recht konservative Schätzung, nach der von einer Netzwerkschnittstelle eines PCs locker 50.000 Datenpakete pro Sekunden verschickt und empfangen werden können.
    Standard-Ping-Pakete sind jeweils 56 bit groß.
    Die DBD stellt aus meiner Sicht bei PPPoP-Anmeldung immer eine IP-Adresse aus einem Klasse B Netzwerk (89.196.0.0) bereit.
    Auch bei theoretischer Vollauslastung des Netzwerks sollen alle IP-Adressen überwacht werden.
Daraus läßt sich folgendes leicht berechnen:
    Es sind maximal 65534 IP-Adressen abzufragen.
    Mit SmokePing-Standard-Test entstehen dafür durchschnittlich 4369 Pakete/s, bzw. 2,8 Mb/s reiner Datenstrom jeweils in Sende- und Empfangsrichtung.
    Die Netzwerkschnittstelle wäre damit nur zu 8,74 % ausgelastet.

Obwohl ich jetzt die CPU-Zeit und Festplattenzugriffe nicht betrachte, scheint mir allein aus diesen Zahlen zu sprechen, daß selbst mit einem alten Pentium-PC locker alle maximal möglichen Verbindungen im 5 Minuten-Takt abgefragt werden könnten. Es sollte nicht mal ein Problem darstellen, eine aktuelle Liste der aktiven Verbindungen zu pflegen und entsprechend Falschmeldungen über Verbindungsverluste nach ordentlicher Abmeldung auszufiltern. Damit wären Latenz und Verbindungsverluste dann kein Mysterium, sondern weitgehend klar. qed

Autor:  hasienda [ 24.11.2007, 01:37 ]
Betreff des Beitrags:  Zwei-Klassen-Mythos

Jüngste Hinweise finden sich in zwei Beiträgen, denen ich etwas nachgegangen bin:
Killbot hat geschrieben:
Hallo,
also ich habe jetzt mehrer tage beobachtet wie meine verbindung ist in welchem gateway...

also wenn ich im gateway: 89.196.36.1 bin habe ich super werte...
zwar schaff ich ca. 200kb/s nur mit downlaod manager aber das ist mir schon lange aufgefallen.. mit mehrern threads zu einem download bekommt man alles raus ;)...

das andere gateway..179.xx andere zahln grad vergessen^^... ist grotten schlecht -.-... kommsch grad ma an 30kb/s ran :twisted:
naja musste vorhin 19 mal immer neu verbinden bis ich im anderen war hihi... aber dafür schön schnell :) [...]

Vor einigen Monaten habe ich das selbe festgestellt aber dort was es genau andersrum und das andere gateway war besser...
(siehe http://www.dslfuerdresden.de/phpbb/viewtopic.php?p=7168#7168)

Gizmo hat geschrieben:
Das gleiches ist mir heute aufgefallen - nach Verbindungsabbruch+Neuverbindung gegen 19:00 hatte ich auf einmal super Werte um die 1800 kBit/s (Standard-Gateway: 89.196.36.1). Nachdem ich nun die Antwort von Killbot hier gelesen hatte und die Verbindung zum Test trennte, landete ich wieder auf dem anderen Gateway (195.71.190.1) und die Verbindung war mit um die 500 kBit/s wesentlich langsamer. Danach habe ich die Verbindung mehrmals getrennt und wieder hergestellt bis ich mal wieder bei Standard-Gateway 89.196.36.1 landete mit entsprechender guter Geschwindigkeit.

Also zumindest im Moment ist da wohl die Last im Netz nicht gleichmäßig verteilt. Ein Geschwindigkeitsunterschied von ca. 300% zwischen den beiden Gateways ist schon signifikant.

Uhrzeit: 20:53
IP: 89.196.14.228
Standard-Gateway: 195.71.190.1
Statisches DNS 1: 89.199.255.3
WiMax Antenne: Altenberger Platz
Bild

Uhrzeit: 20:56
IP: IP-Adresse: 89.196.59.35
Standard-Gateway: 89.196.36.1
Statisches DNS 1: 89.199.255.3
WiMax Antenne: Altenberger Platz
Bild
(siehe http://www.dslfuerdresden.de/phpbb/viewtopic.php?p=7169#7169)

Code:
myhost:~$ whois 195.71.190.1
% This is the RIPE Whois query server #1.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '195.71.190.0 - 195.71.190.255'

inetnum:        195.71.190.0 - 195.71.190.255
netname:        DBD
descr:          DBD Deutsche Breitband Dienste GmbH
descr:          Vangerowstra?e 18
descr:          69115 Heidelberg
country:        DE
admin-c:        TK1940-RIPE
tech-c:         MWH6-RIPE
status:         ASSIGNED PA
mnt-by:         MDA-Z
source:         RIPE # Filtered

role:           mediaWays Hostmaster
address:        Telefonica Deutschland GmBH
address:        Huelshorstweg 30
address:        Postfach 185
address:        D-33415 Verl
phone:          +49 5246 80 1244
fax-no:         +49 5246 80 2081
e-mail:         abuse@telefonica.de
e-mail:         hostmaster@telefonica.de
e-mail:         ncc@telefonica.de
admin-c:        ABEN1-RIPE
admin-c:        PTA7-RIPE
tech-c:         ABEN1-RIPE
tech-c:         PTA7-RIPE
nic-hdl:        MWH6-RIPE
mnt-by:         MDA-Z
source:         RIPE # Filtered

person:         Thomas Kaulbach
address:        DBD Deutsche Breitband Dienste GmbH
address:        Vangerowstrasse 18
address:        69115 Heidelberg
address:        DE
phone:          +49 6221 585043-385
fax-no:         +49 6221 585043-400
e-mail:         kaulbach@dbd-breitband.de
nic-hdl:        TK1940-RIPE
mnt-by:         MDA-Z
source:         RIPE # Filtered

% Information related to '195.71.0.0/16AS6805'

route:        195.71.0.0/16
descr:        Telefonica Deutschland GmbH
origin:       AS6805
remarks:      netname: DE-MEDIAWAYS-970127
mnt-by:       MDA-Z
source:       RIPE # Filtered

myhost:~$ whois 89.196.36.1
% This is the RIPE Whois query server #2.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
%       To receive output for a database update, use the "-B" flag

% Information related to '89.196.0.0 - 89.196.63.255'

inetnum:        89.196.0.0 - 89.196.63.255
netname:        WIMAX-NETWORK-DBD
descr:          Infrastructure Berlin
country:        DE
admin-c:        DBDA-RIPE
tech-c:         DBDA-RIPE
status:         ASSIGNED PA
mnt-by:         MNT-DBD
source:         RIPE # Filtered

role:           DBD Admin
address:        DBD Deutsche Breitband Dienste GmbH
address:        Vangerowstr. 18
address:        69115 Heidelberg
address:        Germany
e-mail:         ripe-admin@dbd-breitband.de
admin-c:        TL1687-RIPE
admin-c:        RL2513-RIPE
admin-c:        MW3329-RIPE
tech-c:         TL1687-RIPE
tech-c:         RL2513-RIPE
tech-c:         MW3329-RIPE
mnt-by:         MNT-DBD
nic-hdl:        DBDA-RIPE
source:         RIPE # Filtered

% Information related to '89.196.0.0/14AS41039'

route:          89.196.0.0/14
descr:          DBD Deutsche Breitband GmbH
origin:         AS41039
mnt-by:         MNT-DBD
source:         RIPE # Filtered

Ein Berliner Knoten mit Sonderkonditionen für die Hauptstadt und alle, die mit dranhängen? Wie auch immer, jedenfalls neue Nahrung für die Theorie der "guten" und der "schlechten" Leitung.

Autor:  volleyballer [ 24.11.2007, 16:00 ]
Betreff des Beitrags: 

Oder ein Zeichen der Unfähigkeit, das eigene Netz einigermaßen zu konfigurieren/parametrisieren...

Autor:  hasienda [ 12.12.2007, 01:35 ]
Betreff des Beitrags:  und die 100.-te ;-)

Am Freitag, 07.12.2007 kam die Überwachungsbox: Äußerlich ein ganz normaler, nagelneuer Linksys-Router WRT54GL-DE. Auf der Verpackung stand lediglich ein handschriftlicher Zusatzhinweis "DBD-WRT-1023", was wohl eine interne Kennung ist.

Das Gerät soll zwischen CPE und vorhandenen Router dazwischengesteckt werden, quasi als transparente Bridge o.ä., wobei ich mir genauere Tests zur Konfiguration bisher noch gespart habe. Ich denke nicht, daß der Nutzer-Datenverkehr zwingend durchgehen muß, und so "hängt" das Gerät bei mir parallel zum Router am LAN-Kabel Richtung CPE, weil da noch ein Switch-Port frei gewesen ist - somit Installation ohne Verbindungsunterbrechung.

Rückmeldungen zu bisherigen Ergebnissen/Erkenntnissen erhielt ich bisher noch keine, trotz tägliche Anrufe beim technischen Service. Angeblich gab es heute einen Rückrufversuch 14:xx Uhr. Ich arbeite werktags immer zu der Zeit, Anrufbeantworter ist an, na ja ...

Seite 2 von 5 Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/