Nach etwas Theorie - leider geht es nicht ohne - wird es hier nun langsam praktischer. Ein TCPIP-Stack ohne Software ist wertlos, egal ob er an einem Controller oder Z80 hängt. Da das für mich ebenfalls absolutes Neuland war, was meine Programmieraktivitäten auf dem KC85-System betrifft, hat es ein wenig gedauert mit fertigen Programmen aber irgendwann ist es dann soweit.

Im folgenden Artikel geht es um das Universalwerkzeug zum Test der KCNET Hard- und Software. Das Programm kann gleichzeitig als Lernspielzeug für die Durchführung der ersten Netzwerk-Experimente eingesetzt werden, um die Funktionsweise von TCPIP-Programmen als Client oder Server im Netzwerk zu verstehen.

Allgemeines

Mit der mittlerweile fünften Hauptversion wird die Weiterentwicklung beendet und ich habe die endgültigen Leistungsmerkmale festgelegt. Die beiden Programme CAOSNET.KCC und CPMNET.COM sind nun absolut identisch, was die einzelnen Menüs und ihre Funktionen betrifft. Entsprechend dem Programmnamen ist das eine für die CAOS-Betriebsart eines KC85 gedacht, das andere kann man nur unter CP/M mit einer Diskettenerweiterung D004 benutzen.

Die beiden Programme stellen die Referenzsoftware für das KCNET-Interface dar, da nahezu alle Möglichkeiten der Treiberschnittstellen damit demonstriert werden. Vom Nutzen her gesehen, sind sie vor allem für die Diagnose und den Test des Netzwerkes gedacht. Die Quellcodes stehen komplett zur Verfügung, sie sind für den Microsoft-Assembler M80 und kompatible geeignet. Ohne D004 muss man alle Programmieraktivitäten z.B. in einen Emulator auf den PC auslagern, dass funktioniert auch unter Windows, die komplette Software wurde so programmiert.

Die anschliessende Vorstellung der Testfunktionen und ihre Programmierung lässt sich damit für Interessierte nachvollziehen. Die beiden Programme zeigen den Gebrauch aller Schnittstellenfunktionen des KCNET-Protokolls und enthalten einige Beispiele für die mögliche Programmierung der verschiedenen Schichten des TCPIP-Stacks W5100 mit den gängigen Protokollen. Auch die relativ nutzlosen Menübefehle ICMP- und (E)MAC-Socket wurden aus diesem Grund im Testprogramm gelassen.

In den folgenden Abschnitten wird nicht mehr zwischen CAOS oder CP/M unterschieden, alle Testfunktionen sind absolut identisch. Für die Eingabe von Werten per Tastatur gilt prinzipiell immer, wenn man gar nichts eingibt, kommt man aus der Eingabe ohne Veränderungen wieder heraus, ein Abbruch erfolgt unter CP/M mit ESC oder CTRL-C und unter CAOS mit BRK, soweit das möglich ist.

Da beide Programme die Software-Schnittstelle des KCNET testen und demonstrieren sollen, wurde alles in drei Menüs verpackt, so dass man passend zur Softwarelogik auf 3 Ebenen Funktionen aufrufen kann.

CAOSNET.KCC

CAOSNET.KCC ist ein ganz normales CAOS-Programm, welches man von Kassette oder Diskette/HDD mit LOAD bzw. FLOAD laden kann. Das Programm läuft im Arbeitsspeicher des Grundgerätes ab Adresse 200H bis knapp unter 4000H und trägt nach dem Laden 3 neue Befehle in das CAOS-Menü ein, womit die 3 Testmenüs des Programmes aufgerufen werden können:

Da unter CP/M die CAOS-Menüverwaltung fehlt, enthält das Programm eine eigene Menüsteuerung. Man wechselt mit den Buchstaben I, T und N zwischen den Menüs und ruft dort ebenfalls mit Buchstaben oder Ziffern, welche angezeigt werden, die einzelnen Funktionen auf, mit Q oder X kann das Programm jederzeit beendet werden. Beim Start von CPMNET.COM gelangt man standardmässig immer zuerst in das Netzwerk-Menü.

Das Interface Menü bildet den grössten Teil des KCNET-Protokolls direkt ab und reicht die Werte von/an die entsprechende Menü-Funktion durch:

TCPIP-STACK MENU

Das TCPIP-Stack Menü enthält Befehle für die manuelle Einstellung der wichtigsten statischen Parameter des TCPIP-Stacks W5100 und zwei Funktionen für die Anzeige und das Zurücksetzen der gesamten Konfiguration:

