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:
| Adresse | Bit/s | Kbit/s – Bit/s durch 1000 | Mbit/s – Kbit/s durch 1000 |
| www.gm.fh-koeln.de | 1144134,08 | 1144,13 | 1,14 |
| www.lacnic.net | 4417,54 | 4,46 | 0,0044 |
| www.dfn.de | 90796,24 | 90,80 | 0,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ät fü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ä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=https://www.danielstechblog.io”>
<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.