Praktikum Kommunikationstechnik: Schwerpunktaufgabe 1

Hier ist die Lösung zu der Schwerpunktaufgabe 1 des Praktikums im Fach Kommunikationstechnik. Ich rate dringend davor ab, die Lösung einfach zu kopieren. 😉

Aufgabe 1-1:

ping -c 10 www.rfc-editor.org

PING www.rfc-editor.org (128.9.160.27) 56(84) bytes of data.
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=1 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=2 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=3 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=4 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=5 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=6 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=7 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=8 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=9 ttl=242 time=174 ms
64 bytes from www.rfc-editor.org (128.9.160.27): icmp_seq=10 ttl=242 time=174 ms
— www.rfc-editor.org ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9037ms
rtt min/avg/max/mdev = 174.532/174.630/174.730/0.271 ms

Die mittlere Antwortzeit wird bestimmt, in dem man die Zeiten aller Pakete addiert und durch die Anzahl der Pakete teilt. Dieses Ergebnis nochmals durch zwei geteilt, ergibt die mittlere Übertragungszeit, da hier für nur der Hin- oder Rückweg betrachtet werden muss.

In diesem Falle ergibt sich eine mittlere Antwortzeit von 174 ms und eine mittlere Übertragungszeit von 87 ms.

Aufgabe 1-2:

Um die Übertragungsrate mittels ping bestimmen zu können brauchen wir die Paketgröße und die durchschnittliche Übertragungszeit! Da wir die Übertragungszeit erst einmal in Bit/s ausrechnen wollen, sieht die Formel dafür folgender Maßen aus:

Bit/s = (Paketgröße *8)/durchschnittliche Übertragungszeit/1000

Paketgröße*8 wird verwendet, um von Byte nach Bit zu kommen
/1000 wird verwendet, um von Millisekunden auf Sekunden zu kommen.

Aufgabe 1-3:

ping -c 10 www.gm.fh-koeln.de
PING advm1.gm.fh-koeln.de (139.6.57.1) 56(84) bytes of data.
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=1 ttl=254 time=0.936 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=2 ttl=254 time=1.09 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=3 ttl=254 time=0.984 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=4 ttl=254 time=0.881 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=5 ttl=254 time=0.779 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=6 ttl=254 time=0.932 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=7 ttl=254 time=0.705 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=8 ttl=254 time=0.854 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=9 ttl=254 time=0.877 ms
64 bytes from advm1.gm.FH-Koeln.DE (139.6.57.1): icmp_seq=10 ttl=254 time=0.908 ms
— advm1.gm.fh-koeln.de ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 0.705/0.895/1.094/0.101 ms

ping -c 10 www.lacnic.net 
PING lacnic.net (200.3.14.10) 56(84) bytes of data.
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=1 ttl=51 time=231 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=2 ttl=51 time=231 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=3 ttl=51 time=231 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=4 ttl=51 time=231 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=5 ttl=51 time=232 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=6 ttl=51 time=232 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=7 ttl=51 time=231 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=8 ttl=51 time=232 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=9 ttl=51 time=233 ms
64 bytes from www.lacnic.net (200.3.14.10): icmp_seq=10 ttl=51 time=232 ms
— lacnic.net ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9038ms
rtt min/avg/max/mdev = 231.098/231.803/233.108/0.661 ms

ping -c 10 www.dfn.de
PING www.dfn.de (194.95.237.15) 56(84) bytes of data.
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=1 ttl=58 time=10.3 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=2 ttl=58 time=11.3 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=3 ttl=58 time=11.3 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=4 ttl=58 time=11.3 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=5 ttl=58 time=11.4 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=6 ttl=58 time=11.3 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=7 ttl=58 time=11.3 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=8 ttl=58 time=11.3 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=9 ttl=58 time=10.8 ms
64 bytes from www.dfn.de (194.95.237.15): icmp_seq=10 ttl=58 time=12.0 ms
— www.dfn.de ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9038ms
rtt min/avg/max/mdev = 10.308/11.278/12.062/0.434 ms

