ax25

[Gutheil]

Das AX25-Protokoll
------------------

Von verschiedenen Seiten wurde die Bitte an mich herangetragen, einmal
zu erklaeren, was es mit dem ominoesen AX25-Protokoll auf sich hat, was ja
zwangslaeufig alle fuer Packet-Radio benutzen.

Eins vorneweg: ich moechte hier lediglich den Versuch unternehmen, das
AX25-Protokoll fuer den Durchschnitts-OM verstaendlich zu machen.
Dies soll kein Ersatz fuer eine Protokollbeschreibung sein sondern
eher der Versuch, praxisnah zu beschreiben was genau in einer Verbindung
passiert und welche moeglichen Fehler auftauchen koennen. Vor allem
soll es eine Hilfe sein, die Quellen fuer auftretende Fehler zu finden,
indem genau festgestellt werden kann, warum z. B. keine Daten uebertragen
werden.

Jeder kennt ja sicherlich seinen Monitor und die endlosen Datenketten
die dort zu sehen sind.

Die Packets nennt man meistens Frames, das ist das englische Wort fuer Rahmen.
Diese Bezeichnung ruehrt daher, dass jedes Packet von 2 Rahmen-Zeichen
(den eigentlichen Frames) umfasst wird. Dies braucht uns aber fuer die
weiteren Ausfuehrungen nicht zu interessieren. Wer es genauer wissen will,
kann dann mal in die Protokollbeschreibung einsteigen (Sollte auch unter
der Rubrik AX25 zu finden sein).

Es gibt verschiedene Sorten von Frames, zu unterscheiden sind sie ganz
leicht. Ich benutze fuer meine Beispiele die Darstellung der
WA8-Firmware fuer TNCs (sowie alternativ die von DIGICOM/BAYCOM).
Wer SP besitzt und dasselbe Anzeigeformat auf dem Monitor
haben will, muss in der SP.CFG WA8=1 setzen, sonst gibt SP ein
komprimiertes Hybridformat aus. Ich persoenlich mag es nicht, aber das
ist wie vieles im Leben Geschmackssache...
Das WA8-Format ist etwas klarer und uebersichtlicher vor allem fuer
Anfaenger.

Also fangen wir ganz vorne an:

So sieht ein Verbindungsaufbau aus:

TNC:
fm DL8GAM-11 to DB0FRB via FF6KDL ctl SABM+ - 05.05.91 11:00:45

DC:
11:00 DL8GAM-11/DB0FRB>FF6KDL>SABM,P

fm DL8GAM-11: DL8GAM-11 ist das Absenderrufzeichen, moeglich sind
hier hinter dem eigenen Callsign insgesamt 16 sogenannte
SSID's. Also DL8GAM-0 (=DL8GAM) bis DL8GAM-15. Jedes SSID-
Call wird vom Digi als eigenes Rufzeichen behandelt, man
kann also mehrfach ein und dieselbe Station (wie z. B.
den Lokaldigi) connecten.

via FF6KDL Digipeaterrufzeichen, in der Reihenfolge wie das Packet
(/FF6KDL) sie durchlaufen soll, bis zu acht sind theoretisch moeglich.

to DB0FRB: Zielrufzeichen.
(>DB0FRB)

ctl SABM+ Set Asynchronous Balanced Mode = Verbindungsaufbau
(>SABM,P)

Dahinter folgt eine Datum/Zeit-Angabe, der mit dem TNC-Kommando K ein- oder
ausgeschaltet werden kann (C 64er: Nur Zeit, umschalten mit :M Q).

Interessant ist vor allem das Kontrollfeld; hier laesst sich ablesen, wie
sich die Controller untereinander verstaendigen.

Es gibt drei Sorten von Frames:

Info-Frames enthalten Information, also Text

Steuer-(Supervisory-)Frames sind notwendig, um z. B. die Verbindung aufzu-
bauen, ankommende Pakete zu bestaetigen, nachzufragen usw.

Unnumbered Frames sind auch Info-Frames, aber unprotokolliert. Sie
tragen also keine Nummer und werden ueblicherweise auch nicht bestaetigt.

