[Gelöst] Geschwindigkeitsprobleme in der Domäne 06

Hallo,

bitte schreibe immer dazu, ob du über WLAN testest oder per LAN-Kabel direkt am Router hängst. 2,5 Mbit/s sind jetzt nicht so dolle, da müsste mehr gehen. Wenn aber das Freibad besucht ist und viele Geräte im Netz hängen, ist es ein sehr guter Wert. Daher kann ich das jetzt nicht einordnen.

Ich lese etwas raus, dass das Hauptproblem doch an deinem Anschluss zu sein scheint. Hast du an dem Anschluss eine globale IPV4? Das sollte bei der Telekom soweit ich weiß immer noch Standard sein. Dann mach mal bitte von einem Server aus dem Netz einen mtr darauf. Eventuell gibt es da Paketverluste.

Sollte das der Fall sein, würde ich erstmal einen anderen Router probieren.

                              My traceroute  [v0.85]

Server0 (0.0.0.0) Thu May 26 10:27:02 2016
Resolver: Received error response 2. (server failure)er of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev

  1. fritz.box 0.0% 9 40.6 26.3 0.6 47.1 12.9
    dslb-084-063-012-001.084.063.pools.vodafone-ip.de
  2. dslb-084-063-012-001.084.063.pools.vodafone-ip.de 0.0% 9 24.2 28.2 24.2 36.0 3.6
  3. 188.111.189.204 0.0% 9 45.3 30.2 24.3 45.3 6.6
  4. 188.111.190.180 25.0% 8 25.7 27.1 25.6 29.7 1.8
  5. 92.79.212.157 0.0% 8 27.2 27.8 26.0 30.2 1.4
  6. 92.79.211.210 0.0% 8 34.3 38.7 33.6 53.8 6.9
  7. 145.253.33.114 0.0% 8 40.0 37.0 31.8 53.9 7.3
  8. 209.85.249.134 0.0% 8 37.0 39.4 32.9 72.5 13.5
  9. 72.14.233.167 0.0% 8 41.0 34.7 30.9 43.8 4.9
  10. 72.14.234.216 0.0% 8 45.8 40.0 36.6 45.8 3.9
  11. 74.125.37.89 0.0% 8 49.1 47.4 40.9 64.0 7.9
  12. 108.170.232.76 0.0% 8 46.3 45.8 40.8 52.4 3.7
  13. 216.239.57.142 0.0% 8 75.2 51.5 39.1 75.2 13.2
  14. 64.233.175.143 0.0% 8 52.7 43.5 38.8 52.7 5.3
  15. fra02s27-in-f3.1e100.net 0.0% 8 39.0 39.5 38.4 40.9 0.5

Wenn in der Mitte irgendwo Pakete verloren zu gehen scheinen, macht das nichts, das ist ein Anzeigefehler, weil der betreffende Router nicht korrekt zurückmeldet, wenn er Pakete verwirft. Wichtig ist die letzte Zahl, bzw. der Sprung ab dem kontinuierlich Paketverluste auftreten. Das ist die Problemstelle.

Syntax:

mtr -i 0.1 <deine IP>

Das Paket heißt unter Debian mtr-tiny.

Liebe Grüße
Matthias

@MPW kann dass hier dass selbe Problem sein?

Das werden wir mit dem mtr-Test rausfinden.

1 „Gefällt mir“

Dieses Thema wurde automatisch 3 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.

Auf Wunsch wieder geöffnet.

Hallo zusammen,

da ich heute erst wieder im Büro bin, konnte ich erst jetzt weitere Tests durchführen.

  • Alle Angaben beziehen sich auf Geschwindigkeitstests im WLAN Bereich. Per LAN-Kabel habe ich keine Speedtests mehr durchgeführt.
  • Das Freibad hat eine 16 MBit/s Leitung und ich war zum Zeitpunkt des Tests alleine im WLAN-Netz. Mit 2,5 MBit/s wäre ich auch zufrieden gewesen. Das Problem war ja, dass ab dem dritten Test, die Geschwindigkeit auch wieder eingebrochen ist.
  • Das Rathaus hat eine 50 MBit/s Leitung mit einer Firewall dazwischen. Tests aus dem internen Netz, genauso wie Tests dirket an der Dose ohne Freifunk Router sind in Ordnung. Dort sind keine Paketverluste zu melden. Wir haben eine feste IPv4 an unserem Anschluss, da wir unseren Mailserver für die Domäne selber betreiben. Des Weitern ist ein MTR-Test von außerhalb auf die öffentliche IP auch in Ordnung.