Ganz oben wird die aktuelle IP-Adresse und Subnetzmaske für das Interface angezeigt und ob eingehende PING Echo-Anforderungen beantwortet werden sollen oder nicht (PING-Block Mode).

Mit Hilfe dieses Menüs lassen sich diverse Parameter des W5100 anzeigen oder ändern, weiterführende Informationen und Erläuterungen dieser Parameter sind wieder im Datenblatt des W5100 zu finden:

Die  Funktion IPCONFIG / IP-CONFIG gibt die aktuelle TCPIP-Konfiguration des Stacks ähnlich dem MSDOS-Kommando "IPCONFIG" in Form einer komletten Übersicht aus. Dieses Kommando ist deshalb immer die Anlaufstelle Nummer 1, wenn man die aktuellen Parameter wissen bzw. überprüfen will. Auch bei Fehlfunktionen oder merkwürdigem Verhalten von Netzwerkprogrammen sollte man zuerst diese Funktion aufrufen und die Parameter kontrollieren.

Mit RESET wird der komplette Stack zurückgesetzt, wobei man eine bestehende Netzwerkkonfiguration erhalten oder löschen lassen kann. Das wäre die zweite Massnahme bei Unklarheiten oder Störungen - der gesamte TCPIP-Stack wird neu initialisiert und muss danach wieder normal funktionieren.

Eine manuelle Konfiguration der Netzwerkparameter wird ebenfalls in diesem Menü vorgenommen und umfasst mindestens die Eingabe gültiger Parameter für die IP-Adresse und Subnetzmaske. Anschliessend sollte der CAOS- bzw. CP/M-Rechner im Netzwerk auf PING-Kommandos antworten (siehe Artikel Netzwerk-Konfiguration).

Wenn man auch auf Dienste ausserhalb des eigenen Netzwerkes, z.B. im Internet, zugreifen möchte, muss auch die IP-Adresse des Netzwerk-Gateway eingetragen werden, das ist im Normalfall die IP-Adresse des Routers im Netzwerk. Diese IP-Adresse wird auch automatisch als IP-Adresse für den DNS-Server im Netzwerk übernommen, wenn diese noch nicht konfiguriert wurde.

Wenn man in seinem Netzwerk einen DHCP-Server zur Verfügung hat. sollte man die Konfiguration der Netzwerkparameter dem DHCP-Client des KC85 überlassen, so wie das im Beitrag zur Netzwerk-Konfiguration beschrieben wurde.

Mit der Funktion ETH_MAC/MAC-ADDRESS wird die Ethernet-MAC-Adresse des KCNET-Interface angezeigt.

Mit den beiden Funktionen für RETRY TIME und RETRY COUNT (siehe Datenblatt W5100) können die Werte für die Reaktion des TCPIP-Stacks auf Timeout-Zustände einer bestehenden TCP-Verbindung eingestellt werden.

Mit dem Kommando PING ECHO kann man die Beantwortung von PING Echo-Request- mit PING Echo-Reply-Paketen durch den W5100 ein- und ausschalten.

Das Kommando SOCKET MODE listet die aktuellen Betriebszustände der 4 Sockets des W5100 auf, das ist ganz nützlich, um zu sehen, ob reservierte Sockets durch die Netzwerkprogramme ordnungsgemäss freigegeben werden - eigentlich sollte dort immer viermal FREI bzw. FREE zu sehen sein.

In diesem Menü sind alle Netzwerkfunktionen der beiden Testprogramme zusammengefasst, neben 3 Befehlen, welche die Arbeit mit bereits umgesetzten RFC-Protokollen ermöglichen, gibt es 5 Funktionen, welche die grundsätzliche Arbeitsweise der Schichten des TCPIP-Stacks veranschaulichen sollen:

Grundlagen und Erläuterungen zu den nachfolgend verwendeten Begriffen und Bezeichnungen können im Artikel Netzwerk-Software nachgelesen werden, sie werden deshalb an dieser Stelle nicht noch einmal aufgeführt.

Im oberen Bereich sieht man seine eigene IP-Adresse und den aktuellen Port für die Kommunikation auf UDP- bzw. TCP-Ebene mit den entsprechenden Funktionen.

Hinter PEER steht das noch einmal, das sind die Angaben für den Netzwerkteilnehmer, mit dem die letzte Kommunikation stattgefunden hat.

Alle Funktionen des Netzwerkmenüs, wo Daten über das Netzwerk transportiert werden, erfordern einen zweiten Netzwerkteilnehmer, dessen IP-Adresse bekannt sein muss.

