wheezy Verbindungen ausserhalb LAN sehr langsam

[r4pt0r]

Habe gerade ein sehr seltsames Problem mit wheezy (frisch installiertes Grundsystem) auf meinem Belinea o.book 13013:
Sämtliche Verbindungen ausserhalb des LAN sind unerträglich langsam (max 100KB/s)

wget auf eine Paketdatei am ftp und http läuft mit der selben geschwindigkeit, also nächster mirror - immer noch so langsam.
Gegenprobe am Desktop (Squeeze) auf den selben mirror: wie gewohnt ~ 2,5-3MB/s

Datei per scp vom Server bei Hosteurope holen: ~100KB/s
Per http: auch 100KB/s
Am Desktop bei beiden Varianten >2MB/s

An der Internetverbindung liegts also nicht.

IP ist zwar die selbe wie zuvor bei squeeze, aber wurde testweise auch schon geändert. Auch austauschen der IPs von Desktop und Notebook brachte keine Änderung.

/etc/network/interfaces ist bei beiden identisch (natürlich bis auf die eigene IP)
/etc/hosts und rouingtabellen sind bei beiden unverändert und bis auf eigene IP/hostnamen gleich.

wget und scp Transfer innerhalb vom LAN läuft mit voller Geschwindigkeit (~11MB/s auf 100mbit/s Karte)


Was bitte macht wheezy anderst wenn es Verbindungen nach ausserhalb aufbaut
Lässt sich IPv6 explizit unterbinden? Hatte da mit Win7 Clients schon die dämlichsten Fehler im Firmennetzwerk...

[Cae]

Lässt sich IPv6 explizit unterbinden?

Ja, geht, ist aber unwahrscheinlich, dass es daran liegt. Wenn der Verbindungsaufbau ueber IPv6 fehlgeschlagen ist (und zwar bei der DNS-Aufloesung), wird IPv4 genommen werden und das durchgaengig. Dennoch:

Code: Alles auswählen

# echo 'net.ipv6.conf.all.disable_ipv6 = 1' >/etc/sysctl.d/disable_ipv6
# sysctl -p /etc/sysctl.d/disable_ipv6

Damit waer's persistent. Temporaer kann man auch sysctl net.ipv6.conf.all.disable_ipv6 = 1 aufrufen oder den Wert in den entsprechenden Pfad unter /proc/sys/ schreiben.

Ansonsten wuerde ich auf kaputte/fehlende Firmware tippen, was aber die fehlenden Probleme im LAN nicht erklaert.

Gruss Cae

[dufty]

Mmmh, was könnte man sich anzeigen lassen?

Wie wär's zum Bleistift mit

Code: Alles auswählen

# ip addr

# ip route

# tc qdisc

# iptables -L

[r4pt0r]

Habe mal den Threadtitel angepasst - war doch etwas spät gestern


Notebook / Wheezy:

Code: Alles auswählen

# ip addr && ip route && tc qdisc && iptables -L
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:24:25:08:be:52 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.13/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::224:25ff:fe08:be52/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DORMANT qlen 1000
    link/ether 00:25:d3:23:80:94 brd ff:ff:ff:ff:ff:ff
default via 192.168.0.10 dev eth0 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.13 
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Dsektop / squeeze:

Code: Alles auswählen

# ip addr && ip route && tc qdisc && iptables -L
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:22:15:dd:d1:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.42/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::222:15ff:fedd:d192/64 scope link 
       valid_lft forever preferred_lft forever
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.42 
default via 192.168.0.10 dev eth0 
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Das einzige was mir auffällt (klar, wlan0 einträge..) ist diese Zeile:
169.254.0.0/16 dev eth0 scope link metric 1000

KA welches netz das sein soll, von mir stammt das sicher nicht !?

Traceroute auf den Mirror der Hochschule Esslingen den ich benutze ist bei beiden bis auf ein paar IPs vorm Exitnode vom KabelDeutschland-Netz identisch:

Code: Alles auswählen

