Netzwerkprobleme

Dieser Artikel wurde als veraltet markiert, und sollte kontrolliert, und gegebenfalls korrigiert bzw. aktualisiert werden.

---

Das Internet "geht" mal wieder nicht?

Im Webbrowser wird die gewünschte Seite nicht angezeigt?
Lokale Anwendungen (thunar, mc, ...) starten langsam?

Hier sollen kurze Tests gezeigt werden womit der User feststellen kann ob und ggf. welches Netzproblem vorliegt.

Ist der lokale Rechner netzwerkfähig?

ip addr show

zeigt alle verfügbaren Netzwerkdevices und deren Zustand

ip addr show eth0

zeigt speziell den Zustand des Devices eth0. Wichtig hierbei sind:

• hat das Device eine IP-Adresse? inet 192.168.1.10
• Ist es aktiv? UP BROADCAST RUNNING MULTICAST (es reicht auch, wenn da LOWER_UP dran steht)

Wenn beides nicht stimmt, dann ist das eigene Netzdevice nicht richtig konfiguriert.
Lösungen/Ursachen

• Device richtig in /etc/rc.conf einrichten

Was auch immer funktionieren muss:

ping <eigene_IP-Adresse>
ping 127.0.0.1

• Link-Probleme bei Ethernet

Bei Ethernet muss das Device auch einen Link zum Switch/Hub aufgebaut haben.
Dazu sollte das Modul mii geladen sein. Kontrollieren kann man das mit:

lsmod | grep mii

Falls es nicht automatisch durch das Netzwerkkarten-Modul mitgeladen wurde, dann dieses Modul in die MODULES= Sektion in der /etc/rc.conf eintragen.

Überprüfen kann man den Link (als root) mit:

mii-tool

was z.B. so etwas ausgeben sollte.

eth0: negotiated 100baseTx-FD flow-control, link ok

Weiterhin kann man mit mii-tool den Link beobachten, neu aufbauen und auch bestimmte Verbindungsarten (10/100base, HD/FD) erzwingen.

man mii-tool
mii-tool -h

zeigt die Optionen.

Falls mii-tool mit einer Fehlermeldung abbricht, könnte die Netzwerkkarte auch zu neu dafür sein :) Dann kann ethtool weiterhelfen (für eth0 z.B.):

 ethtool -i eth0
 ethtool eth0

Manche Anwendungen starten langsam/gar nicht

Linux ist ein netzwerkorientiertes Betriebssystem. Viele Anwendungen oder Prozesse bedienen sich selbst auf einem Einzelplatz-Rechner ohne offensichtlichen Netzwerkanschluss der TCP/IP-Kommunikation.
Dieser "interne" Verkehr wird dann über das sog. loopback device abgewickelt. Dieses Device ist auf jedem Rechner konfiguriert.
Ob ein Problem vorliegt kann man sehr einfach testen:

 ping 127.0.0.1

muss beantwortet werden.
Auch der Befehl:

 ip addr show lo

muss das loopback Device mit der IP-Adresse 127.0.0.1 zeigen.
Gleichzeitig sollte folgendes funktionieren:

ping localhost

Hierbei muss sich das loopback Device mit Antwortpaketen melden.

Lösungen/Ursachen

• Damit der Name localhost auch aufgelöst wird, muss folgendes zum Loopback-Device in der Datei /etc/hosts stehen:

127.0.0.1               localhost.localdomain   localhost

Zur Aufgabe dieser hosts-Datei siehe auch hier

Probleme mit der Außenwelt

Lokal ist mein Rechner scheinbar netzwerkfähig, sogar das lokale Netzwerk funktioniert (sofern vorhanden). Nur nach außerhalb (Internet z.B.) funktioniert nichts!

Dafür kann es mehrere Ursachen geben. Hier die Sachen, die wir testen können/sollten:

Routing

Weiß unser Rechner wohin Pakete zu schicken sind, die nicht für diesen Rechner bestimmt sind?

route -n

sollte uns etwas in dieser Art zeigen:

[god@universe ~]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Wichtig hier ist das sog. Default Gateway. Das ist die letzte Zeile mit der Destination 0.0.0.0 und dem Flag UG.
Als Zieladresse (Gateway) muss hier die IP-Adresse unseres Gateways stehen. Das kann die Adresse eines DSL-Routers sein. Oder bei einer PPP/PPPoE-Verbindung die des Providers.

