









                          NORD><LINK



                  terrestrische Anwendung des
                      PACSAT-Protokolles






           MANUAL fr USER, SYSOPs und Programmierer

I.  bersicht:


II. Anwender-Teil:
    1.  Allgemeine berlegungen zum Mail-Broadcasts als Er-
gnzung zu einem User-Einstieg
    2.  Beschreibung des PACSAT-Protokolls bei terristrischer
Anwendung
    3.  PACSAT in der Praxis


III.SYSOP-Teil:
    1.  Nachrstung von TheNetNode-Digipeatern mit PACSAT
    2.  Betrieb von PACSAT und Einstieg auf der selben QRG


IV. Programmierer-Teil:
    1.  AX.25 als Trgerprotokoll fr PACSAT-Broadcasts
    2.  PACSAT File-IDentifier
    3.  Aufbau eines PACSAT-Datenframes
    4.  Der PACSAT Nachrichten-Header
    5.  PACSAT MANDATORY HEADER
    6.  PACSAT EXTENDED HEADER
    7.  PACSAT OPTIONAL HEADER

Anhnge:
    A.  Konstanten (Auszug)
    B.  Packverfahren
    C.  CRC-Routinen






Das hier beschriebene Protokoll entspricht der aktuellen
Version. nderungen und Irrtum vorbehalten. Eine Auflistung der
vorkommenden Markenzeichen erspare ich mir.



Diese Dokumentation entstand mit der freundlichen Untersttzung
von DL9HCJ/Matthias, DL5HBF/Ulli, DL9GYA/Roland und DL2LAY/
Kurt. Fragen, Korrekturen, Ergnzungsvorschlge bitte an:

                    DB7KG @ DB0HRO.#MVP.DEU.EU
                    Andreas Gal
                    Dorfstae 34b
                    23617 Stockelsdorf
                (oder an eine unserer NORD><LINK
Dienststellen :-) )
II.1  Allgemeine berlegungen zum Mail-Broadcasts als Ergnzung
zu einem User-Einstieg

Beobachtet  man  eine  Zeit  lang sorgfltig  einen  beliebigen
Packet-Radio  Netzeinstieg, fllt schnell auf,  das  der  Digi-
peater  auf  seinem  Einstieg mit sehr hoher Redundanz  sendet,
d.h.   die  selben  Daten  (Nachrichten)  werden  von  mehreren
Benutzern  abgerufen  und  dadurch mehrfach  ausgesendet.  Dies
fhrt  zu  einer  Verschwendung  der  zur  Verfgung  stehenden
Sendekapazitt.  Eigentlich  wrde  es  ausreichen,  wenn   EIN
Benutzer  eine  Nachricht abruft und alle  anderen,  die  diese
Nachricht   auch   haben   mchten,  diese   Nachricht   passiv
mitschreiben.  Dies ist leider nur mit sehr wenigen  Programmen
mglich  (z.B.  DigiPoint auf dem ATARI), so da diese  Methode
zumeist  mit  einem  erheblichen  Aufwand  verbunden  ist.  Ein
weiterer  Nachteil  ist die fehlende Fehlersicherheit,  die  zu
Datenverluten/Verflschungen fhren kann.  Auerdem  ist  nach
dem   Mitschreiben   von  Hand  zumeist  eine   Nachbearbeitung
notwendig.
Auf  Packet-Radion-Einstiegen, wo die Sendezeit besonders knapp
ist,  z.B. PACket-SATelitten, wurde von Anfang an ein Verfahren
zum   Nachrichtenaustausch  gewhlt,  das  ein   100%   fehler-
gesichertes passives Mitschreiben ermglicht. Alle Nachrichten,
die   der   Satellit  aussendet,  sind  "an  alle"   adressiert
(Broadcast),  werden  also bei jeder Station  aufgenommen.  Man
kann  dann  im  nachhinein entscheiden  ob  man  die  Nachricht
behalten  mchte oder nicht. Dadurch wird vermieden, die  selbe
Nachricht mehrmals auszusenden. Bei den immer weiter steigenden
Datenmengen auf den Einstiegen ist ein Umstieg auf ein  solches
BROADCAST-Protokoll auch bei PR-Einstiegen sinnvoll.

II.2  Beschreibung  des  PACSAT-Protokolls  bei  terrestrischer
Anwendung