[...] diverse static/dynip.superkabel.de [.....]
8  Frankfurt-DECIX-1-10GE-0-1-0-3.belwue.net (80.81.192.175)  22.356 ms  21.255 ms  25.738 ms
 9  Mannheim-Schloss-1-10GE-0-0-0-1.belwue.net (129.143.57.173)  25.963 ms Mannheim-Schloss-1-10GE-0-0-0-0.belwue.net (129.143.57.177)  22.217 ms Mannheim-Schloss-1-10GE-0-0-0-1.belwue.net (129.143.57.173)  22.148 ms
10  Karlsruhe-RZ-1-10GE-0-2-0-1.belwue.net (129.143.1.173)  25.886 ms  25.798 ms  21.950 ms
11  Stuttgart-AL30-1-10GE-0-1-0-2.belwue.net (129.143.57.45)  23.747 ms  26.175 ms  25.974 ms
12  Esslingen-HS-1-10GE-0-0-0-0.belwue.net (129.143.57.14)  26.056 ms  27.163 ms  26.540 ms
13  HS-Esslingen-peer.belwue.net (129.143.116.2)  22.925 ms  26.322 ms  27.570 ms
14  rhcs0003.hs-esslingen.de (134.108.47.2)  26.420 ms  26.714 ms  29.661 ms
15  rhlx01.hs-esslingen.de (129.143.116.10)  24.703 ms  25.930 ms  25.882 ms

Zeiten sind auch bis auf ~1-2ms gleich! Also scheint das notebook nicht sonstwohin zu routen...

Habe auch nochmal den gegentest per scp gemacht:
Selbe Datei zuerst vom Desktop aus vom Server bei HE geholt: >2MB/s
dann vom Notebook aus: ~100KB/s
dann vom Notebook aus vom Desktop holen: ~11MB/s

oder per wgat auf die selbe datei:

Code: Alles auswählen

# wget http://deb-mirror.de/debian/pool/main/v/vim/vim_7.3.547-6_amd64.deb
--2013-01-31 13:38:28--  http://deb-mirror.de/debian/pool/main/v/vim/vim_7.3.547-6_amd64.deb
Auflösen des Hostnamen »deb-mirror.de (deb-mirror.de)«... 109.230.212.54
Verbindungsaufbau zu deb-mirror.de (deb-mirror.de)|109.230.212.54|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 841324 (822K) [application/octet-stream]
In »»vim_7.3.547-6_amd64.deb«« speichern.

100%[===========================================================================>] 841.324     85,7K/s   in 8,5s    

2013-01-31 13:38:36 (97,1 KB/s) - »»vim_7.3.547-6_amd64.deb«« gespeichert [841324/841324]

und Desktop:

Code: Alles auswählen

# wget http://deb-mirror.de/debian/pool/main/v/vim/vim_7.3.547-6_amd64.deb
--2013-01-31 13:38:43--  http://deb-mirror.de/debian/pool/main/v/vim/vim_7.3.547-6_amd64.deb
Auflösen des Hostnamen deb-mirror.de... 109.230.212.54
Verbindungsaufbau zu deb-mirror.de|109.230.212.54|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 841324 (822K) [application/octet-stream]
In »vim_7.3.547-6_amd64.deb« speichern.

100%[===========================================================================>] 841.324     1,12M/s   in 0,7s    

2013-01-31 13:38:44 (1,12 MB/s) - »vim_7.3.547-6_amd64.deb« gespeichert [841324/841324]

Sobald er nach draussen Verbindet, bricht er zusammen...


Habe gerade noch per GRML live-CD gegengetestet:

Code: Alles auswählen

# wget http://deb-mirror.de/debian/pool/main/v/vim/vim_7.3.547-6_amd64.deb
--2013-01-31 13:51:10--  http://deb-mirror.de/debian/pool/main/v/vim/vim_7.3.547-6_amd64.deb
Resolving deb-mirror.de (deb-mirror.de)... 109.230.212.54
Connecting to deb-mirror.de (deb-mirror.de)|109.230.212.54|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 841324 (822K) [application/octet-stream]
Saving to: `vim_7.3.547-6_amd64.deb.1'

100%[===========================================================================>] 841,324      132K/s   in 6.3s    

2013-01-31 13:51:17 (131 KB/s) - `vim_7.3.547-6_amd64.deb.1' saved [841324/841324]