ping -c 10 www.omg.org
PING www.omg.org (192.67.184.5) 56(84) bytes of data.
— www.omg.org ping statistics —
10 packets transmitted, 0 received, 100% packet loss, time 9014ms

Wie schon vorab zu sehen ist, werden ICMP-Pakete von der Firewall von www.omg.org verworfen, so dass in diesem Falle keine Ermittlung der Übertragungsrate möglich ist. Für die anderen Adressen wurden folgende Übertragungsraten, nach der oben angegebenen Formel ermittelt:

AdresseBit/sKbit/s – Bit/s durch 1000Mbit/s – Kbit/s durch 1000
www.gm.fh-koeln.de1144134,081144,131,14
www.lacnic.net4417,544,460,0044
www.dfn.de90796,2490,800,09

Aufgabe 1-4:

Ping erlaubt eine maximale Paketgröße von ca. 64 Kbyte. Der Maximalwert unter Windows ist 65500 Byte und unter Linux 65527 Byte. Allerdings sollte man darauf achten, dass die Paketgröße die MTU nicht überschreitet, denn sonst wird das Paket fragmentiert, also in mehrere kleine Pakete aufgeteilt. Außerdem erreichen große Pakete den Host des Öfteren nicht, so dass man die Meldung Zeitüberschreitung der Anforderung erhält. Ein idealer Wert sind die bei Linux standardmäßigen 64 Byte oder bei Windows die 32 Byte, da damit ein quasi Standard gegeben ist und man eine gute Vergleichbarkeit hat.

Aufgabe 1-5:

/home/kt> /usr/sbin/traceroute ktdsp18.local
traceroute to ktdsp18.local (10.20.23.18), 30 hops max, 40 byte packets
1  ktdsp18.local (10.20.23.18)  3.221 ms   0.086 ms   0.091 ms

So sieht die Route von dem Rechner (ktdsp17.local) zu ktdsp18.local aus.

Aufgabe 1-6:

/home/kt> ping -c 10 -R ktdsap1.local
PING ktdsap1.local (10.50.23.1) 56(124) bytes of data.
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=1 ttl=62 time=1.89 ms
RR:     ktdsp17.local (10.20.23.17)
ktdsrt1.local (10.23.5.61)
10.50.0.1
ktdsap1.local (10.50.23.1)
ktdsap1.local (10.50.23.1)
ktdss05.local (10.23.5.5)
10.20.0.1
ktdsp17.local (10.20.23.17)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=2 ttl=62 time=1.77 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=3 ttl=62 time=1.72 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=4 ttl=62 time=1.73 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=5 ttl=62 time=1.75 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=6 ttl=62 time=1.69 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=7 ttl=62 time=1.71 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=8 ttl=62 time=1.72 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=9 ttl=62 time=1.74 ms        (same route)
64 bytes from ktdsap1.local (10.50.23.1): icmp_seq=10 ttl=62 time=1.78 ms       (same route)
— ktdsap1.local ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9038ms
rtt min/avg/max/mdev = 1.697/1.753/1.891/0.076 ms

/home/kt> nslookup
> 10.50.0.1
Server:         10.23.5.1
Address:        10.23.5.1#53
** server can’t find 1.0.50.10.in-addr.arpa.: NXDOMAIN
> 10.20.0.1
Server:         10.23.5.1
Address:        10.23.5.1#53
** server can’t find 1.0.20.10.in-addr.arpa.: NXDOMAIN
> exit

Wie man sehen kann sind bei allen IP-Adressen, bis auf zwei, die Namen aufgelöst worden. Da diese IP-Adressen auch nicht im DNS-Server eingetragen sind, konnten wir mittels nslookup die Namen über einen Reverse-Lookup nicht bestimmen.

Aufgabe 1-7:

/home/kt> /usr/sbin/traceroute ktdsap1.local
traceroute to ktdsap1.local (10.50.23.1), 30 hops max, 40 byte packets
1  10.20.0.1 (10.20.0.1)  0.690 ms   1.163 ms   1.200 ms
2  ktdss05.local (10.23.5.5)  0.422 ms   0.410 ms   0.404 ms
3  ktdsap1.local (10.50.23.1)(H!) 
0.570 ms (H!)  0.510 ms (H!)  0.506 ms