Um  einerseits  auf die Erfahrung, aber auch  auf  die  bereits
vorhandenen  Programme  zurckgreifen  zu  knnen,   hat   sich
NORD><LINK  entschieden,  das  bei den  Packet-Radio-Satelliten
bliche   "PACSAT-Protokoll"  auch   fr   den   terrestrischen
Broadcast  zu  verwenden,  d.h. man kann  zur  Dekodierung  der
Nachrichtenbroadcasts  eines  TheNetNode-Digipeaters  auf   die
selbe  Software zurckgreifen, wie man sie fr den  Satelliten-
betrieb  benutzt. Als Beispiel sei das Programm "WISP" genannt,
das durch die AMSAT Vertrieben wird.
Da   die  TheNetNode-Broadcastsoftware  aber  teilweise  andere
Grundbedingungen hat, muten einige Modifikationen  am  PACSAT-
Ablauf  vorgenommen  werden. Satelliten  senden  in  der  Regel
vollduplex,  die meisten (alle?) Digipeater aber  simplex  oder
echoduplex. Somit ist es beim Satelliten-Betrieb mglich, Daten
an die Box zu senden. Dies ist bei der terrestrischen Anwendung
nicht  mglich, da der Digipeater dauersendet und  nicht  hren
kann.  Auch ein "REJECT" wie beim Satelliten-Betrieb ist  nicht
mglich,  aber auch nicht ntig. Erstens treten kaum  Strungen
auf  und  andererseits kann der Digipeater  durch  seine  nicht
eingeschrnkte  Hrbarkeitszeit erheblich  grere  Datenmengen
umsetzen  als ein Satellit und somit die Fehlerkorrektur  durch
Mehrfachaussenden  der  Nachricht erreichen.  Fr  den  PACSAT-
Betrieb  wird mindestens 9600 Baud bertragungsrate  empfohlen.
Daraus ergibt sich etwa eine effektive Datenrate von 800  Bytes
/ s, somit etwa 2.8MB pro Stunde und 67MB am Tag. Umschalt- und
Wartezeiten  wie  bei  Einstiegen  entfallen  und  erhhen  die
effektive Datenrate um das 10-15fache !
Pro  Tag  fallen in DL etwa 200 neue Info-Mails an. Der  Knoten
bentigt  je nach Mailumfang etwa 10 Minuten um die  200  Mails
auszusenden. Damit man als Benutzer nicht 24 Stunden am Tag auf
der   Digipeater-QRG  lauschen  mu,  werden  die  letzten  200
Nachrichten  stndig wiederholt. Alle 2 Nachrichten  wird  eine
Nachricht aus dem gesammt-Nachrichtenvolumen der letzten  Tage,
Monate,   Jahre   (je   nach  Plattengre   des   Digipeaters)
ausgesendet. Somit kann ein Benutzer durch kurzzeitiges zuhren
(20-30  Minuten) die neuen Nachrichten mitschreiben oder  durch
lngeres   Mitschreiben  noch  mehr  interessanter  Nachrichten
bekommen.
Das  Broadcast-Prinzip beseitigt die Benachteiligung  schwacher
Stationen, die von "Grofunkstellen" plattgebgelt werden. Auch
SWLs knnen problemlos dem Packetgeschehen folgen.

II.3 PACSAT in der Praxis

Die  meisten  PACSAT-Broadcast-"Ausgnge"  (Einstieg  wre  das
falsche Wort) werden mit 9600 Baud ihre Daten senden, d.h.  man
bentigt ein 9600 Baud Modem nach G3RUH/DF9IC. Da man nicht  zu
senden braucht, ist nahezu jeder 70cm TRX geeignet, selbst PLL-
Handys,  die  fr den regulren 9600 Baud Betrieb  wegen  ihrer
schlechten Sendeeigenschaften unbrauchbar sind.
Die Dekodierung der PACSAT-Aussendung geht vollautomatisch ohne
zutun  des Benutzers. PC-Anwender knnen mit dem Programm  WISP
die  Nachrichten unter Windows (auch im Hintergrund) empfangen.
Durch  das  "Last-In-First-Out"  kann  man  durch  kurzzeitiges
zuhren  bereits die aktuellsten Nachrichten mitschreiben.  Fr
den  ATARI  ermglicht das Programm "DigiPoint" die Dekodierung
der PACSAT-Aussendungen.

III.1 Nachrstung von TheNetNode-Digipeatern mit PACSAT