Steigen wir also gleich mal ein bei den Info-Frames.

Ein Info-Frame das auf dem Monitor erscheint ist zwangslaeufig korrekt
empfangen worden. Das TNC nimmt eine Ueberpruefung vor, ob Checksumme
und Inhalt des Paketes uebereinstimmen. Erst wenn diese Pruefung
erfolgreich war, wird das TNC das Packet ans Terminal weiterreichen.

Ein Info-Frame sieht zum Beispiel so aus:

TNC:
fm FF6KDL to DL8GAM ctl I00^ pid F0
RMNC/FlexNet V. 3.0a DIGIPEATER du REF68 - Petit-Ballon - JN37NX - 433.625 Mhz
DB0ORT <---= FF6KDL =---> HB9EAS
- (I)nfos digi - (H)elp - (U)sagers - (L)inks - (D)igis - (A)ctuel 04.05.91 -
=>

DC:
FF6KDL>DL8GAM>I00,C,F0:
RMNC/FlexNet V. 3.0a DIGIPEATER du REF68 - Petit-Ballon - JN37NX - 433.625 Mhz
DB0ORT <---= FF6KDL =---> HB9EAS
- (I)nfos digi - (H)elp - (U)sagers - (L)inks - (D)igis - (A)ctuel 04.05.91 -
=>

Die erste Zeile enthaelt den Header, jede weitere Zeile Text.
Der Header ist der "Kopf" jedes Frames; er enthaelt Informationen
darueber, von wem ueber welchen Weg an wen diese Packet geht,
sowie weitere Kontrollinformationen. Danach koennen dann bis zu
256 Zeichen Text in ein Info-Frame kommen.

SP zum Beispiel kann Header und Text unterschiedlich einfaerben, das
erleichtert die Uebersicht sehr.

Nun wird das Packet natuerlich bestaetigt, in diesem Falle mit:

TNC: DC:
fm DL8GAM to FF6KDL ctl RR1v DL8GAM>FF6KDL>RR1,R

RR1v bzw. RR1,F bedeutet folgendes:

Packet Nummer 0 wurde korrekt empfangen, als naechstes Packet erwartet
der TNC das Packet Nummer 1.

Kommt nun diese Bestaetigung nicht an, so fragt die Gegenstation nach
einer Weile nach, was nun aus dem Packet geworden ist:

fm FF6KDL to DL8GAM RR0+ FF6KDL>DL8GAM>RR0,P

Und da das Packet ja schon ankam, lautet die Antwort:

fm DL8GAM to FF6KDL RR1- DL8GAM>FF6KDL>RR1,F

Folgende Grundregel gilt hierbei:

das + oder P am Ende bedeutet "Poll", d. h. Wiederholung oder Nachfrage.

Ein +/P wird immer mit - bzw. F fuer "Final" beantwortet.

Ein ^ oder C (Command) bedeutet erstmalige Aussendung eines Info-Frames
und wird mit v bzw. R fuer "Ready" bestaetigt.

+ und -, ^ und v (bzw. P und F, sowie C und R) gehoeren also zusammen.

Ein Verbindungsaufbau wird immer gepollt, also korrekterweise
SABM+ (SABM,P). Die Antwort auf ein SABM lautet immer UA, also in diesem
Falle UA- (UA,F). Manche Spezialsoftware macht anstatt SABM+ auch SABM^.
Kein Problem, SABM^ wird mit UAv beantwortet. Das habe ich zwar
nur einmal gesehen bisher, aber die Gegenstation kommt auch mit
solchen eigentlich nicht protokollgerechten Anfragen klar.

Also der typische Verbindungsaufbau sieht so aus:

TNC: DC:
fm DL8GAM to FF6KDL ctl SABM+ DL8GAM>FF6KDL>SABM,P
fm FF6KDL to DL8GAM ctl UA- FF6KDL>DL8GAM>UA,F

Und schon steht die Verbindung. Nun koennen Informationen uebertragen werden.

Wenn alles glattgeht schickt mir FF6KDL ein Infoframe mit dem CTEXT.
Den lassen wir mal weg, es interessieren ja nur die Header:

fm FF6KDL to DL8GAM ctl I00^ pid F0
FF6KDL>DL8GAM>I00,C,F0:

Das wird beantwortet mit

fm DL8GAM to FF6KDL ctl RR1v
DL8GAM>FF6KDL>RR1,R

RR bedeutet uebrigens Receive Ready, die Station kann weitere Pakete
aufnehmen.

Nun schicke ich ein Infoframe zum Digi, zum Beispiel mit einem
Connectbefehl oder einem Digibefehl:

fm DL8GAM to FF6KDL ctl I10^ pid F0
DL8GAM>FF6KDL>I10,C,F0

Wieso aber I10 und nicht I00?

Bei Infoframes wird immer der Gegenstation mitgeteilt, bei welchem
Packet die eigene Station ist. Das ist die erste Ziffer. Und die
eigentliche Nummer des Paketes steht an zweiter Stelle, Packet
Nummer 0 zum Senden also, aber Packet Nummer 0 von der Gegenseite
kam schon an, als naechstes erwartet meine Station das Packet Nummer
1, das ist die Bedeutung von I10.

I57 bedeutet also, meine Station erwartet ein Packet mit der Nummer 5,
dieses Packet traegt die Nummer 7.

Durchnumeriert wird von 0 bis 7, anstatt 8 kommt wieder 0.
Das ist auch der Grund, warum an eine Gegenstation maximal 7
Infopakete auf einmal gesendet werden koennen. Die Gegenstation
koennte sonst nicht mehr unterscheiden, ob mit dem RR0 der
Empfang des achten bestaetigt oder die Wiederanforderung des
ersten gemeint ist.

Werden z. B. drei Infopakete empfangen, so muss nur das letzte
bestaetigt werden. Wird das letzte bestaetigt, bedeutet das
zwangslaeufig, dass die beiden anderen auch angekommen sind:

TNC: DC:
fm FF6KDL to DL8GAM ctl I11^ pid F0 FF6KDL>DL8GAM>I11,C,F0:
fm FF6KDL to DL8GAM ctl I12^ pid F0 FF6KDL>DL8GAM>I12,C,F0:
fm FF6KDL to DL8GAM ctl I13^ pid F0 FF6KDL>DL8GAM>I13,C,F0:
fm FF6KDL to DL8GAM ctl I14^ pid F0 FF6KDL>DL8GAM>I14,C,F0:

wird dann beantwortet mit:

fm DL8GAM to FF6KDL ctl RR5v DL8GAM>FF6KDL>RR5,R

FF6KDL wird mit Packet I15 fortfahren, sofern die Bestaetigung
auch ankam.

Kommt sie nicht an, fragt FF6KDL nach:

fm FF6KDL to DL8GAM ctl RR1+ FF6KDL>DL8GAM>RR1,P

Das bedeutet "Receive Ready, erwarte Packet Nummer 2 (habe 1 empfangen),
bei welcher Nummer bist Du?".

Die Antwort lautet:

fm DL8GAM to FF6KDL ctl RR5- DL8GAM>FF6KDL>RR5,F

und bedeutet "Receive Ready, erwarte Packet Nummer 5 (habe 4 empfangen)".

Dieses Spiel wiederholt sich so lange, bis FF6KDL entweder
die Bestaetigung empfaengt oder nach Ablauf des Retry-Zaehlers
die Verbindung trennt.

Aber wir lassen die Verbindung mal stehen... Es gibt ja noch
andere Statusmeldungen, richtig kompliziert wirds bei REJ.

Folgender Fall tritt ein:

FF6KDL schickt mir wieder einen Stoss Infopakete:

fm FF6KDL to DL8GAM ctl I15^ pid F0 FF6KDL>DL8GAM>I15,C,F0:
fm FF6KDL to DL8GAM ctl I17^ pid F0 FF6KDL>DL8GAM>I17,C,F0:
fm FF6KDL to DL8GAM ctl I10^ pid F0 FF6KDL>DL8GAM>I10,C,F0:

Wer genau hinsieht merkt, dass ein Packet fehlt in der Reihe.
Die Nummer 6 ist verlorengegangen, aber 7 und 0 kamen an.