Paktetverluste treten laut MTR-Test immer erst auf, wenn ich über den Tunnel im Freifunk-Netz bin. Deshalb war ja die Vermutung, dass vielleicht bei der Übergabe von einem Provider zum Anderen im Backbone irgendwelche Engpässe sind oder fehlerhafte Strecken. Daher würde ich gerne wissen, zu welchen IP-Adressen, bzw. Domänenhosts die Router ihre Verbindung für den Tunnel aufbauen. So könnte man ggf. sehen, ob auf den Weg dahin irgendwo Probleme auftauchen.

Ansonsten können wir meiner Meinung nach alles ausschließen, was sonst noch als Fehlerquelle in Frage käme:

  • Verkabelung defekt oder beeinflusst => dirketer Test an der Dose in Ordnung / keine Fehler auf den Port am Switch zu sehen
  • Fehlerhafte Konfiguration des VLANS => direkter Speedtest am Port in Ordnung
  • Einschränkung durch die Firewall => alle Sicherheitsprüfungen der Firewall in dem VLAN wurden abgeschaltet
  • Router, bzw. Anschluss selber => keine Probleme bei anderen Netzen, direkte Tests sind in Ordnung
  • Firmware nicht in Ordnung => Firmware aus Stadtlohn getestet, selbe Probleme wie vorher
  • Freifunkserver nicht in Ordnung => anderen Server benutzt, selbe Probleme wie vorher
  • Internetleitung => identische Probleme im Freibad, eigener Internetanschluss

Gruß,
Markus

1 „Gefällt mir“

Hi,

ich fürchte, dass wir so nicht weiterkommen. Ist es möglich, dass ich mal SSH-Zugriff auf das Gerät bekomme?

Dazu müsstest du nur meinen Schlüssel nach /etc/dropbear/authorized_keys kopieren und mir den Routernamen sagen.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDEp5dj9lvGrgCXRPMo15IemvtsD3yzqFvZJow+7/oXFFMg6Tz/mG5fpOclfxKnMu33H9CmrmFem3h89K6XhBPbXtF5wxDeWIIKQnuB0LkRi+zMHP50OzPqiRajZFRUhckVjg0KfEf0hbIaHnoXFpwkbvGDr/3RkkC4Ya1JsRq9DaNZcSQYmarGbau6O85dybTGWCw6xYE0FBVBNRBa3LD1prmtGWtUU3T0J4Vv0euW1kBzBT08yuXdLbaC4LEYV58mJwgtyA26EVjSRik+JDia3CcZSDhfAf2TtWi2XCcwChBMzlFQwiLgfI8q8d1MUKIrwk6ajdlUxU6kynaineuL mpw@Server1

Grüße
Matthias

Ist das der Schlüssel mit den Namen “authorized_keys” oder ist dies der Ordner worin der Schlüssel abgelegt werden soll? Es existiert unter dropbear nur die beiden Dateien dropbear_dss_host_key und dropbear_rsa_host_key.

Ach ja, der Routername lautet:
FF-WML-Reken-Rathaus-Test

“authorized_keys” ist eine Datei in die der Schlüssel eingetragen werden muss. Also Datei in einem Editor öffnen, den Schlüssel eintragen, Speichern und schließen. Wichtig ist das dieser Schlüssel in einer Zeile stehen muss. Sollte die Datei noch nicht existieren dann einfach neu anlegen.

Grüße Marius

Genau, und wenn die Datei nicht existiert, einfach anlegen.

So, ist jetzt eingestellt.

Gruß,
Markus

1 „Gefällt mir“

Hallo zusammen,

ich habe heute bei einer Schule auch einen Freifunk-Router zum Testen angeschlossen. Dort hatte ich dasselbe Problem wie im Rathaus. Die ersten zwei, drei Speedtests waren noch bei 1,5 MBit/s, danach waren wir nur noch bei 300 KBit/s. Weitere Tests blieben auch bei der Geschwindigkeit. Tests über einen normalen Access Point im internen Netz lagen bei 10 MBit/s. Vor Ort hängt eine FritzBox mit einer 16MBit/s Leitung von der Telekom. Also scheint es nicht nur am Rathaus zu liegen.

Gruß,
Markus

Hallo,

auf das Gerät FF-WML-Reken-Rathaus-Test mit der IPV6 2a03:2260:115:600:a62b:b0ff:feca:96b4 kann ich mich leider nicht einloggen. Das bedeutet, dass der Schlüssel nicht korrekt hinterlegt ist.

Grüße
Matthias

Bitte noch einmal versuchen. Bei ssh-rsa fehlte ein “s”.