Wenn im Netzwerk eine Auflösung von Namen per DNS funktioniert (das probieren wir gleich aus), kann man auch mit den lokalen Domainnamen arbeiten. Für die Auflösung von Internet-Domain-Namen muss der Gateway und DNS-Server konfiguriert sein (siehe Artikel zur Netzwerk-Konfiguration).

Wenn man eine Clientfunktion startet, muss man die Portnummer des Serverprogrammes kennen und u.U. auch eingeben (mit Doppelpunkt zwischen IP-Adresse/Name und Port), damit eine Verbindung hergestellt werden kann. Wenn man keinen Port angibt, wird die oben angezeigte Portnummer des PEER verwendet. Sie kann auch mit der Funktion PEER PORT vorher einzeln eingegeben werden.

Eine Serverfunktion startet wiederum grundsätzlich mit der oben angezeigten Portnummer hinter LOCAL, welche man vorher mit der Funktion LOCAL PORT entsprechend einstellen muss. Ein Server muss die Portnummer des PEER nicht kennen, da sich dieser selbst aktiv meldet.

Je nachdem, ob der KC85 jetzt als Client oder Server im Netzwerk funktionieren soll, ist auf die Angabe bzw. Einstellung der richtigen Parameter zu achten, sonst werden die Experimente mit den TCP- und UDP-Socketfunktionen nicht funktionieren!

Als Kommunikationspartner im Netzwerk wird bei den meisten Anwendern ein Windows PC dienen. Da wir das Interface testen wollen, benötigen wir daher auf der PC-Seite ein Programm, welches TCP- bzw. UDP-Rohdaten, das sind Netzwerkdaten ohne Protokoll, so wie sie ankommen, empfangen und anzeigen bzw. umgekehrt entgegennehmen und senden kann.

Dafür ist das Hercules-Utility von http://www.hw-group.com (siehe dort Bereich SOFTWARE oder per Suchfunktion) ideal geeignet, da es für alle drei TCP/UDP-Socket Funktionen von CAOSNET bzw. CPMNET die passende Peer-Funktion für den Test der Kommunikation integriert hat. Auf der Herstellerseite ist das sogar alles in deutsch beschrieben und eine Installation auf dem PC ist auch nicht notwendig, einfach die HERCULES.EXE starten und testen, im Bild sieht man beispielsweise die Einstellung für den Test eines UDP-Sockets:

Nach dem Start des Programmes wählt man mit den Reitern ganz oben die entsprechende Seite aus, trägt IP-Adresse (Module IP) und Port des KC85 ein und kann dann wie mit einem Terminalprogramm Textnachrichten verschicken und empfangen.

Die nachfolgende Tabelle fasst die Problematik mit den richtigen Portnummern von Client und Server noch einmal übersichtlich zusammen, bevor es zu den einzelnen Funktionen des Netzwerkmenüs geht:

DHCP CLIENT

Diese Funktion startet die automatische Netzwerk-Konfiguration für das Interface durch den DHCP-Dienst des lokalen Netzwerkes, wenn entweder die IP-Adresse oder Subnetzmaske nicht konfiguriert sind. Voraussetzung dafür ist ein DHCP-Server im Netzwerk, welcher selbständig gefunden wird.

Es werden insgesamt 7 Versuche unternommen, eine Konfiguration vom Server zu erhalten, wobei schrittweise die Wartezeit zwischen den einzelnen Anfragen immer weiter erhöht wird, um auch in "schlechten" Netzwerken eine Antwort zu bekommen - selbst in Ballenstedt hat es spätestens im vierten Anlauf immer geklappt :-). Der gesamte Vorgang kann bis zu ca. 60s dauern und wird danach mit einer Timeout Meldung abgebrochen.

Beim Aufruf der Funktion muss man für den KC einen Computer-Namen für den DNS-Dienst im lokalen Netzwerk eingeben. Wenn man nichts eingibt, wird die Funktion abgebrochen. Der gesamte Vorgang kann auch vorzeitig mit Hilfe der o.g. Abbruchtasten beendet werden.

Wie das DHCP-Protokoll funktioniert, kann man in RFC 2131 nachlesen, beispielsweise auf www.rfc-editor.org.

Der gleiche Client ist im CP/M Konfigurationsprogramm NCFG.COM (siehe Software -> CP/M) eingebaut, dort muss der Name als Argument in der Kommandozeile angegeben werden. Die empfangenen Daten vom DHCP-Client überschreiben immer eventuelle bereits eingetragene andere Parameter, wie beispielsweise Gateway oder DNS-Server IP-Adresse, wenn sie in der Antwort des DHCP-Servers zurückgegeben werden.