Also Probleme im Netzwerk??
Notebook und Desktop hängen beide am selben Switch, dieser ist dann an die FritzBox verbunden - Verbindung läuft für beide gleich nach aussen.
Die FritzBox hat keine besonderen Einstellungen (IP-bezogen), ausser ein paar Portweiterleitungen auf den Netzwerkserver und Port 4444 auf den Desktop.

Da ich letzte Woche noch einiges getestet habe am Notebook (noch mit squeeze), weiß ich definitiv, dass die downloads auch per apt-get da noch mit normaler Geschwindigkeit liefen. (Jetzt brauchen die Pakete für kde-plasma-netbook >1h!!) Änderungen im Netzwerk oder an der FritzBox gab es in der Zeit keine.

[dufty]

IPv6 hast jetzt doch nicht abgeschaltet.
Die Route 169.254.0.0/16 sollte nicht stören.

Könntest Du mal spassehalber Deinen Desktop vom switch abstecken und stattdessen das Kabel
des Notebooks dort anschließen und jenem auch die "Desktop-IP" verpassen und nochmals ein wget ins Internet versuchen?

[r4pt0r]

Notebook am Kabel vom Desktop einstecken + IP vom Desktop hatte ich schon ausprobiert - auch Kabel wurde schon mehrfach durchgetauscht. Da die verbindung zwischen Notebook/Desktop/Netzwerkserver aber egal in welche Richtung normal läuft, kanns daran ja nicht liegen.
Da das Notebook mit der IP vom Desktop aber noch immer so langsam von ausserhalb lädt, kanns auch nicht am Router liegen...

Hier noch die beiden Routingtabellen:

Desktop:

Code: Alles auswählen

# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
localnet        *               255.255.255.0   U     0      0        0 eth0
default         fritz.box       0.0.0.0         UG    0      0        0 eth0

Notebook:

Code: Alles auswählen

# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0

Default ist identisch, die lokalen routen sollten ja keine Rolle spielen - anscheinend wurden die von squeeze auf wheezy auch etwas verändert?

[dufty]

Die routen hast Du ja schon mittels
# ip route
angegeben. Was sagt denn
# ethtool eth0
?

Wenn Du dein wlan0 nicht benötigst, kann es mal im BIOS abschalten.
Im folgenden Beispiel "kullert" ein unbenutztes eth0 rum

Code: Alles auswählen

# ifconfig eth0
eth0      Link encap:Ethernet  Hardware Adresse aa:bb:cc:dd:ee:ff  
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:4346506902540 errors:26079041415240 dropped:8693013805080 overruns:4346506902540 frame:21732534512700
          TX packets:4346506902540 errors:17386027610160 dropped:0 overruns:4346506902540 carrier:8693013805080
          Kollisionen:21732534512700 Sendewarteschlangenlänge:1000 
          RX bytes:4346506902540 (3.9 TiB)  TX bytes:4346506902540 (3.9 TiB)
          Interrupt:46

In der Logfiles auch nichts auffälliges?

[r4pt0r]

wlan0 wird benötigt (zumindest sobald das system vollends aufgesetzt ist) - ich lasse ihn gerade im Schneckentempo die kde-pakete runterladen inkl. NetworkManager, dann werde ich mal per wlan testen obs genauso langsam läuft. Evtl biegt der Network Manager ja auch noch irgendwas wieder um damit es normal läuft...

Notebook:

Code: Alles auswählen

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Desktop:

Code: Alles auswählen

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Half 1000baseT/Full 
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000033 (51)
        Link detected: yes

Wenn da was faul wäre sollte doch aber auch bzw primär die Geschwindigkeit im LAN deutlich in die Knie gehen...

Kollissionen/errors sind bei beiden auf 0. Einziger unterschied am Notebook:
letzte Zeile: "Interrupt:43 Basisadresse:0xe000 "
Die "Basisadresse" fehlt am Desktop, sollte ja aber nur die Hardwareaddressierung betreffen, also hier irrelevant (?)


Update:
Über WLAN läufts mit normaler geschwindigkeit... Werde jetzt erstmal das system volelnds einrichten und mich später nochmal damit befassen. Da das Notebook hier zu Hause und auch in der Firma zu 90% sowieso übers WLAN läuft ist es jetzt vorerst auch nicht absolut kritisch...