Um  den  Umstieg auf PACSAT zu erleichtern, wurde  der  PACSAT-
Server  in die Digipeater-Software integriert. Dadurch bentigt
man  keine  weitere Rechnerhardware, als eine aureichend  gro
dimensionierte  Festplatte.  Der  PACSAT-Server  ist  Standard-
Bestandteil der TNN-Software ab Version 1.55. Damit der  Server
automatisch alle Nachrichten aus dem Netz erhlt,  mu  er  bei
EINER  Box  in  der nhe an den S&F angebunden werden.  In  der
Regel ist eine Wartung des PACSAT-Servers durch den Sysop nicht
ntig.
10  neue  QRGs  im 70cm-ISM-Bereich wurden vom BUS-Referat  fr
Broadcast-Ausgnge   bereitgestellt.  Sie   knnen   mit   ent-
sprechendem  Filteraufwand parallel zu einem  vorhandenen  70cm
Einstieg  im  oberen  Bandbereich benutzt  werden.  Der  Server
macht,  sofern  nicht  anders konfiguriert,  auf  der  Ausgabe-
frequenz Dauertastung, d.h. der TRX ist entsprechend zu  khlen
und  der  Hardware-Watchdog des Modems auer Betrieb zu setzen.
Es  ist  anzumerken, das eine 9600 Baud (synkron)  Dauertastung
einen  Datenflu  auf der Tokenring-Seite (asynkron)  von  etwa
14000  Baud  erfordert. Ein 19k2 Tokenring ist dann  mit  einem
weiteren  Einstieg bereits berlastet. Generell ist fr  PACSAT
VANESSA unbedingt zu empfehlen.

III.2 Betrieb von PACSAT und Einstieg auf der selben QRG

Mchte man die Mglichkeiten des Broadcast testen, kann man auf
einem  vorhanden Einstieg PACSAT-Broadcasts hinzuschalten.  Das
Timing ist dabei frei whlbar. ber die zeitgesteuerten Batches
lt  sich der PACSAT-Broadcast auch zu den Hauptbetriebszeiten
abschalten  usw. Im Interesse der Bandbelegung  im  ISM-Bereich
ist eine eigene Broadcast-Frequenz vorzuziehen.

IV.1 AX.25 als Trgerprotokoll fr PACSAT-Broadcasts

Damit  PACSAT  strungsfrei parallel zu normalen  Packet  Radio
betrieben   werden  kann,  werden  PACSAT   Frames   in   AX.25
Trgerframes  verpackt.  Es  sind UI  (unnumbered  information)
Frames mit der PID (protocoll Identifier) 0xBB gerichtet an das
Zielrufzeichen   QST-1.   Das   Absender-Rufzeichen   ist   das
Rufzeichen des Satelliten/des Digipeaters.

fm DB0HRO to QST-1 ctl UI^ pid BB
<PACSAT-Dateninhalt>

Bei  der  Erkennung von PACSAT Frames ist also auf die richtige
PID  und auf das Zielrufzeichen QST-1 zu achten. Da die PID von
der  AX.25  PID F0 abweicht, ist das Aussenden von  PACSAT  mit
einem TNC ohne nderungen im Hostmode NICHT MGLICH.

IV.2 PACSAT File-IDentifier

Da  die  Lnge  des Datenfeldes bei den meisten  TNCs  auf  256
begrenzt  ist, mssen fast alle Nachrichten in mehrere  PACSAT-
Datenframes  zerlegt  werden. Damit  ein  Datenframe  eindeutig
einer  Nachricht zugeordnet werden kann, erhlt jede  Nachricht
eine  FID  (FileID).  Diese FID ist ein 4-Byte  LONG,  der  der
Nachricht zugeordnet wird. Jeder PACSAT-Server vergibt eine FID
nur ein einziges mal, d.h. es kann nicht zu Kollisionen kommen.
Das  Dekodierprogramm speichert die FIDs alle Nachrichten,  die
schon  dekodiert  worden sind und vermeidet so einen  doppelten
Empfang.  Dabei  ist zu beachten, das die  FID  nur  fr  EINEN
PACSAT-Server  eindeutig ist, sendet  z.B.  DB0HRO  und  DB0LUB
beide  PACSAT  aus,  dann  kann  die  FID  1234567  bei  beiden
unterschiedliche  Nachrichten bezeichnen, das  Dekodierprogramm
mu die Aussendungen also nach Absenderrufzeichen trennen.
IV.3 Aufbau eines PACSAT-Datenframes

