Unterschied zwischen Dowload im Browser und Speedtest.
Hallo zusammen,
ich habe seit etwa Dienstag/Mittwoch diese Woche mehr oder weniger Probleme mit meiner Internetverbindung. Zuerst mal folgende Ausgaben:
sven@BB1804:~$ speedtest-cli Retrieving speedtest.net configuration... Testing from Vodafone Kabel Deutschland (31.17.249.250)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Marco Bungalski GmbH (Verden) [31.60 km]: 38.29 ms Testing download speed................................................................................ Download: 175.60 Mbit/s Testing upload speed...................................................................................................... Upload: 11.74 Mbit/s sven@BB1804:~$ sven@BB1804:~$ ping -c3 www.ubuntuusers.de PING ubuntuusers.de (213.95.41.4) 56(84) bytes of data. 64 bytes from ha.ubuntu-eu.org (213.95.41.4): icmp_seq=1 ttl=53 time=39.0 ms 64 bytes from ha.ubuntu-eu.org (213.95.41.4): icmp_seq=2 ttl=53 time=37.2 ms 64 bytes from ha.ubuntu-eu.org (213.95.41.4): icmp_seq=3 ttl=53 time=39.7 ms --- ubuntuusers.de ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 37.265/38.688/39.777/1.052 ms sven@BB1804:~$
Das sieht ja alles erstmal normal aus bei einer 200 Mbit Leitung, wenn ich aber einen Download im Browser Starte kommen folgende werte zustande, siehe Bilder. Der Download von Paketen per apt-get im Terminal ist ebenfalls Schneckenlahm sozusagen.
Was aber noch kurioser ist das selbst ein anderer DNS Server die gleichen Ergebnisse Produziert. Und es spielt keine Rolle ob Google 8.8.8.8 oder Cloudfare 1.1.1.1, es findet keine Verbesserung im Browser statt.
Den DNS Server ändere ich über die /etc/resolv.conf und sieht dann so aus.
# This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "systemd-resolve --status" to see details about the uplink DNS servers # currently in use. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. # nameserver 127.0.0.53 # search hitronhub.home nameserver 1.1.1.1
Ich habe schon mehrfach den Router Neu gstartet, sowohl vom Strom gezogen als auch über die Web Gui, keine Verbesserung. Ich habe Heute zwischen 13:30 Uhr bis 16:30 3 x mit der Vodafone Störungshotline Telefoniert allerdings ist man dort auf meine Fragen nicht wirklich eingegangen.
Ich sollte immer nur einen Speedtest machen, aber die Sache mit dem langsamen DL im Browser hat die nicht die Bohne Interessiert. Auch auf meinen Wechsel zu einem anderen DNS hatten sie auch keine plausible Erklärung.
Das Ende vom Lied war ich soll jetzt bis Fretag den 12.10.2018 warten und beobachten, und wenn sich bis dahin keine Besserung zeigt dann würden Sie mir einen neuen Router Schicken. Ich will der ganzen Sache auf den Grund gehen, es kann nicht sein das zwischen Speedtest und DL im Browser solche Unterschiede liegen.
Das hatte ich in den letzten 3 Jahren noch Nie mit Vodafone, naja irgendwann ist immer das erste mal. Ich Suche also nun hier jemanden der ein wenig Mehr Ahnung von der Materie hat und Tacheless mit mir spricht, das würde ich mich Freuen. Hier noch die weiteren Ausgaben.
sven@BB1804:~$ cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback sven@BB1804:~$ sven@BB1804:~$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 1c:1b:0d:94:dc:9f brd ff:ff:ff:ff:ff:ff sven@BB1804:~$ sven@BB1804:~$ ip -4 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 192.168.0.10/24 brd 192.168.0.255 scope global dynamic noprefixroute enp6s0 valid_lft 601364sec preferred_lft 601364sec sven@BB1804:~$ sven@BB1804:~$ ip -4 route default via 192.168.0.1 dev enp6s0 proto dhcp metric 100 169.254.0.0/16 dev enp6s0 scope link metric 1000 192.168.0.0/24 dev enp6s0 proto kernel scope link src 192.168.0.10 metric 100 sven@BB1804:~$ sven@BB1804:~$ ip -4 neigh 192.168.0.1 dev enp6s0 lladdr bc:14:01:14:cd:c2 STALE sven@BB1804:~$ sven@BB1804:~$ nmcli general ; nmcli device ; nmcli connection STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN verbunden vollständig aktiviert aktiviert aktiviert aktiviert DEVICE TYPE STATE CONNECTION enp6s0 ethernet verbunden Kabelgebundene Verbindung 1 lo loopback nicht verwaltet -- NAME UUID TYPE DEVICE Kabelgebundene Verbindung 1 52b9af2f-44f1-3584-8b0b-a2bc75743486 ethernet enp6s0 sven@BB1804:~$
Zumindest hoffe ich das man das ganze hier ein wenig mehr Diagnostizieren kann.