Mein TNC antwortet: Digicom:
fm DL8GAM to FF6KDL ctl REJ6v DL8GAM>FF6KDL>REJ6,R

Bedeutet: das sechste Packet kam hier nicht an, bitte alles ab da
nochmal. REJ heisst REJECT, also Zurueckweisung eines Paketes,
weil nicht empfangen.

FF6KDL wird also die Nummern I16 I17 und I10 wiederholen.
Kommt das Packet 0 an, wird mit RR1v (RR1,R) bestaetigt.
Kommt zum Beispiel das siebte Packet nun nicht an, erfolgt ein
REJ7v (REJ7,F) und 7 und 0 werden wiederholt.
Kommt aber das sechste Packet nach einem REJ auch im zweiten
Versuch nicht an, passiert nichts! Mein TNC wartet naemlich
dann seelenruhig darauf, dass die Gegenstation pollt, in diesem
Falle mit dem bekannten RR1+ (RR1,P). Ein RR6- (RR6,F) wird dann
als Antwort gesendet und es geht weiter mit dem sechsten Frame.

Hier gilt eine spezielle Regel: Bei REJ werden nur die Pakete wiederholt,
die nicht ankamen. Es muessen mindestens zwei Pakete ausgesendet
worden sein. Wird das letzte Packet nicht empfangen, merkt das TNC das
nicht und sendet nicht REJ sondern RR. REJ wird nur gesendet,
wenn der TNC eine Luecke feststellt.
REJ wird fuer ein Packet nur einmal gesendet (Ausnahme: einige
KISS-Controller verfahren da anders). Kommt das Packet ein zweitesmal
nicht an, reagiert das TNC nicht mehr.

Muss die Gegenstation nach einem zweiten Versuch pollen, wird
Maxframe auf der Gegenseite wieder aufgefuellt.
Nehmen wir an, die Gegenseite hat Maxframe 3.

Das Packet Nummer 2 kommt nicht an. Es wird REJ gesendet. Pakete
Nummer 2 bis 3 werden wiederholt. Wieder kommt Nummer 2 nicht an.
Nun sendet mein TNC erstmal nicht, weil es nicht zweimal REJ
senden kann.
Die Gegenstation fragt nach einer Weile nach. Nun teilt meine
Station wieder mit, dass als naechstes Packet Nummer 2 erwartet
wird. Nun werden die Pakete Nummer 2 bis Nummer 4 gesendet,
also wieder drei Stueck. In dem Moment wo eine Station pollen
muss, wird der Framepuffer wieder auf die Maxframe-Zahl aufgefuellt,
sofern noch genuegend Pakete zur Sendung anliegen.

Muss die Gegenstation pollen, wird alles vergessen was vorher war.
Auch das Spiel REJ fuers zweite Packet koennte also wieder anfangen.
Allerdings nur einmal, ein zweitesmal wuerde mein TNC ja wieder
auf einen Poll warten...
Dies gilt fuer jeden Poll: wird erstmal gepollt, wird der Framepuffer
immer aufgefuellt, solange Vorrat reicht, also Daten zum Senden da sind.

Wenn ich also z. B. die Pakete 1 bis 3 zur Gegenstation schicke und
erhalte ein REJ1 zurueck, dann kam das erste Packet nicht an, aber
mindestens das zweite oder dritte Packet, vielleicht auch beide.

Kassiert man haeufig REJs fuers erste gerade gesendete Frame, kann
das zwei Ursachen haben:
entweder haut immer eine andere Station dazwischen oder der eigene
Sender hat Anlaufschwierigkeiten, z. B. weil die PLL einschwingen
muss oder weil die PA verspaetet zuschaltet. Was davon zutrifft
muss jeder selber herausfinden durch Beobachtung.

Natuerlich kann auch mein RX etwas traege sein und der Digi legt
recht schnell los, dann sende ich die REJs fuer das jeweils erste
Frame. Aber ein REJ kommt immer mal vor, solange sich das nicht
haeuft kein Grund zur Sorge. Einzelne Pakete koennen immer
verloren gehen.

Der Verbindungsabbau ist relativ einfach:

DISC bedeutet Disconnect. DISC+ (DISC,P) wird mit UA- (DM,F) beantwortet.
Hat eine Seite mal ein DISC empfangen ist die Verbindung weg.
Empfaengt die Station nun ein zweites DISC, weil z. B. das UA
nicht ankam, wird mit DM geantwortet. DM bedeutet Disconnect Mode,
Verbindung besteht nicht. Denn die Verbindung wird nach dem
ersten empfangenen DISC getrennt. Das Digicom sendet auch auf das
erste DISC ein DM; das AX25-Protokoll laesst beides zu.

Typisches Beispiel dafuer:

TNC: DC:
fm DL8GAM to FF6KDL ctl DISC+ DL8GAM>FF6KDL>DISC,P
- FF6KDL sendet hier UA, kommt aber nicht an bei mir... -
fm DL8GAM to FF6KDL ctl DISC+ DL8GAM>FF6KDL>DISC,P
fm FF6KDL to DL8GAM ctl DM- FF6KDL>DL8GAM>DM,F

Und nun weiss auch meine Station, dass die Trennung der Verbindung
auf der anderen Seite ankam.

Zusammenfassend:

TNC: DC:
Anfrage Antwort Anfrage Antwort

+ - P F
^ v C R
SABM UA SABM UA
DISC UA DISC DM
I^ RRv I,C RR,R
RR+ RR- RR,P RR,F

Aber es koennen noch andere (Un)Faelle auftreten:

Ein SABM wird mit DM beantwortet. Das TNC wertet das als BUSY, also
besetzt aus. Das kann passieren, wenn der Gegenstation die freien Kanaele
ausgegangen sind (kommt bei stark frequentierten Mailboxen schon oefter
vor) oder wenn sie keine Connects annehmen will (WA8-Befehl: Y 0).
In diesem Falle kommt eben keine Verbindung zustande.

Der Digi sendet RNR.
Fuer RNR gilt genau das gleiche wie fuer RR. Nur heisst RNR eben
Receive NOT Ready. Das passiert bei FlexNet gerne, wenn eine bestimmte
Anzahl Frames im Puffer ueberschritten ist. So schuetzt sich der
Digi davor, dass sein Speicher ueberlaeuft.
Ist das letzte zu sendende Frame meiner Seite mit RNR beantwortet
worden, so wartet mein TNC solange, bis wieder ein RR vom Digi kommt.

Das klassische Beispiel:

TNC: DC:
fm DL8GAM to FF6KDL ctl I31^ pid F0 DL8GAM>FF6KDL>I31,C,F0
fm DL8GAM to FF6KDL ctl I32^ pid F0 DL8GAM>FF6KDL>I32,C,F0
fm DL8GAM to FF6KDL ctl I33^ pid F0 DL8GAM>FF6KDL>I33,C,F0
fm DL8GAM to FF6KDL ctl I34^ pid F0 DL8GAM>FF6KDL>I34,C,F0

fm FF6KDL to DL8GAM ctl RR5v FF6KDL>DL8GAM>RR5,R

fm DL8GAM to FF6KDL ctl I35^ pid F0 DL8GAM>FF6KDL>I35,C,F0
fm DL8GAM to FF6KDL ctl I36^ pid F0 DL8GAM>FF6KDL>I36,C,F0
fm DL8GAM to FF6KDL ctl I37^ pid F0 DL8GAM>FF6KDL>I37,C,F0
fm DL8GAM to FF6KDL ctl I30^ pid F0 DL8GAM>FF6KDL>I30,C,F0

fm FF6KDL to DL8GAM ctl RNR1v FF6KDL>DL8GAM>RNR1,R

Und schon sendet mein TNC nichts mehr auf diesem Kanal.
Aber irgendwann wird der Digi ja wieder aufnahmebereit sein,
das teilt er mir dann so mit:

fm FF6KDL to DL8GAM ctl RR1^ FF6KDL>DL8GAM>RR1,C

Der einzige Fall in der Praxis, wo ein RR^ auftritt uebrigens...