Jedes  Datenframe,  das ausgesendet wird, erhlt  einen  Frame-
Header. Die dort enthaltenen Informationen sind variabel.  Hier
wird nur auf die von TNN benutzte Form eingegangen.
Jedes PACSAT-Frame enthlt am Anfang einen 9 Bytes Header, dann
eine  variable  Datenmenge und am Ende noch 2 CRC  (Checksumme)
Bytes. Der Header ist folgendermaen aufgebaut:

Name    Lnge    Funktion
<FLAGS>   1 Byte   bestimmt den Typ des Headers, bei TNN  steht
hier immer ein PF_O, das das Vorhandensein
                eines OFFSET-Feldes anzeigt
<FID>    4 Bytes  PACSAT-File Identifier (s. IV.2)
<TYPE>    1 Byte    Typ der Nachricht, bei TNN (z.Z.) 0x00
<OFFSET>  3  Bytes    Offset,  an der  die  Datenbytes  in  das
Empfangsfile zu schreiben sind

Durch  den  3-Byte Offset ist die maximale Filegre 16MB,  was
auch  fr  knftige Baudraten ausreichen sollte. Hat  man  alle
Teile einer Nachricht empfangen, dann erhlt man ein File,  das
zuerst  einen  binren Nachrichtenheader enthlt  und  dann  im
ungepackten ASCII-Format die eigentliche Nachricht. Die  letzen
beiden   Bytes  im  Trgerframe  bilden  eine  CRC   ber   den
Frameheader  und die Datenbytes. Sie werden nach dem  Verfahren
im Anhang berechnet.

IV.4 Der PACSAT Nachrichtenheader
(freie  bersetzung  der  englischen Originaldokumentation  von
NK6K)

Alle  Elemente des Nachrichtenheaders (file header)  haben  das
selbe Format:

<ID><Lnge>[<Daten> . . . ]

IV.4.1 <ID>-Feld
      2-Byte  Integer,  der  das  Element  identifieziert,  ist
Bit   15   gesetzt,   handelt  es  sich   um   eine   benutzer-
definiertes Headerfeld

     Die <ID> wird wie alle mehrbyte-Integers mit dem LSB (last
significant byte) zuerst bertragen, also so wieder der    IBM-
PC   das   standardmig  tut.  Alle  Motorolla-CPUs   notieren
genau umgekehrt.

IV.4.2 <Lnge>-Feld

     Dieses Feld ist ein unsigned char und gibt die Anzahl  der
Datenbytes  in dem Headerelement an. Unbekannte Header-elemente
knnen so bergangen werden. Auch Header-   elemente, die  eine
feste Lnge haben, haben das length-   Feld.

IV.4.3 <Daten>-Feld

     Hier  sind die Daten des Feldes enthalten, sie  knnen  je
nach Art des Headerelementes unterschiedliche Formate haben.

Der   PACSAT   Nachrichtenheader   wird   immer   unkomprimiert
bertragen,  selbst wenn die Nachricht selber komprimiert  sein
sollte (bei TheNetNode z.Z. immer unkomprimierter ASCII-Text).

Das Ende des Headers ist durch ein Element mit der ID 0x0000 (2
Bytes) und der Lnge 0 gekennzeichnet, also die Bytefolge  0x00
0x00 0x00.

IV.5 PACSAT MANDATORY HEADER

Der  "MANDATORY  HEADER"  mu  bei  allen  PACSAT  Aussendungen
enthalten   sein.  Er  wird  durch  die  Bytefolge  0xaa   0x55
eingeleitet, danach folgen die Header-Elemente in aufsteigender
Reihenfolge ihrer Ids.

IV.5.1 file_number
    ID          :   0x01
    Lnge        :   4
    Daten        :   unsigned long file_number

    Hier wird der File-Identifier bertragen.

IV.5.2 file_name
    ID          :   0x02
    Lnge        :   8
    Daten        :   char file_name[8];

     <file_name>  ist der Filename ohne Extention  nach  rechts
mit Spaces (0x20) aufgefllt, wenn unbekannt dann mssen   hier
8  Spaces stehen, die Empfangsstation whlt dann einen  eigenen
Namen. [TheNetNode bertrgt hier 8 Spaces]

IV.5.3 file_ext
    ID          :   0x03
    Lnge        :   3
    Daten        :   char file_ext[3];

    Hier gilt das selbe wie fr file_name.
    [TheNetNode bertrgt hier 3 Spaces]

IV.5.4 file_size
    ID          :   0x04
    Lnge        :   4
    Daten        :   unsigned long file_size;

      <file_size>  bezeichnet  die  Gesammtlnge   des   Files,