Traceroute zeigt nur den Hinweg zum Ziel an, im Gegensatz zu ping –R wo Hin- und Rückweg angezeigt werden. Dieses Ergebnis kommt durch die unterschiedliche Arbeitsweise zustande:

Ping:
Ping schickt, um die Erreichbarkeit eines Rechners zu überprüfen, einen ICMP-Echo-Request. Der Empfänger antwortet darauf mittels einem ICMP-Echo-Reply, vorausgesetzt das Protokoll wird unterstützt und die Firewall lässt ICMP-Verkehr zu. Daher erscheint größtenteils bei ping mit der Option –R auch die komplette Route, da jeder Knotenpunkt auf dem Weg zum Ziel mittels einem ICMP-Echo-Request auf Erreichbarkeit geprüft wird.

Traceroute:
Traceroute dagegen sendet mehrfach Pakete, um die Route zu ermitteln. Dabei wird die TTL bei jedem Paket um 1 erhöht, so dass jeder Knotenpunkt der das Paket erhält die TTL um 1 heruntersetzt. Sollte ein Router dabei ein Paket mit der TTL=1 erhalten und müsste es logischerweise vermitteln, dann wird das Paket verworfen und stattdessen ein ICMP-Reply „Time-to-live exceeded“ und „Time-to-live exceeded in transit“ an den Absender gesendet. Passiert dies allerdings bei unserem Zielhost so erhält man ein ICMP-Reply „Destination Unreachable“ oder alternativ einen ICMP-Echo-Reply. Dies stellt im Endeffekt unsere Route zum Ziel dar. Dabei kann der Rückweg identisch sein, muss es aber nicht, wenn asymmetrisches Routing zum Einsatz kommt. Allerdings stellt Traceroute nicht immer die vollständige Route dar, da Firewalls, NAT sowie andere Routen bei Netzwerküberlastung Einfluss darauf haben können.

Aufgabe 1-8:

Betrachtet man die Ergebnisse aus Aufgabe 1-6 und Aufgabe 1-7 liegen 2 Router auf dem Weg zwischen ktdsp17.local und ktdsap1.local!

ktdsp17.local 10.20.23.7 0
10.20.0.1 1a
ktdrt1.local 10.23.5.61 1b
ktdss05.local 10.23.5.5 2a
10.50.0.1 2b
ktdsap1.local 10.50.23.1 3a

Aufgabe 1-9:

/home/kt> /usr/sbin/traceroute www.lacnic.net
traceroute to www.lacnic.net (200.3.14.10), 30 hops max, 40 byte packets
1  139.6.65.1 (139.6.65.1)  0.435 ms   0.367 ms   0.358 ms
2  xr-bir1-ge9-21.x-win.dfn.de (188.1.232.125)  1.723 ms   1.691 ms   1.700 ms
3  zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46)  4.469 ms   4.141 ms   4.252 ms
4  64.213.78.237 (64.213.78.237)  4.105 ms   4.109 ms   4.110 ms
5  ge-1-3-0.0.gw01.registro.br (64.214.145.246)  231.019 ms   231.038 ms   231.713 ms
6  ar01.bb2.registro.br (200.160.0.244)  232.506 ms   232.935 ms   232.240 ms
7  gw01.lacnic.registro.br (200.160.0.212)  231.573 ms   231.782 ms   231.901 ms
8  www.lacnic.net (200.3.14.10)  233.220 ms   232.479 ms   232.727 ms

Sieben Knoten bzw. acht Hops liegen auf dem Weg von ktdsp17.local zu www.lacnic.net. Die Standorte der Knoten wurden mittels whois Abfragen ermittelt:

1 DE Köln/Gummersbach
2 DE Over
3 DE Over
4 US Arvada, CO
5 US nicht vorhanden
6 BR nicht vorhanden
7 BR nicht vorhanden
8 UY nicht vorhanden
US = Vereinigte Staaten von Amerika – BR = Brasilien – UY = Uruguay

