|
MTEC4 unterstützt den Zugang zum Internet über Terminal und front-end PC. Durch
Konvertierung der Grafik- und Textformate für den PC können die Daten von dort
in Internetprojekte eingebracht, oder Daten aus dem Internet an MTEC4
weitergegeben werden. MTEC4 besitzt jedoch auch direkten Internetzugang. MTEC4-PPP: Das Point to Point Protocol (PPP) ist ein Protokoll der Datensicherungsschicht des OSI-Referenzmodells. Die Funktionsweise von PPP wird beschrieben in RFC 1661. Der neueste Stand der Kennziffern ergibt sich aus dem 'Assigned Numbers RFC'. Eine nützliche Beschreibung wird in Jamsa, Chris, Internetprogrammierung unter Windows, Bonn 1996, gegeben. Hilfreiche Unterlagen sind ferner die Quelltexte der Linux PPP Module und deren Manuale und Erläuterungen. PPP unterscheidet zwischen der Verhandlungsphase zur Vereinbarung der Daten übertragungsparameter und der darauffolgenden Datenübertragung. Die Verhandlungs phase wird üblicherweise durch ein gesondertes Modul durchgeführt, während die Datenübertragungsphase durch das mit den vereinbarten Parametern eingestellte Treiberprogramm erfolgt. Das MTEC4 Verhandlungsmodul, sowie der Treiber arbeiten auf zwei Ebenen: der Übertragungsebene, welche die Daten ggf. in verschlüsselter Form (mit Escape Codes) enthält, und den logischen Ein-/Ausgabe Bereichen, die nur noch Nutzdaten und die PPP Kopfdaten enthalten. Herstellung des PPP Rahmens PPP-Prüfziffer (Frame Check Sequence FCS), ggf. Kompression/Dekompression von Adress- und Protokollfeld erfolgt bei der Übertragung zwischen den Ebenen. MTEC4 PPP protokolliert die Verhandlungsdaten ggf. zur späteren Überprüfung. Die Verhandlungsphase besteht aus den Teilen: LCP (Link Control Protocol), in dem Parameter wie z.B. max. Länge der Empfangspakete vereinbart werden, der Authentisierung durch Passwortkontrolle, und dem Network Control Protocol, für das Internet IPCP, in dem z.B. Kompressionsverfahren und die Internetadresse vereinbart werden. Jedes dieser Protokolle wird durch eine Protokollkennziffer unterschieden. Vor der Protokollkennziffer sind PPP Kopfdaten (Hx 7E FF 03). Darauf folgen der Verhandlungscode wie Request, Akzept, Reject, die ID als Reihenfolge- und Bezugskennziffer, sowie eine zweistellige Längenangabe für den Datenteil. Darauf folgen die Verhandlungsoptionen mit Typ. Länge,Optionsdaten. Ein Datenpaket wird durch die 16 Bit FCS und das PPP Flag Hx 7E abgeschlossen. MTEC4 PPP lädt zu Beginn die für die Verhandlung erforderlichen Parameter und Verhandlungsstrategien, nach denen die Verhandlung geführt wird. Das Verhand lungsmodul kann sowohl als Client den Server anrufen und die Verhandlung durch wiederholte Requests eröffnen, als auch in der passiven Serverrolle auf Requests reagieren. Zwei Verhandlungsbespiele für aktive Eröffnung und passive Reaktion sind im folgenden in hexadezimaler Darstellung wiedergegeben. Doppelpunkt, Punkt und Space zwischen den Hexadezimalzahlen sind Gliederungszeichen zum leichteren Erkennen des Paketaufbaus und der 'Control Informations' (CI's). Im Datenstrom sind diese Gliederungszeichen nicht enthalten. 1 Send: 7E FF 03:C0 21:01.02.00 18:01.04.00 FA: 2x REQ ID=1-2,MRU=250 2 :02.06.00 0A 00 00:05.06.00 4C 83 17: ASYNCMAP=0A, 3 :07.02:08.02:fcs:7E MAGIC No.; A/P-COMPR., 4 Empf: 7E FF 03:C0 21:01.01.00 27:00.04.00 00: 1x REQ ID=1, Leeropt. 5 :01.04.05 F4:02.06.00 0A 00 00: MRU=1524, ASYNCMAP=0A, 6 :03.04.C0 23:07.02:08.02: Auth.=PAP,A/P-COMPR., 7 :11.01.05 F4: Multlnk MRU 8 :13.09.03 00 C0 7B 6E A0 6C:fsc:7E Endp.Discr. 9 7E FF 03:C0 21:02.02.00 18:01.04.00 FA: 1x ACK ID=2,MRU=250 10 :02.06.00 0A 00 00:05.06.00 4C 83 17: ASYNCMAP=0A, 11 :07.02:08.02:fcs:7E MAGIC No.; A/P-COMPR., 12 Send: 7E FF 03:C0 21:04.01.00 19:00.04.00 00:01.04.05 F4: 1x REJ ID=1, Leeropt.,MRU=1524 13 :11.01.05 F4: Multlnk MRU 14 :13.09.03 00 C0 7B 6E A0 6C:fsc:7E Endp.Discr. 15 Empf: 7E FF 03:C0 21:01.02.00 12: 1x REQ ID=2, 16 :02.06.00 0A 00 00:03.04.C0 23: ASYNCMAP=0A, Auth.=PAP 17 :07.02:08.02:fcs:7E A/P COMPRESS. 18 Send: 7E FF 03:C0 21:02.02.00 12: 1x ACK ID=2, 19 :02.06.00 0A 00 00:03.04.C0 23: ASYNCMAP=0A, Auth.=PAP 20 :07.02:08.02:fcs:7E A/P COMPRESS. 21 7E:C0 23:01.04.00 13:06.65 61 30 37 32 34: 1x REQ PAP,ID=4,LOGIN 22 :07.68 61 68 61 68 61 61:fcs:7E PASSWRD 23 Empf: 7E:C0 23:02 04 00 15:00:fcs:7E 1x ACK PAP ID=4 24 7E:80 21:01.01.00 10:02.06.00 2D 0F 01: 1x REQ IPCP ID=1,VjCP 25 :03.06.84 C3 14 F8:fcs:7E IP ADRESSE 26 7E:80 FD:01.01.00 09:11.05.00 01 04:fcs:7E 1x REQ CCP ID=1, LZS 27 Send: 7E:80 21:04.01.00 0A:02.06.00 2D 0F 01:fcs:7E 1x REJ ID=1, VjCP 28 Empf: 7E:80 21:01.02.00 0A:03.06.84 c3 14 F8:fcs:7E 1x REQ ID=2, IP ADR SERVER 29 Send: 7E:80 21:02.02.00 0A:03.06.84 c3 14 F8:fcs:7E 1x ACK ID=2, IP ADR SERVER 30 7E FF 03:80 FD:08.01.00 09:11.05.00 01 04:fcs:7E 1x PROT.REJ CCP ID=1, LZS 31 Send: 7E:80 21:01.01.00 16:03.06.00 00 00 00:81.06.00 00 00 00: 1x REQ ID=1, Leerfelder fuer 32 :83.06.00 00 00 00:fcs:7E IP ADR CLIENT, DNS1, DNS2 33 Empf: 7E:80 21:03.01.00 16:03.06.84 c3 16 07:81.06.84 c3 14 0D: 1x NAK ID=1, Zuweisung 34 :83.06.84 c3 14 03:fcs:7E IP ADR CLIENT, DNS1, DNS2 35 Send: 7E:80 21:01.02.00 16:03.06.84 c3 16 07:81.06.84 c3 14 0D: 1x REQ ID=2, 36 :83.06.84 c3 14 03:fcs:7E IP ADR CLIENT, DNS1, DNS2 37 Empf: 7E:80 21:02.02.00 16:03.06.84 c3 16 07:81.06.84 c3 14 0D: 1x ACK ID=2, Zuweisung 38 :83.06.84 c3 14 03:fcs:7E IP ADR CLIENT, DNS1 DNS2 Diese Verhandlung mit o.a. Optionen stellt die Standard PPP Verbindung für MTEC4 her. Sende- und Empfangsvorgang von MTEC4 sind gekennzeichnet. Jedes Paket ist mit Kopfdaten, Protokollkennzeichen, Code, ID, Datenlänge, gefolgt von Optionen mit Typ, Länge, Optionsdaten, wiedergegeben. Doppelpunkt und Punkte sind lediglich Gliederungszeichen, nicht Daten. Die Zeilen sind durchnummeriert. Jedes Paket ist durch den Rahmen (Kapselung), Kopf = Hx7E FF 03 und Ende = 2 Byte Prüfziffer (fcs) + Hx7E erkennbar. Jede Zeile enthält einen Kurzkommentar bezügl. des Vorgangs (Code), der ID und der Optionen. Die Verhandlung wird von MTEC4, unmittelbar nach der CONNECT Meldung des Modems, mit dem Server des Internet Providers durch zweimaliges Senden (Z.1) des LCP Requests für eine max. Paketlänge von 250 Bytes, Asyncmap, Magic No. und der A/P Kompression eröffnet. Auf die Wiederholung des Requests (ID=2) folgt Antwort des Providers durch Gegenrequest mit einem umfangreichen Repertoire von Optionen (Z.4-8), sowie die Bestätigung (ACK) der max. Paketlänge von 250 Bytes und der weiteren Optionen (Z.9-11), die damit vereinbart sind. MTEC4 weist die vorgeschlagene MRU von 1524 Bytes sowie die Multilink-Optionen durch Configure-Reject (Code=4) zurück (Z.12-14), und erhält einen neuen Request des Servers ohne die zurückgewiesenen Optionen (Z.15-17). Dieser wird von MTEC4 durch ACK (Code=2) bestätigt (Z.18-20). Damit sind außer der MRU auch die Liste der zu verschlüsselnden Zeichen (Asyncmap), die Authentisierung durch das Password Authentication Protocol PAP und die Kompression des Adress- und Proto kollfeldes vereinbart. Der Teil des Link Control Protokolls mit Protokollkenn- zeichen HxC021 ist damit beendet. Die Vereinbarungen sind bereits wirksam. Die Zeichen HxFF 03 im Paketkopf erscheinen aufgrund der A/P Kompression nicht. Die Verschlüsselung aller Zeichen kleiner Hx20 mit 7D entfällt im Sendepuffer. Lediglich die Standardverschlüsselung von XON/XOFF=Hx11,13 und Hx7D,7E bleibt. MTEC4 sendet sogleich den Request für die Authentisierung mit Protokollkennzeichen HxC023 und Login und Password(Z.21-22). Der Server des Providers sendet das ACK (Z.23). Damit ist auch der Teil der Authentisierung mit Protokollkennzeichen HxC023 PAP beendet. Der PPP Server des Providers sendet sogleich anschließend die Requests des Internet Protocol Control Protocol (IPCP) mit Kennzeichen Hx8021 (Z.24-25) und des Compression Control Protocol (CCP) mit Kennzeichen Hx80FD (Z.26). Der IPCP Reqest enthält die Optionen der Van Jacobson Kompression für Header von IP Datagrammen, die von 20 auf 3 Byte reduziert werden können, und der IP Adresse des Servers. Die Vj Kompression wird von MTEC4 zurückgewiesen (Z.27). Der IP Server sendet einen neuen Request ohne Vj Kompression, nur mit der IP Adr. Dieser Request wird von MTEC4 mit ACK bestätigt(Z.28-29) und ist vereinbart. Der CCP Request, der eine LZS Datenverdichtung vorschlägt, wird durch Protocol Reject (Code=8) von MTEC4 zurückgewiesen (Z30). MTEC4 sendet nun einen Request mit Leerfeldern für die eigene IP Adresse, und den Adressen der Domain Name Server 1 und 2 (Z.31-32. Diese Adressen werden mit einem NAK Paket (Z.33-34) vom IP Server dynamisch zugeteilt. MTEC4 sendet darauf Request mit diesen Adressen und erhält vom Server mit ACK die Bestätigung (Z.35-38). Damit ist auch der Teil IPCP (und CCP) der PPP Verhandlung, und damit die gesamte PPP Verhandlungsphase beendet. Der PPP Kanal steht nun für die Übertragung von Internetdaten offen. Im zweiten Verhandlungsbeispiel wird MTEC4 von einem Client PC mit WINDOWS ME zum Aufbau der DFUE Verbindung angerufen. MTEC4 reagiert als Server. Abgesehen von der Eröffnung wird der Dialog weitgehend wie im vorangehenden Beispiel abgewickelt.Die WINDOWS PPP Wählmaske wurde auf Arbeiten ohne Vj Kompression von IP Headern und ohne Datenkompression eingestellt. Diese Optionen erscheinen nicht mehr. Ebenso wird von MTEC4 als Server kein Multilink Verfahren vorgeschlagen. Bereits das erste WINDOWS LCP Request Paket, das bis zu 10 mal wiederholt würde, erhält Antwort von MTEC4. 1 Empf: 7E FF 03:C0 21:01.01.00 17:02.06.00 0A 00 00 1x REQ ID=1, ASYNCMAP 2 :05.06.00 05 54 C9:07.02:08.02: MAGIC NO, A/P COMPRESS 3 :0D.03.06:fcs:7E CALLBACK 4 Send: 7E FF 03:C0 21:04.01.00 07:0D.03.06:fcs:7E 1x REJ ID=1, CALLBACK 5 Empf: 7E FF 03:C0 21:01.02.00 04:02.06.00 0A 00 00: 1x REQ ID=2, ASYNCMAP 6 :05.06.00 05 54 C9:07.02:08.02:fcs:7E MAGIC NO, A/P COMPRESS 7 Send: 7E FF 03:C0 21:02.02.00 0A:02.06.00 0A 00 00: 1x ACK ID=2, ASYNCMAP 8 :05.06.00 05 54 C9:07.02:08.02:fcs:7E MAGIC NO, A/P COMPRESS 9 7E FF 03:C0 21:01.03.00 16:01.04.00 FA:02.06.00 0A 00 00: 1x REQ ID=3, MRU,ASYNCMAP 10 :03.04.C0 23:07.02:08.02:fcs:7E PAP, A/P COMPRESS 11 Empf: 7E FF 03:C0 21:02.03.00 16:01.04.00 FA:02.06.00 0A 00 00: 1x ACK ID=2, MRU,ASYNCMAP 12 :03.04.C0 23:07.02:08.02:fcs:7E PAP, A/P COMPRESS 13 7E:C0 23:01.04.00 13:06.65 61 30 37 32 34: 1x REQ PAP, ID=4,LOGIN 14 :07.68 61 68 61 68 61 61:fcs:7E PASSWRD 15 Send: 7E:C0 23:02.04.00 05:00:fcs:7E 1x ACK PAP ID=4 16 7E:80 21:01.01.00 0A:03.06.84 C3 14 F8:fcs:7E 1x REQ IPCP ID=1, IP ADR SERVER 17 Empf: 7E:80 21:02.01.00 28:03 06 84 c3 14 F8:fcs:7E 1x ACK IPCP ID=1, IP ADR SERVER 18 7E:80 21:01.01.00 28:03 06 00 00 00 00: 1x REQ IPCP ID=1, IP ADR CLIENT leer 19 :81.06.00 00 00 00:82.06.00 00 00 00: DNS1, NBNS1 ADR leer 20 :83.06.00 00 00 00:84.06.00 00 00 00:fcs:7E DNS2, NBNS2 ADR leer 21 Send: 7E:80 21:04.01.00 10:82.06.00 00 00 00 00: 1x REJ IPCP ID=2 NBNS1, 22 :84.06.00 00 00 00:fcs:7E: NBNS2 ADR 23 Empf: 7E:80 21:01.02.00 14:03 06 00 00 00 00: 1x REQ IPCP ID=2, IP ADR CLIENT leer 24 :81.06.00 00 00 00:83.06.00 00 00 00:fcs:7E DNS1, DNS2 ADR leer 25 Send: 7E:80 21:03.02.00 14:03.06.84 c3 16 07: 1x NAK IPCP ID=2 mit IP ADR CLIENT, 26 81.06.84 c3 14 0D:83.06.84 C3 14 03:fcs:7E DNS1, DNS2 27 Empf: 7E:80 21:01.03.00 14:03.06.84 c3 16 07: 1x REQ IPCP ID=3 IP ADR CLIENT 28 81.06.84 c3 14 0D:83.06.84 C3 14 03:fcs:7E DNS1, DNS2 29 Send: 7E:80 21:02.03.00 14:03.06.84 c3 16 07: 1x ACK IPCP ID=3 IP ADR CLIENT 30 81.06.84 c3 14 0D:83.06.84 C3 14 03:fcs:7E DNS1, DNS2 31 Send: 7E FF 03:C0 21:05.05.00 04:fcs:7E 1x TERM REQ ID=5 32 Empf: 7E FF 03:C0 21:06.05.00 04:fcs:7E 1x TERM ACK ID=5 MTEC4 beantwortet den Eröffnungsrequest von WINDOWS mit einer Zurückweisung (REJECT) der Option CALLBACK. Der zweite Request von WINDOWS, nur noch mit den Optionen ASYNCMAP, MAGIC No., die der Erkennung von internen Loops dient, und A/P Kompression, wird von MTEC4 akzeptiert und bestätigt. MTEC4 sendet einen Request für MRU=250, ASYNCMAP, Authentisierung mit dem Password Authentication Protocol PAP, A/P Kompression und erhält von WINDOWS Bestätigung durch ein ACK Paket. Der LCP Teil endet mit den vereinbarten Optionen MRU=250, ASYNCMAP der Authentisierung durch PAP und der Kompression des Adress- und des Protokollfeldes als beiderseitige Vereinbarungen Es folgt der PAP Authentiserungsrequest von WINDOWS mit Logon und Password und die Bestätigung seitens MTEC4. MTEC4 sendet darauf im Network Control Protocol IPCP die (eigene) IP Adresse des Servers und erhält Bestätigung. WINDOWS sendet darauf einen Request mit Leerfeldern für die IP Adresse des Client, und die erste und zweite Adresse des Domain Name Servers und der NBNS1 und 2. Da die letzteren Adresssen zumeist nicht benötigt werden, wird die dynamische Vergabe der letzteren Adressen zurückgewiesen. WINDOWS sendet darauf einen neuen Request ohne die Leerfelder fur NBNS1,2. Auf diesen Request weist MTEC4 die IP Adressen mit einem NAK Paket dynamisch zu (Code=3).Der Client WINDOWS bestätigt mit ACK (Code=2). Damit sind die erforderlichen Vereinbarungen für LCP, PAP, IPCP getroffen und es können nun Internetdaten ausgetauscht werden. Die WINDOWS PPP Wählmaske verschwindet auf dem Bildschirm des PC. Nun könnte Telnet ausgeführt werden. Da MTEC4 eine Testverhandlung führt, die in diesem Fall nicht zur Datenüber tragung genutzt wird, schließt MTEC4 den PPP Kanal, wie nach erfolgter Daten übertragung, durch Senden eines Termination Requests (Code=5). Die mit dem Restart Timer auf ca 3 Sekunden befristete Verhandlungspause wird durch das Termination ACK des Client (Code=6) bendet und der PPP Kanal geschlossen. Da es MONDENIA insbesondere um eine effiziente Softwarelösung auf einem Micro- Computer geht, wurde der für MTEC4-PPP zusätlich zum Dialer und DFUE Treiber des Terminals entwickelte Softwareaufwand auf etwa 1KB beschränkt. Die Routine für die Berechnung der FCS beträgt incl. Tabelle etwa 128 Byte, die Verhandlungs strategien benötigen ca. 400 Byte. Timer, Paketaufbau und Führung der I/O Bereiche auf logischer und auf Treiberebene belegen den restlichen Maschinen- programmcode. |
| HOME |