Empfange ich das nun nicht, pollt der Digi mich an. Der Digi merkt
ja, ob von mir nach der Freigabe nun weitere Infoframes kommen, und
auf die wartet er erstmal. Wenn nichts kommt, wird mit RR+ gepollt
wie gehabt. Ist das RR^ verloren gegangen, so reagiert mein TNC
auf das RR+ und faengt sofort an, Daten zu senden, vorausgesetzt,
es sind noch welche da. Wenn nicht bleibt es bei dem RR- zur Bestaetigung
fuer das RR+. Die Bestaetigung RR- wird in jedem Fall gesendet, ob
nun von mir weitere Infoframes kommen oder nicht.

Wird ein RNR von der Gegenstation empfangen, obwohl nicht alle
zu sendenden Pakete bestaetigt worden sind, pollt mein TNC die
Gegenstation an und wartet auf das unvermeidliche RNR-. Sobald
das empfangen wurde, steckt das TNC die Pakete wieder in den Speicher
wo die Pakete liegen, die noch nicht "dran" waren und wartet schoen
brav aufs naechste RR. RNR ist zwingend, an eine Station die RNR
meldet koennen auf diesem Kanal keine weiteren Info-Frames
gesendet werden. Wenn ich aber einmal connected habe unter DL8GAM-1
und einmal unter DL8GAM-2 und fuer DL8GAM-2 kommt ein RNR, kann
DL8GAM-1 munter weitersenden. RNR gilt nur fuer den Kanal auf dem
es gesendet wurde, wie jedes Frame.

Ein Packet gibt es noch, das FRMR. Es bedeutet Frame Reject und ist was
Unangenehmes. FRMR signalisiert einen Protokollfehler. Ein Packet
wurde empfangen, welches nicht ins Protokoll passt.

Am haeufigsten passiert das beim Verbindungsaufbau, wenn man schonmal
"auf Vorrat" den ersten Befehl fuer den Digi eingetippt hat, bevor
der Connect steht.
Dann kann es passieren, dass der Digi ein UA sendet, aber das naechste
SABM schon zum Senden bereitlag.
Das sieht so aus:

TNC: DC:
fm DL8GAM to FF6KDL ctl SABM+ DL8GAM>FF6KDL>SABM,P
fm FF6KDL to DL8GAM ctl UA- FF6KDL>DL8GAM>UA,F
fm FF6KDL to DL8GAM ctl I00^ pid F0 FF6KDL>DL8GAM>I00,C,F0:
fm DL8GAM to FF6KDL ctl SABM+ DL8GAM>FF6KDL>SABM,P
fm DL8GAM to FF6KDL ctl I00^ pid F0 DL8GAM>FF6KDL>I00,C,F0
fm FF6KDL to DL8GAM ctl FRMRXXXXXXv FF6KDL>DL8GAM>FRMR,P:<XX><YY><ZZ>

Der Fehler hierbei liegt im SABM und folgenden Info-Frame, obwohl
der Digi noch kein UA senden konnte fuer das zweite SABM.
Das passiert oft dann, wenn man zu kurzes FRACK benutzt, oder
die Frequenz sehr stark belegt ist, so dass der Digi selber
kaum zum Antworten kommt (insbesondere auf Duplex-Digis).

Auch Framesammler auf der Gegenseite koennen zu FRMR fuehren, wenn
MAXFRAME waehrend eines Connects reduziert wurde und die Gegenstation
ploetzlich ein Packet bestaetigt, welches mein TNC schon "vergessen"
hat.

Auch Rufzeichenmissbrauch auf einem Digi kann zu FRMR fuehren; kein
Wunder wenn zwei TNCs unterschiedliche Sachen machen unter dem
selben Call...

FRMR ist das unglueckliche Ende einer Verbindung. Die WA8-Software
sendet auf FRMR sofort SABM, kommt das UA an, steht die Verbindung
auf beiden Seiten wieder. Dagegen wird DIGICOM hier DISConnecten.
Manch andere Software reagiert leider noch seltsamer, z.B. Pollen
ohne Unterlass, bis der Retry-Zaehler ablaeuft.

Alles bis hierher war protokolliert, also wird jedesmal eine Antwort
erwartet auf das was gesendet wurde.

