Netzwerkprobleme
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?
ifconfig -a
zeigt alle verfügbaren Netzwerkdevices und deren Zustand
ifconfig eth0
zeigt speziell den Zustand des Devices eth0. Wichtig hierbei sind:
- hat das Device eine IP-Adresse? inet addr:192.168.1.10
- Ist es aktiv? UP BROADCAST RUNNING MULTICAST
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 muß:
ping <eigene_IP-Adresse> ping 127.0.0.1
- Link-Probleme bei Ethernet
Bei Ethernet muß 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/garnicht
Linux ist ein sehr 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 muss auf jedem Rechner konfiguriert sein.
Ob solch ein Problem vorliegt kann man sehr einfach testen:
ping 127.0.0.1
muss beantwortet werden. Wenn nicht, dann ist es in der /etc/rc.conf falsch/nicht konfiguriert.
Auch der Befehl:
ifconfig lo
muss das loopback Device lo UP mit der IP-Adresse 127.0.0.1 zeigen.
Gleichzeitig muß folgendes funktionieren:
ping localhost
Hierbei muß sich das lo Device mit der IP 127.0.0.1 mit Antwortpaketen melden.
Lösungen/Ursachen
- Das Device richtig in der /etc/rc.conf eintragen (Die Punkte ... sagen nur: hier kann bei dir auch noch was anderes zusätzlich stehen):
... # NETWORKING ... lo="lo 127.0.0.1" INTERFACES=(lo ...)
- Damit der Name localhost auch aufgelöst wird, muß 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) muß 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 Meldug 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:
- Access-Concentrator - der Name des AC/DSLAM
- Got a cookie: xxx yyyy
- 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,community) unter /etc/pacman.d das zu verwendende Protokoll von ftp:// auf http:// ändert.