Von den sieben Knoten liegen, laut Angaben der whois Abfragen, drei Knoten in Deutschland.

Aufgabe 1-10:

/home/kt> nslookup -type=SOA fh-koeln.de
Server:         10.23.5.1
Address:        10.23.5.1#53
fh-koeln.de
origin = ns-iwz.nz.fh-koeln.de
mail addr = dns.fh-koeln.de
serial = 2009102602
refresh = 10800
retry = 1800
expire = 604800
minimum = 86400
 

Der Primary Nameserver ist unter dem Punkt origin zu finden und trägt folgenden Namen:
ns-iwz.nz.fh-koeln.de
Die Seriennummer der Zone lautet 2009102602. Der TTL-Wert ist unter dem Punkt minimum zu finden und dürfte wie es standardmäßig der Fall ist in Sekunden angegeben sein: 86400. Die Mailadresse des Zonenverwalters findet man unter mail addr, nach dem DNS-Standard entsprechend, muss der erste Punkt in dns.fh-koeln.de als @ interpretiert werden, demzufolge lautet die Mailadresse dns@fh-koeln.de . Um die letzte Änderung der Zone herausfinden zu können betrachtet man die ersten 8 Stellen der Seriennummer. Diese haben folgendes Format YYYYMMDD. Daraus ergibt sich, dass die Zone das letzte Mal am 26.10.2009 geändert worden ist.

Aufgabe 1-11:

/home/kt> nslookup www.gm.fh-koeln.de
Server:         10.23.5.1
Address:        10.23.5.1#53
www.gm.fh-koeln.de      canonical name = advm1.gm.fh-koeln.de.
Name:   advm1.gm.fh-koeln.de
Address: 139.6.57.1
 

Aus dieser nslookup Abfrage kann man gut erkennen welcher Eintrag vom Typ A und welcher vom Typ CNAME (canonical name) in der Zone gm.fh-koeln.de sein muss.

www.gm.fh-koeln.de CNAME advm1.gm.fh-koeln.de
advm1.gm.fh-koeln.de A 139.6.57.1

Aufgabe 1-12:

/home/kt> nslookup -type=MX fh-koeln.de
Server:         10.23.5.1
Address:        10.23.5.1#53
fh-koeln.de     mail exchanger = 10 smtp.intranet.fh-koeln.de.
 

/home/kt> nslookup smtp.intranet.fh-koeln.de
Server:         10.23.5.1
Address:        10.23.5.1#53
Name:   smtp.intranet.fh-koeln.de
Address: 139.6.1.61
 

Laut nslookup Abfrage nach dem MX-Record, der für die Mailservereinträge im DNS verwendet wird, existiert in der Zone fh-koeln.de nur ein Server für die Mailweiterleitung. Vermutlich steckt hinter der IP-Adresse ein redundantes Cluster welches von außen nur über diese eine IP-Adresse angesprochen wird.

Aufgabe 1-13:

/home/kt> telnet www.f10.fh-koeln.de 80
Trying 139.6.138.92…
Connected to www.f10.fh-koeln.de.
Escape character is ‘^]’.
GET http://www.f10.fh-koeln.de

<html>
<head>
<meta name=”GENERATOR” content=”IMPERIA 7.5.1″ />
<meta http-equiv=”content-type” content=”text/html; charset=iso-8859-1″>
<meta name=”Content-Language” content=”de”>
<meta http-equiv=”Content-Style-Type” content=”text/css”>
<meta name=”robots” content=”index”>
<meta name=”pragma” content=”no-cache”>
<meta name=”keywords” content=”FH Koeln, Fachhochschule Koeln, Fakultaet 10, Fakult&auml;t f&uuml;r Informatik, Ingenieurwissenschaften”>
<meta name=”X-Imperia-Live-Info” content=”283e9061-5c8e-8f8e-ffb3-cd250ef7b0f4/188/17″ />
<link rel=”stylesheet” type=”text/css” href=”/styles.css”><link rel=”stylesheet” href=”/styles.css”>
<link rel=”alternate” type=”application/rss+xml” title=”Nachrichten der Fakult&auml;t als RSS-Feed” href=”http://www.zi.fh-koeln.de/rss_f10.php”>
<title>Fachhochschule Koeln</title>
</head>
<body bgcolor=”white”>
<input type=”hidden” name=”directory” value=”/sa”>
<input type=”hidden” name=”filename” value=”Startseite_sa.htms”>
<table width=”765″ border=”0″ cellspacing=”0″ cellpadding=”0″ align=”left”>
<script language=”JavaScript”>
function ImperiaSearch() {
search_win=open(‘/inc/loading.html’, ‘search’, ‘resizable=1,resize=yes,scrollbars=yes,height=500,width=650′);
document.forms.search.target=’search’;
document.search.submit()
}
</script>
……..