Bei UI-Frames ist das nicht so. UI-Frames sind Unnumbered Information-
Pakete, ohne Nummer, also unprotokolliert.

Sie werden verwendet fuer Baken und fuer den FlexNet-Search.

Ueblicherweise werden sie an einen nicht vorhandenen Empfaenger gesendet.
Z. B. an CQ:

TNC: DC:
fm DL8GAM to CQ ctl UI+ DL8GAM>CQ>UI,P

Das Frame kann bis zu 256 Zeichen Text enthalten und beliebig oft
wiederholt werden.

Wird ein UI-Frame an einen Empfaenger gesandt (DL1XYZ) wird es mit
DM beantwortet werden, weil ja keine Verbindung besteht. In einer laufenden
Verbindung wird ein eingeschobenes UI-Frame an den selben Adressaten
je nach Software verschieden behandelt: Die WA8-Soft ignoriert das UI-Frame,
denn ein DM wuerde ja zum Abbruch der Verbindung fuehren.
Bei Superkiss 3.0 kann ein UI-Frame in einer laufenden
Verbindung einen Absturz des Rechners beim Empfaenger verursachen!
Der Fehler wurde in der Version 3.0a bereinigt.)
DIGICOM wird mit DM,F antworten und so die Verbindung auf der Gegenseite
abbrechen (und beim naechsten eigenen POLL auch ein DM bekommen).
FLEXNET beantwortet ein UI+ (UI,P) waehrend eines Connects mit
dem passenden RRx,R-Frame!

Die TheNet-Software sendet bei einem CQ-Befehl UI-Frames unter dem
Rufzeichen des Absenders mit CQ als Ziel-Adresse. Dabei wird die SSID
des Absenders aber 'umgedreht', damit keine Verwechslungen mit dem
eigentlichen Rufzeichen passieren.
Ein UI-Frame an den Adressaten CQ wird von zahlreichen Programmen
ausgewertet, bei SP z. B. erscheint ein Pop-Up-Fenster in dem Call
und QRG der rufenden Station erscheinen. SABMs an CQ werden hier nicht
ausgewertet, es muss ein UI-Frame sein...

FlexNet verwendet UI-Frames um eine Station ueber mehrere Digis zu
suchen (FIND-Befehl). Empfaengt der FlexNet-Digi ein DM von der
gesuchten Station, teilt sie es dem Absender mit (*** DL1XYZ found via
DB0XYZ). Als Inhalt des UI-Frames erscheint "FlexNet-Search". Naeheres
ist der FlexNet-Dokumentation zu entnehmen. Absolut verlaesslich ist
diese Methode nicht, da das DM ja unprotokolliert ist. Wenn es nicht
ankommt, ist es verloren. Es empfiehlt sich daher UI-Frames (und Find-
Befehle) mehrfach zu wiederholen um sicherzustellen, dass sie auch
ankamen. Wie im klassischen Funk, hi!

Gesendet werden UI-Frames auf dem Monitor-Kanal, der Adressat wird mit dem
Connectbefehl eingegeben. (Bei Superkiss und DIGICOM gibt es eine Option
UNPROTO, da ist es etwas anders, das Ergebnis sollte das selbe sein.)
Der Text wird einfach eingegeben und mit RETURN abgeschickt. Als
Absenderrufzeichen erscheint das angegebene Call fuer Kanal 0.

Bis hierhin war alles die Protokollversion 2. Es gibt eine etwas
altertuemlichere Version 1. Auf UKW in DL ist sie kaum mehr im Einsatz,
jedoch auf KW kann man sie noch bewundern.

Sie ist schnell erklaert: es fehlt das +-^v, d.h. es gibt KEIN
Polling (nachfrage bei ausstehenden Bestaetigungen). Es gibt nur SABM UA
RR RNR REJ DISC DM und FRMR. Infoframes werden solange wiederholt,
bis sie bestaetigt sind. Je schlechter eine Verbindung ist, desto
mehr ist die Version 1 der Version 2 unterlegen.

FlexNet akzeptiert keine Version 1-Connects, kann diese aber digipeaten.

