Um die Funktionalität des Netzwerkanschlusses zu testen, existieren
mehrere Programme.
Erster Anlaufpunkt ist die Überprüfung des lokalen TCP/IP-Systems:
user@sonne> ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.2 ms
--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
|
Das Kommando ping (Abbruch mit <CTRL-C>) schickt die Datenpakete
ans loopback-Device. Geht hier schon etwas schief, ist entweder der Kernel
nicht richtig konfiguriert oder irgendein Netzwerkdienst wurde nicht gestartet.
Als nächstes wird die Netzwerkkarte getestet:
user@sonne> ping sonne
PING sonne.galaxis.de (194.168.10.101): 56 data bytes
64 bytes from 194.168.10.101: icmp_seq=0 ttl=64 time=0.2 ms
64 bytes from 194.168.10.101: icmp_seq=1 ttl=64 time=0.1 ms
--- sonne.galaxis.de ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.2 ms
|
Ein möglicher Fehler hier wäre ein Defekt der Karte oder
der Verkabelung. Schließlich "pingt" man einen Rechner seines Netzes
an:
user@sonne> ping zeus
PING zeus.buero.saxedu.de (194.180.239.20): 56 data bytes
64 bytes from 194.180.239.20: icmp_seq=0 ttl=128 time=0.8 ms
64 bytes from 194.180.239.20: icmp_seq=1 ttl=128 time=0.5 ms
64 bytes from 194.180.239.20: icmp_seq=2 ttl=128 time=0.5 ms
--- zeus.buero.saxedu.de ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.6/0.8 ms
|
Ein anderes Kommando ist ifconfig, das, ohne
Parameter aufgerufen, die vorhandenen Netzwerkschnittstellen auflistet:
root@sonne> ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:112 errors:0 dropped:0 overruns:0 frame:0
TX packets:112 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:194.180.239.167 Bcast:194.180.239.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
eth0 Link encap:Ethernet HWaddr 00:80:C8:47:B3:47
inet addr:194.180.239.167 Bcast:194.180.239.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41405 errors:19 dropped:0 overruns:0 frame:29
TX packets:9123 errors:0 dropped:0 overruns:0 carrier:0
collisions:607
Interrupt:15 Base address:0xd000
|
Wichtigstes Device ist hier "eth0", das eigentliche Netzwerkdevice.
ifconfig
dient der Konfiguration dieser Schnittstellen, z.B. könnte man mittels
root@sonne> ifconfig eth0 down
|
dieselbe deaktivieren. Schließlich versucht man noch einen Rechner
"outside of the world" zu erreichen:
root@sonne> ping 198.41.0.4
PING 198.41.0.4 (198.41.0.4): 56 data bytes
64 bytes from 198.41.0.4: icmp_seq=0 ttl=247 time=159.3 ms
64 bytes from 198.41.0.4: icmp_seq=1 ttl=247 time=157.3 ms
64 bytes from 198.41.0.4: icmp_seq=2 ttl=247 time=189.1 ms
64 bytes from 198.41.0.4: icmp_seq=3 ttl=247 time=163.9 ms
--- 198.41.0.4 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 157.3/167.4/189.1 ms
|
Die verwendete Adresse gehört zu einem Nameserver der Toplevel-Domain.
Schlägt dieser Kontaktversuch fehl, stimmt vermutlich etwas mit dem
Routing nicht, womit wir beim Kommando route
angelangt wären. Das Kommando listet die bekannten Interfaces auf
und zeigt, wie diese erreichbar sind:
root@sonne> route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
sonne.galaxis.de * 255.255.255.255 UH 0 0 0 dummy0
194.180.239.0 * 255.255.255.0 U 0 0 31 eth0
loopback * 255.0.0.0 U 0 0 2 lo
default gw.galaxis.de 0.0.0.0 UG 0 0 5 eth0
|
Falls der letzte Eintrag fehlt, scheitert die Vermittlung an unbekannte
Adressen, da der Rechner mit einer solchen nichts anzufangen weiß.
Der
default-Eintrag bewirkt, dass Pakete mit unbekannter IP-Adresse
an diesen Rechner geleitet werden, in der Hoffnung, dass dieser die Adresse
kennt. Fehlt diese Route, fügt man sie am besten hinzu:
root@sonne> route add default gw gw.galaxis.de
|
Der Name gw.galaxis.de muss lokal auflösbar sein (am besten
durch einen Eintrag in der /etc/hosts). Danach sollten auch Rechner
außerhalb des lokalen Netzes ansprechbar sein.Falls nicht, liegt
der Fehler vermutlich außerhalb unseres Einflussbereiches. Wen es
interessiert, der kann mit dem Kommando traceroute die genaue
Wegewahl des Paketes verfolgen und eventuell das schwache Glied in der
Kette isolieren:
root@sonne> traceroute www.linux.de
traceroute to www.linux.de (195.254.37.153), 30 hops max, 40 byte packets
1 ball.saxsys.de (194.184.233.3) 1.003 ms 1.539 ms 0.884 ms
2 195.211.141.1 (195.211.141.1) 3.062 ms 3.965 ms 2.505 ms
3 frankfurt1.GIGABELL.NET (195.211.224.1) 26.195 ms 29.581 ms 16.679 ms
4 hssi4-0.frankfurt2.GIGABELL.NET (195.211.199.30) 19.642 ms 20.949 ms 19.533 ms
5 194.31.232.65 (194.31.232.65) 21.751 ms 21.525 ms 17.002 ms
6 194.97.193.6 (194.97.193.6) 19.811 ms 27.464 ms 17.253 ms
7 194.97.193.17 (194.97.193.17) 51.076 ms 37.010 ms 28.361 ms
8 194.97.216.19 (194.97.216.19) 31.216 ms 30.439 ms 31.207 ms
9 195.254.37.153 (195.254.37.153) 31.260 ms 32.833 ms 28.463 ms
|
Falls ein Paket nicht vermittelt werden kann, wird in der letzten Zeile
anstelle der Zeitinformationen ein Fehlercode (eingeleitet durch
!)
erscheinen. Z.B. besagt ein !N, dass das Netzwerk oder das Protokoll
nicht erreichbar ist. Drei Sterne in einer Zeile beschreiben den Transportversuch
über ein Gateway, von welchem keine Antwort kam. Nach drei Anläufen
wird versucht, ein Paket über ein anderes Gateway zu routen. Das Kommando
netstat
dient schließlich der Überwachung aller Netzwerkschnittstellen.
Hiermit lässt sich der Status jedes Ports abfragen, auch derer, an
denen zz. nur ein Dienst "lauscht".
Anhand von Statistiken der Schnittstellen lassen sich u.a. Schwachstellen
im Netzwerk erkennen:
root@sonne> netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
lo 3924 0 0 0 0 0 0 0 0 0 LRU
dummy 1500 0 0 0 0 0 0 0 0 0 BORU
eth0 1500 0 2527 0 0 0 2329 0 0 0 BRU
|
Der Eintrag eth0 beschreibt die Schnittstelle zum physikalischen
Netzwerk:
-
MTU gibt die maximale Größe von Paketen an, hier also
1500 Bytes.
-
Met gibt die Metrik an, die zur Kostenermittlung einer passierten
Route vorgesehen ist. In Linux wird hiervon kein Gebrauch gemacht.
-
RX-OK/TX-OK beschreibt die Anzahl empfangener/gesendeter Pakete
-
RX-ERR/TX-ERR ist der Zähler für fehlerhafte Pakete.
Ein im Verhältnis zu xx-OK sehr hoher Wert kann auf eine
Überlastung des Netzwerkes hindeuten und das damit vermehrte Auftreten
von Kollisionen.
-
RX-DRP/TX-DRP beinhaltet die Anzahl verworfener Pakete. Der Host
ist offensichtlich überlastet und kann die eintreffenden/ausgehenden
Pakete nicht schnell genug verarbeiten.
-
RX-OVR/TX-OVR zählt die Pakete, die einen Überlauf des
Puffers hervorgerufen haben. Wahrscheinlich überschreitet die Paketlänge
die mögliche MTU der Schnittstelle. Bei der Implementierung eigener
Netzwerksoftware ist zu beachten, dass die Linux-IP-Implementierung derzeit
keine Fragmentierung unterstützt.
-
FLAGS beschreibt des Status der Verbindung
| Flags |
Bedeutung |
| A |
Empfang von Multicast-Adressen |
| B |
Broadcast erlaubt |
| D |
Device wird debugged |
| L |
Loopback-Device |
| M |
Alle Pakete werden empfangen |
| N |
Pakete ohne Trailer senden |
| O |
Keine ARP |
| P |
Point-to-Point-Verbindung |
| R |
Device ist in Betrieb |
| U |
Device ist aktiv |
