# Überprüfung des Netzwerkanschlusses

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