Empfaengt mein TNC ein SABM in Version 1 (zu erkennen an dem
fehlenden "+" bzw ",P") wird es in Version 1 antworten und die Verbindung
darin abwickeln. Ein Wechsel der Protokollversion ist waehrend
des Connects nicht moeglich.

Kann eine Gegenstation keine Protokollversion 2, so wird sie mein
SABM+ (SABM,P) mit einem normalen UA (ohne -/F) beantworten. Und auch in
diesem Fall laeuft die Verbindung in der Version 1. Spitzenkandidat hierfuer
sind zahlreiche MSYS-Nodes bzw. -BBS auf Kurzwelle.

Soweit also mal ein kurzer Ueberblick auf das verwendete Protokoll.
Korrekturen und Ergaenzungen bitte ich mir mitzuteilen, ich werde
den Text dann entsprechend ueberarbeiten und neu einspielen.
Der vorhandene Text wurde von mir, DF3VI und DL1GRA mehrfach redigiert.
Einen besonderen Dank moechte ich an Patrick, DF3VI richten, der
die TNC-Diktion in Digicom "uebersetzt" und einige Sachen ergaenzt
hat. Auch Rainer, DL1GRA hat kraeftig mitgeholfen.

Aber die Materie ist kompliziert, der ein oder andere Schnitzer
kann immer noch drin sein. Alle Angaben sind daher ohne Gewaehr...

vy 73 de Urs, DL8GAM @ DB0FRB

(AX25) DL1RNN de DB0BQ>
DISCONNECTED fm DB0BQ - 10.11.91 18:00:40

CONNECTED to DB0AX - 10.11.91 18:00:59
TheNetNode Digipeater Paderborn, 438.150 MHz Simplex
Betreiber: Arbeitsgemeinschaft TEUTO<>LINK
* HELP TEUTO * HELP ANMELD *
DL1RNN de DB0AX >c pbbox

DISCONNECTED fm DB0AX - 10.11.91 18:01:35

CONNECTED to DB0AX - 10.11.91 18:01:39
TheNetNode Digipeater Paderborn, 438.150 MHz Simplex
Betreiber: Arbeitsgemeinschaft TEUTO<>LINK
* HELP TEUTO * HELP ANMELD *
DL1RNN de DB0AX >c db0bq
PB:DB0AX> Connected to DB0BQ

Mailbox Paderborn - 438,025 MHz - Login: 10.11.91 19:22 UTC Logins: 3

Hallo Lutz, Dein letztes Logout mit QUIT war am 10.11.91 09:29 UTC

Keine Post fuer Dich da.

() DL1RNN de DB0BQ>l contest

Rubrik: CONTEST
Nr. Call Datum Zeit Bytes Titel

11 DL1VJ 10.11.91 15:31 727 JY IN WWDXC-CW

(CONTEST) DL1RNN de DB0BQ>l contest 1-

Rubrik: CONTEST
Nr. Call Datum Zeit Bytes Titel

1 DL1SAN 31.10.91 11:08 1654 dl0ul/p im Marconi Contest
2 DD2FX 31.10.91 14:02 24086 CQ World Wide Contest
3 DF0FKB 31.10.91 14:33 2113 ERGEBNIS SEP.91 UKW
4 DL1EK 01.11.91 01:57 1059 CT3M during CQ-WW-DX CW 1991
5 HB9ZZ 01.11.91 12:12 1171 HE7DDO im Marconi-Contest
6 OK2FD 01.11.91 14:07 6957 OKDX Contest 9/10 Nov
7 DJ6HC 03.11.91 18:43 2680 **CQ M DX-Contest '90 Ergebnisse / Diplome *
8 DJ6HC 04.11.91 06:57 3121 **CQ M DX-Contest '90 Ergebnisse / Diplome *
9 OE1MCU 06.11.91 04:13 3364 ALL-OE-DX-CONTEST 160m
10 DL2DN 07.11.91 11:45 4999 WAE-DX-Contest CW 91 (DL-results)
11 DL1VJ 10.11.91 15:31 727 JY IN WWDXC-CW

(CONTEST) DL1RNN de DB0BQ>