inclusiv   Header,  die  Magic-Bytes  (0xaa   0x55)   und   der
Nachricht.

IV.5.5 create_time
    ID          :   0x05
    Lnge        :   4
    Daten        :   unsigned long create_time;

     Datum,  wann die Datei erstellt wurde. Die Angabe  erfolgt
in  Unix-Time,  also die Sekunden, die seit dem  1.  Jan.  1970
vergangen sind.
     [TheNetNode bertrgt hier die Uhrzeit, wann die Nachricht
ber den Store&Forward empfangen wurde]

IV.5.6 last_modified_time
    ID          :   0x06
    Lnge        :   4
    Daten        :   unsigned long last_modified_time;

     [TheNetNode bertrgt hier die Uhrzeit, wann die Nachricht
ber den S&F empfangen wurde.

IV.5.7 seu_flag
    ID          :   0x07
    Lnge        :   1
    Daten        :   unsingned char seu_flag;

    [Bei terristrischer Anwendung ist dieses Flag immer 0]

IV.5.8 file_type
    ID          :   0x08
    Lnge        :   1
    Daten        :   unsigned char file_type;

     [TheNetNode  verwendet  momentan  nur  Typ  0x00]

IV.5.9 body_checksum
    ID          :   0x09
    Lnge        :   2
    Daten        :   unsigned int body_checksum;

      body_checksum  ist  die  16-Bit  Summe  aller  Bytes  des
bertragenen Files ohne den Header (also nur die Nachricht).

IV.5.10 header_checksum
    ID          :   0x0a
    Lnge        :   2
    Daten        :   unsigned int header_checksum;

    wie body_checksum, aber ber alle Bytes des Headers.

IV.5.11 body_offset
    ID          :   0x0b
    Lnge        :   2
    Daten        :   unsigned int body_offset

     gibt den Offset des 1. Bytes des bertragen Files an, also
somit die Lnge des Headers. Das File wird direkt hinter    dem
Header bertragen.

IV.6 PACSAT EXTENDED HEADER

Der "EXTENDED HEADER" beinhaltet weitere Informationen ber die
ausgesendete  Nachricht. Einige Elemente sind fr  den  terris-
trischen Betrieb uninteressant und haben nur Dummy-Funktion.
Sie sind durch ein * gekennzeichnet.

IV.6.1 Source
ID          :   0x10
Lnge        :   verschieden
Daten        :   char source[];

Dieses Feld bezeichnet den Absender im ASCII-Format.

IV.6.2 ax25_uploader*
ID          :   0x11
Lnge        :   6
Daten        :   char ax25_uploader[6];

Dieses  Feld  bestimmt  das Rufzeichen  der  Station,  die  die
Nachricht gespeichert hat. [bei terristrischer Anwendung stehen
hier 6 Leerzeichen]

IV.6.3 upload_time*
ID          :   0x12
Lnge        :   4
Daten        :   unsigned long upload_time;

Dieses Feld gibt die Uhrzeit des Uploads einer Nachricht in den
Satelitten an. [Bei TheNetNode wird wieder die Empfangszeit aus
dem S&F eingetragen]

IV.6.4 download_count*
ID          :   0x13
Lnge        :   1
Daten        :   unsigned char download_count;

Dieses   Feld   enthlt  die  Anzahl  der  Aussendungen   einer
Nachricht. [Bei TheNetNode ist dieses Feld immer 0]

IV.6.4 destination
ID          :   0x14
Lnge        :   verschieden
Daten        :   char destination[];
Dieses Feld bestimmt die Zieladresse. [TheNetNode bergibt hier
die  hierarchische Routingadresse, z.B. DB7KG @ DB0HRO oder IBM
@ DL]

IV.6.5 ax25_downloader*
ID          :   0x15
Lnge        :   6
Daten        :   char ax25_downloader[6];

Dieses  Feld  beinhaltet das Rufzeichen der  Station,  die  die
Nachricht  angefordert hat. [Bei TheNetNode werden  Nachrichten
nach  einem festen Zeitplan gesendet, nicht nach Requests, hier
stehen also wieder nut 6 Spaces]

IV.6.6 download_time
ID          :   0x16
Lnge        :   4
Daten        :   unsigned long download_time

Dieses  Feld  bestimmt die Zeit wann die Nachricht  erfolgreich
empfangen.  [TheNetNode setzt hier die  Uhrzeit  an,  wann  die
Aussendung des Files begannt]

IV.6.7 expire_time
ID          :   0x17
Lnge        :   4
Daten        :   unsigned long expire_time

Dieses  Feld  enthlt  die  Uhrzeit/das  Datum  wann  das  File
"ausluft" und gelscht werden soll. [Aus diesem Feld kann  die
Lifetime   berechnet  werden:  (expire_time  -  jetzt_zeit)   /
sekunden_pro_tag]

IV.6.8 priority*
ID          :   0x18
Lnge        :   1
Daten        :   unsigned char priority

[Dieses Feld beinhaltet bei terristrischer Anwendung immer 0]

IV.7 PACSAT OPTIONAL HEADER

Diese  Headerelemente sind alle optional, d.h.  sie  knnen  in
beliebiger   Reihenfolge  auftreten  und  mssen   nicht   alle
vorhanden  sein.  Es  werden  nur die  fr  den  terristrischen
Gebrauch sinnvollen Elemente beschrieben.


IV.7.1 compression_type
ID          :   0x19
Lnge        :   1
Daten        :   unsigned char compression_type;
Die  bertragene  Nachricht  kann  komprimiert  werden  um  die
bertragungskapazitt  zu  erhhen.  Siehe   Anhang   fr   die
definierten Packverfahren. [Dies wird z.Z. von TheNetNode  noch
nicht untersttzt, das Packverfahren ist immer 0 und somit aus]

IV.7.2 bulletin_id_number
ID          :   0x21
Lnge        :   verschieden
Daten        :   char bid[];

Die  Bulletin-ID der Nachricht. Bei User-Mails  eventuell  auch
nicht angegeben.

IV.7.3 title
ID          :   0x22
Lnge        :   verschieden
Daten        :   char title[];

ASCII-Title der Nachricht.

IV.7.4 user_file_name
ID          :   0x26
Lnge        :   verschieden
Daten        :   char user_file_name[];

Name  des  Files  beim Absender. [wird gesetzt ist  aber  nicht
weiter von Bedeutung]
Anhang A. Konstanten (Auszug)

/* Frame-Header Flags */
#define    PF_O                            2

/* Header ID's of mandatory Headers */
#define    PH_HEADER_END                   0
#define    PH_FILE_NUMBER                  1
#define    PH_FILE_NAME                    2
#define    PH_FILE_EXT                     3
#define    PH_FILE_SIZE                    4
#define    PH_CREATE_TIME                  5
#define    PH_LAST_MODIFIED_TIME           6
#define    PH_SEU_FLAG                     7
#define    PH_FILE_TYPE                    8
#define    PH_BODY_CHECKSUM                9
#define    PH_HEADER_CHECKSUM              10
#define    PH_BODY_OFFSET                  11

/* Header ID's of extended Headers */
#define    PH_SOURCE                       16
#define    PH_AX25_UPLOADER                17
#define    PH_UPLOAD_TIME                  18
#define    PH_DOWNLOAD_COUNT               19
#define    PH_DESTINATION                  20
#define    PH_AX25_DOWNLOADER              21
#define    PH_DOWNLOAD_TIME                22
#define    PH_EXPIRE_TIME                  23
#define    PH_PRIORITY                     24

/* Header ID's of optional Headers */
#define    PH_COMPRESSION_TYPE             32
#define    PH_BULLETIN_ID_NUMBER           34
#define    PH_TITLE                        35
#define    PH_USER_FILE_NAME               39

Anhang B. Packverfahren

0x00    unkomprimiert
0x01    komprimiert mit PKARC*
0x02    komprimiert mit PKZIP*

[* wird von TNN nicht untersttzt]

Anhang C. CRC-Routine

/* CRC fr ein Byte verrechnen */
unsigned int gen_crc(unsigned int crc, char data) {

    unsigned int y;

    crc ^= ((unsigned int)data) << 8;
    for(y = 0; y < 8; y++)
         if( crc & 0x8000)
             crc = (crc << 1) ^ 0x1021;
         else
              crc <<= 1;
    return(crc);

}

/* CRC eines Frames berprfen */
void ckcrc(char *frame, int len) {

    unsigned int crc = 0;
    int x;

    for (x = 0; x < len-2; x++)
        crc = gen_crc(crc, frame[x]);
    crc = gen_crc(crc, frame[x+1]); /* 1. CRC Byte */
    if (gen_crc(crc, frame[x+2]))
        printf("CRC Error\n");
}


Statt dem langsamen Bit-Verfahren kann man auch ber Tabellen
arbeiten, sie knnen dem TheNetNode Source-Code entnommen
werden.