Klappt, ich gucke mich jetzt mal ein bisschen auf dem Gerät um und werde dann berichten.

Okay, das hab ich überhaupt noch nicht gesehen. Obwohl der Knoten per Fastd mit unserem Server direkt verbunden ist, bevorzugt Batman den Weg über einen anderen Knoten hinweg.

# batctl traceroute a4:2b:b0:ca:96:b4
traceroute to a4:2b:b0:ca:96:b4 (a6:2c:b1:ca:96:b4), 50 hops max, 20 byte packets
 1: a6:2c:b1:ca:84:38  45.146 ms  45.566 ms  44.951 ms
 2: a6:2c:b1:ca:96:b4  46.055 ms  50.473 ms  47.420 ms

(die a6:2c:b1:ca:84:38 ist FF-WML-Reken-Rathaus-Sitzungszimmer)

Ich habe das WLAN-Meschnetz daraufhin zu Testzwecken abgeschaltet, um eine direkte Verbindung zu erzwingen. Die Paketverluste liegen bei 20%. Die Paketverluste zu eurer öffentlichen IPV4 sind aber 0%.

Hängt da hausintern noch ein weiterer Router dazwischen? Die Pakete müssen irgendwo zwischen dem Freifunk-Router und 192.168.11.254 auftreten (vorausgesetzt 11.254 informiert korrekt über verworfene Pakete). An der DSL-Leitung scheint es nicht zu liegen. Und an unserem Server auch nicht, da ich problemlos andere Router aus der Domäne 06 pingen kann. Zehn Pakete pro Sekunde 0 Paketverluste über Minuten hinweg.

Ich tippe auf einen kaputten Switch, Router, Port oder ein defektes Kabel innerhalb des Hauses.

Das Problem in der Schule kann damit zusammenhängen, wenn diese per Glas oder wie auch immer an der Gemeinde dran hängt? Das ist in vielen Gemeinden der Fall.

Bitte mal probieren, den Router so weit wie möglich direkt an den Hauptrouter anzuschließen. Zumindest Testweise.

Ein mtr vom Router auf 8.8.8.8 (das geht direkt über eure Leitung, nicht über unsere Server) hat mir 80% Paketverluste angezeigt.

Grüße
Matthias

Kannst du es bitte noch einmal testen? Ich habe keine Fehler mehr drauf. Ich hatte meinen Laptop direkt am Kabel vom Router angeschlossen und dort waren keine Fehler zu sehen. Danach habe ich den Router wieder angeschlossen und jetzt sind dort auch keine Fehler mehr im MTR zu erkennen.
Ich vermute, dass sich der Router nach dem Neustart nur mit Half Duplex eingestellt hat und nicht mit Full Duplex.

Von welchem System aus ist der mtr gemacht? Das ist leider abgeschnitten.

Wenn ich mich auf dem FF-Router anmelde, sind die Werte immer noch genauso schlecht, wie in dem Bildschirmfoto, was ich dir in der privaten Nachricht geschickt hatte.

Ich mache den mtr mit -i 0.1, dadurch werden nicht ein Paket sondern 10 pro Sekunde verschickt.

Solange ich nur einen mtr ohne Parameter mache, ist auch alles gut (Mitte). Bei mir Zuhause läuft es auch mit 0,1 Sekunden Abstand gut(oben). Sobald ich dann auf dem FF-Router auf 0,1 runter gehe (unten) steigen auch bei dem langsamen mtr die Paketverluste (Mitte).

Zehn Pakete pro Sekunde ist mal gar nichts. Das müsste locker gehen, ohne jegliche Verluste.

Grüße
Matthias

Bei Congestion (oder auch sonst) gibt es keine Information über dropped packets.
Die werden (entsprechend der Spec) einfach weggeworfen.

Hallo zusammen,
hier haben wir schon das Problem beim MRT mit dem Wert 0.1. Die Swichte/Firewall erkennen ein Flooding und blockieren, bzw. verwerfen die Pakete. Wenn man danach einen normalen Test macht, ist die MAC-Adresse noch immer bekannt von dem Gerät und wird blockiert. Erst nach einer gewissen Zeit, bzw. wenn man ein anderes Gerät anschließt fällt die Sperrung weg. Danach sind MRT-Tests wieder sauber durchführbar.

Siehe Screenshot:

Also können wir damit keinen wirklichen Test machen.

Die 20% Pakteverlust beim Freifunk habe ich aber auch in der normalen Ping-Geschwindigkeit.

Also wie sollen wir jetzt weiter vorgehen?

Gruß,
Markus