Wenn die Kommunikation zwischen DHCP-Client und DHCP-Server erfolgreich war, wird eine komplette Liste mit allen erhaltenen Parametern auf dem Bildschirm ausgegeben und gleichzeitig das KCNET-Interface damit konfiguriert.

PING CLIENT

Hinter dieser Funktion steckt ein erwachsener ICMP-Client/Server bereits in der dritten Version. Was das ist und wozu das gut ist, steht im Artikel zur Netzwerk-Konfiguration. Das ICMP-Protokoll wird in RFC 792 beschrieben. Die Leistungsfähigkeit des Client liegt mittlerweile irgendwo zwischen den Windows- und Linux-Clients, welche dort mit dem Betriebssystem geliefert werden.

Da es davon auch eine Einzelvariante PING.COM für CP/M gibt, wird die Funktionalität dort beschrieben (siehe Software -> CP/M).

Nach dem Start der Funktion steht unten PING _ und der Cursor blinkt. Jetzt kann einmalig ENTER gedrückt werden, worauf die komplette Hilfe ausgegeben wird und wieder PING _ vor sich hin blinkt. Nach Eingabe der optionalen Parameter und des obligatorischen Zieles, werden entsprechend PING-Requests gesendet und die Antworten oder Fehlermeldungen ausgegeben.

Das Ziel kann auch als Domain-Name eingegeben werden, die IP-Adresse wird dann im Hintergrund durch eine DNS-Abfrage entsprechend aufgelöst.

DNS CLIENT:

Diese Funktion ist der Zugang zum sogenannten Resolver. Der ist für die Umwandlung von Domain-Namen in numerische 32 Bit IP-Adressen oder umgekehrt zuständig. Normalerweise bekommt man den unter anderen Betriebssystemen gar nicht zu Gesicht, da er meist im Hintergrund arbeitet aber immens wichtig ist. Ohne ihn müssten wir alle Web-Adressen als IP-Adresse eingeben, was dem Internet sicher nicht zum Durchbruch verholfen hätte.

In RFC 1034/1035 wird DNS beschrieben, wobei es zahlreiche ergänzende Dokumente gibt, wie beispielsweise RFC 2929, RFC 3696 oder RFC 4343.

Der Resolver des KC85 stellt nur die Grundfunktionalität eines DNS-Clientprogrammes zur Verfügung, was in 99,9 % aller Fälle für ein Heimnetzwerk ausreicht.

Nach dem Start der Funktion kann man nun einen beliebigen Domain-Namen eingeben und ENTER drücken, worauf die entsprechende IP-Adresse als Ergebnis ausgegeben wird oder eine Fehlermeldung (die Ursachen der möglichen Fehlermeldungen kann man im Quelltext der Datei DNSCxx.INC nachlesen). Ein DNS SERVER ERROR 3 bedeutet, dass kein Host mit dem eingegeben Namen gefunden wurde, das kann auch ein Schreibfehler sein :-) !

Der umgekehrte Weg kann dafür benutzt werden, herauszufinden, ob eine lokale Auflösung von Hostnamen im Heimnetzwerk zur Verfügung steht. Also die IP-Adresse des KC85 eingeben und ENTER, wenn ein Name zurückgegeben wird, kann man den KC unter diesem Namen dann auch im lokalen Netz ansprechen. Wenn nicht, müssen in allen Netzwerkanwendungen als Ziel immer und auschliesslich die IP-Adressen der lokalen Rechner im eigenen Netzwerk angegeben werden!

Für Ziele im Internet trifft das natürlich nicht zu. Dort werden die Hostnamen über die DNS-Server Eures Internet-Providers aufgelöst und das sollte immer funktionieren!

TCP SERVER:

Mit dieser Funktion wird der KC85 zum TCP-Server im Netzwerk. Nach dem Start tut sich erst mal nicht viel, es erfolgt eine Meldung, dass der Server auf dem eingestellten lokalen Port läuft und auf einen Client wartet.

Jetzt kann man mit der TCP-Client Funktion des o.g. HERCULES Programmes mit den in der Tabelle dargestellten Parametern eine Verbindung herstellen, indem man CONNECT betätigt. Der KC gibt  daraufhin eine entsprechende Meldung am Bildschirm aus, wo man sehen kann, wer sich verbunden hat. 