Es wurde sich mittels telnet auf den Webserver www.f10.fh-koeln.de auf Port 80 verbunden und mittels GET http://www.f10.fh-koeln.de der Inhalt der index.html abgefragt. Die Ausgabe geht noch weiter wurde aber abgeschnitten, um die Seitenanzahl nicht unnötig aufzublähen.

telnet www.f10.fh-koeln.de 80
Trying…
Connected to imperia-live.zam.fh-koeln.de.
Escape character is ‘^]’.
HEAD /index.html HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 14 Nov 2009 15:04:57 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_jk2/2.0.4 PHP/4.3.10-22 mod_ssl/2.0.54 OpenSSL/0.9.7e
Accept-Ranges: bytes
Connection: close
Content-Type: text/html

Connection closed.

Die Abfrage des Protokollkopfes muss mittels der Option HTTP/1.0 erfolgen. Versucht man es standardmäßig mittels HTTP/1.1 erhält man die Fehlermeldung: Bad request.

/home/kt> telnet www.neumanndaniel.de 80
Trying 82.165.115.240…
Connected to www.neumanndaniel.de.
Escape character is ‘^]’.
GET http://www.neumanndaniel.de
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<meta http-equiv=”refresh” content=”0; URL=http://www.necron.mcseboard.de”>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<meta name=”Description” content=”Offizielle Homepage von Daniel Neumann! Hier finden Sie alle Infos …”>
<meta name=”publisher” content=”Daniel Neumann”>
<meta name=”author” content=”Daniel Neumann”>
<meta name=”robots” content=”index, follow”>
<meta name=”date” content=”2006-2008″>
<meta http-equiv=”pragma” content=”no cache”>
<meta http-equiv=”Expires” content=”0″>
<meta http-equiv=”Language” content=”de”>
<link rel=”shortcut icon” href=”favicon.ico”>
<!– TemplateBeginEditable name=”doctitle” –>
<title>NeumannDaniel.de (c) by Daniel Neumann</title>
</head>
<body>
</body>
</html>
Connection closed by foreign host.
 

Hier wurde sich wieder mittels telnet auf den Webserver www.neumanndaniel.de auf Port 80 verbunden und mittels GET http://www.neumanndaniel.de der Inhalt der index.html abgefragt.

Aufgabe 1-14:

/home/kt> telnet ftp.isi.edu 21
Trying…
Connected to www.isi.edu.
Escape character is ‘^]’.
220 ftp.isi.edu NcFTPd Server (free educational license) ready.
USER anonymous
331 Guest login ok, send your complete e-mail address as password.
PASS ***********************************************

230-You are user #13 of 550 simultaneous users allowed.
230-
230-If you have problems downloading and are seeing “Access denied” or
230-“Permission denied”, please make sure that you started your FTP client in
230-a directory to which you have write permission.
230-
230-If your FTP client crashes or hangs shortly after login please try using
230-a dash (-) as the first character of your password. This will turn off
230-the informational messages that may be confusing your FTP client.
230-
230-All transfers and commands to and from this host are logged.
230-
230-If you experience any problems using ftp, please report them via
230-e-mail to Action@isi.edu.
230-
230 Logged in anonymously.
cwd /in-notes/std
250-“/in-notes/std” is new cwd.
250-
250-*====================================================================*
250-* *
250-* This directory is maintained by the RFC Editor. If you experience *
250-* any problems, please report them to rfc-editor@rfc-editor.org. *
250-* *
250-*====================================================================*
250
PASV
227 Entering Passive Mode (128,9,176,20,226,226)
RETR std1.txt
150 Data connection accepted from 139.6.57.1:41673; transfer starting for rfc500 0.txt (222566 bytes).
226 Transfer completed.
quit
221 Goodbye.
Connection closed.