Lösungen/Ursachen

• Bei einer statischen lokalen IP wurde ein falsches Gateway eingetragen oder das Gateway nicht aktiviert. In der /etc/rc.conf die richtige Gateway-Adresse eintragen und/oder das Disable-Flag (!) bei ROUTES= für diese Route entfernen.

DNS-Probleme

Wenn im Webbrowser keine Seiten gefunden werden ("Unbekannter Rechner www.google.de" o.ä.) dann können meist die Namen der Rechner netzwerkseitig nicht zu den IP-Adressen aufgelöst werden.

Ob so ein Problem vorliegt kann man folgendermaßen testen:

[god@universe ~]$ ping www.google.de
ping: unknown host www.google.de

Wenn diese Meldung kommt, dann kann die IP dieses Rechners nicht aufgelöst werden. Dann folgendes testen:

[god@universe ~]$ ping 209.85.129.104
PING 209.85.129.104 (209.85.129.104) 56(84) bytes of data.
64 bytes from 209.85.129.104: icmp_seq=1 ttl=245 time=16.5 ms
64 bytes from 209.85.129.104: icmp_seq=2 ttl=245 time=16.2 ms
...

Wenn beim Ping auf die IP-Adresse Antwortpakete zurückkommen, dann funktioniert das Netzwerk prinzipiell, lediglich die Namensauflösung klappt nicht.

Lösungen/Ursachen

• In der Datei /etc/resolv.conf müssen gültige Nameserver eingetragen sein. Auch wenn die eigene IP-Adresse dynamisch per DHCP zugewiesen wird darf diese Datei nicht leer sein.

Provider-Probleme

Oftmals kann auch der Provider ein Problem haben. Das glaubt uns dort nur meist niemand ;-)
Hier ein paar hilfreiche Tests:

traceroute www.google.de

Das zeigt uns den "Weg" eines Paketes. Wenn wir diesen Test mit verschiedenen Zielen machen und der letzte Host der sich meldet immer der unseres Providers wäre (*.net.DTAG.DE.* z.B. bei der Telekom), dann hat der Provider evtl. ein Netzproblem.

pppoe-discovery

Bei einem DSL-Anschluss kann uns das zeigen, ob unsere DSL-Verbindung zum Provider gestört ist. Das kann ein DSL-Router/Modem-Problem sein, aber auch ein Provider-Problem.
Bei Funktionieren sollte dieser Befehl melden:

1. Access-Concentrator - der Name des AC/DSLAM
2. Got a cookie: xxx yyyy
3. AC-Ethernet-Address - die MAC-Adresse des AC/DSLAM

Dieser Test mit pppoe-discoery kann von jedem Rechner im LAN abgesetzt werden.

Pacman-Probleme

Wenn mit Pacman keine Aktualisierung möglich ist oder keine Installation von Paketen, dann kann das mit der eigenen Netzwerkumgebung (speziell Firewall-Einstellungen) zu tun haben.
Pacman verwendet intern wget zum Download der aktuellen Paketlisten und der Pakete. Und je nach Mirror unterschiedliche Protokolle (ftp, http). Bei FTP gibt es nun bei sehr restrikt oder schlecht konfigurierten Firewalls oftmals ein Problem beim normalen FTP-Datentransfer. Wo hingegen der sogenannte "passive" FTP-Transfer meist funktioniert. HTTP sollte eigentlich immer funktionieren.

Testen könnt ihr das so:

 wget ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/i686/core.db.tar.gz
 wget --passive-ftp ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/i686/core.db.tar.gz
 wget http://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/i686/core.db.tar.gz

Der erste Test ist normales FTP. Dies funktioniert wie oben angeführt oftmals nicht. Wenn aber der zweite FTP-Transfer(passiv) funktioniert, dann musst du in der pacman Konfig-Datei etwas ändern:

 # /etc/pacman.conf
 ...
 XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u

Also das Kommentarzeichen bei XFerCommand entfernen.

Falls gar kein Transfer mit FTP möglich sein sollte, dann solltest du einen HTTP-Spiegelserver nehmen. Den Hosteurope-Mirror kann man z.B. auch mit HTTP ansprechen, indem man in den Repository-Listen (core,extra) unter /etc/pacman.d das zu verwendende Protokoll von ftp:// auf http:// ändert.