Nun kann man auf dem KC mit ENTER bzw. TAB (CP/M) einen Text eingeben, welcher nach Bestätigung an den CLIENT gesendet wird und dort im Fenster 'Received/Sent data' ausgegeben wird. Umgekehrt kann der CLIENT natürlich auch Nachrichten an den KC-Server schicken, welche dieser auf der Konsole ausgibt.

Das lässt sich nun unendlich fortsetzen, bis einer der beiden Teilnehmer die Verbindung beendet, das kann sowohl clientseitig als auch serverseitig erfolgen. Wenn der Client die Verbindung kappt, wird der Server auf dem KC85 sofort wieder neu gestartet und wartet wieder auf eine neue Verbindungsaufnahme bis man ihn beendet.

Mit >E< kann der KC85 bei bestehender Verbindung in den Echomodus umgeschaltet werden, siehe Artikel zum KCNET 1.2, wo diese Betriebsart genauer erläutert und für die Ermittlung der Schnittstellengeschwindigkeit eingesetzt wurde.

TCP CLIENT:

Das ist das Gegenstück zur TCP-Server Funktion, jetzt muss man erst HERCULES als TCP-Server starten.

Anschliessend kann man die TCP-Client Funktion auf dem KC85 aufrufen, den PC mit HERCULES als Ziel eingeben und bestätigen. Als Zielangabe sind der PC-Name (nur mit DNS) oder die IP-Adresse und optional der Port, durch Doppelpunkt getrennt, zulässig. Wenn kein Port angegeben wird, benutzt das Programm die aktuelle PEER-Einstellung.

Nach dem Herstellen der Verbindung, bestehen genau die gleichen Möglichkeiten, Daten auszutauschen, wie bei der Server-Funktion. 

UDP SOCKET:

Die UDP-Socket Funktion entspricht von der Funktionalität her den beiden TCP-Funktionen. UDP arbeitet aber verbindungslos. D.h., man kann nach dem Öffnen des UDP-Sockets auf dem KC85 und auf dem Peer-PC Daten senden und empfangen, wobei der Sender die Portnummer des Empfängers kennen muss, sonst kommt nichts an, siehe Tabelle!

Beide Teilnehmer - oder mehrere untereinander - können Daten gleichzeitig senden und empfangen. Deshalb muss man vor dem Senden einer Nachricht auch jedesmal das Ziel wie oben neu eingeben. Aus diesem Grund wird eine UDP-Kommunikation auch als multiplexfähig bezeichnet.

Nachteil von UDP - man weis nicht, ob die gesendeten Daten auch ankommen, da keine Verbindung zwischen den Teilnehmern aufgebaut wird. Man kann das sehen, wenn beispielsweise HERCULES auf dem PC beendet wird. Der KC kann immer noch Daten an den PC schicken, was mit OK bestätigt wird - die werden dort aber nachweislich nicht mehr entgegengenommen!

ICMP SOCKET:

Die Funktion ICMP SOCKET arbeitet auf IP-Ebene und zeigt an, wenn ein anderer Rechner den KC85 anpingt. Wenn man auf dem Bildschirm des KC etwas sehen will, muss man an dessen IP-Adresse also PING-Pakete schicken.

Wenn man einen Socket des W5100 im IPRAW-Mode öffnet, wird die interne automatische Beantwortung von PING-Requests abgeschaltet und der Software überlassen.

Der KC85 beantwortet solche Nachrichten dann nicht mehr, da das in dieser einfachen Socket-Funktion nicht implementiert ist. Man bekommt deshalb auf dem pingenden Rechner nur Timeouts gemeldet, obwohl der KC online ist und funktionsfähig am Netzwerk hängt.

(E)MAC SOCKET:

Die Funktion (E)MAC SOCKET zeigt schliesslich noch bestimmte Inhalte und Informationen von eingehenden Ethernet-Frames an, welche für den KC85 bestimmt sind. Auf diese Art und Weise arbeiten die meisten Netzwerk-Sniffer, mit denen das Netzwerk auf der tiefsten möglichen Schicht der Netzwerk-Schnittstelle angezapft und abgehört werden kann.

Das ist für die Diagnose von Netzwerkstörungen unentbehrlich und war mir beispielsweise auf der PC-Seite während der Entwicklung als schnelle Möglichkeit sehr behilflich, die Netzwerkdaten, welche der KC85 sendet, anzuschauen. Die waren natürlich auch oft falsch - dann kommt weiter oben im eigentlichen PC-Netzwerkprogramm nichts an, da das Protokoll nicht eingehalten wird!

Das ist eine sehr nützliche Geschichte für neue Programme, siehe www.wireshark.org.