Beim Übertragen trat der Fehler Write error: Bad file number auf, mittels Änderung des Übertragungsmodus in den passiven Modus (PASV) konnte anschließend die Datei korrekt übertragen werden. Allerdings muss man dazu ein zweites Konsolenfenster öffnen und die neue Portnummer berechnen. Dies geschieht mit den letzten zwei Zahlen bei „227 Entering Passive Mode (128,9,176,20,226,226)“. Die Formel dazu lautet dann 226*256+226=58082, die zu addierende Zahl ist die letzte Zahl bei „227 Entering Passive Mode (128,9,176,20,226,226)“. Ist man mit dem Server über die neue Portnummer verbunden, startet man die Übertragung im Hauptfenster und bekommt den Inhalt der Datei im zweiten Fenster angezeigt!

Aufgabe 1-15:

/home/kt> telnet mail.local 25
Trying 10.20.23.30…
Connected to mail.local.
Escape character is ‘^]’.
220 mail.local ESMTP Postfix
MAIL FROM: ktmailer1
250 2.1.0 Ok
RCPT TO: ktmailer2
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Hallo,
dies ist eine Testnachricht!
.

QUIT
Connection closed by foreign host.

Zum Versenden der Testmail wurde sich mittels telnet auf den Mailserver mail.local auf Port 25 verbunden. Absender ist ktmailer1 und Empfänger ktmailer2. Man sollte unbedingt darauf achten, dass die Nachricht mit einem freistehenden Punkt beendet wird. Mit dem Befehl QUIT verlässt man den Mailserver und sendet auch zeitgleich die Nachricht ab.

Aufgabe 1-16:

/home/kt> telnet mail.local 110
Trying 10.20.23.30…
Connected to mail.local.
Escape character is ‘^]’.
+OK ready <***********************************************>
USER ktmailer2
+OK Password required for ktmailer2.
PASS ***********************************************
+OK ktmailer2 has 11 visible messages (0 hidden) in 5555 octets.
STAT
+OK 11 5555
LAST
+OK 10 is the last read message.
RETR 11
+OK 585 octets
Return-Path: <ktmailer1@mail.local>
X-Original-To: ktmailer2
Delivered-To:  ktmailer2@mail.local
Received
: from ktdsp17.local (ktdsp17.local [10.20.23.17])
by mail.local (Postfix) with SMTP id 5FEE05F71B
for <ktmailer2>; Tue, 17 Nov 2009 16:04:36 +0100 (CET)
Message-Id: <20091117150502.5FEE05F71B@mail.local>
Date: Tue, 17 Nov 2009 16:04:36 +0100 (CET)
From: ktmailer1@mail.local
To: undisclosed-recipients:;
X-UIDL: ET2″!n5:!!kT]!!jZY!!

Hallo,
dies ist eine Testnachricht!
.

dele 11
+OK Message 11 has been deleted.
quit
+OK Pop server at *********************************************** signing off.
Connection closed by foreign host.

Zum Abrufen der versendeten Nachricht wurde sich mittels telnet auch den Mailserver mail.local auf Port 110 verbunden. Die Anmeldung erfolgte mit dem Benutzer ktmailer2 und der entsprechenden Eingabe des Passwortes. Mit dem Befehl LAST wurde die schon gelesenen Nachrichten aufgelistet, so dass die 11. Nachricht die Ungelesene sein muss, die dann mittels RETR 11 angezeigt wurde. Zum Abschluss wurde die Nachricht per dele 11 gelöscht und der Mailserver mittels quit verlassen.

Facebooktwittergoogle_pluslinkedinmail

Leave a Reply