,---------[ teledat.sourceforge.net ]----------
| Autor: Felix Schwarz <felix at schwarz-online.org>
| Webseite: teledat.sourceforge.net
| Lizenz: GNU Free Documentation License 1.1 oder neuere (s.u.)
|
|--------- Changelog ---------
|
| 20.07.03  fs	Anpassung der Protokollnummerierung (v3.0 und v3.1)
| 15.03.03  fs	CRC gefunden
| 14.03.03  fs	kleinere Info zu falschen CRCs
| 17.10.02  fs	neue Informationen zum Aufbau des Befehlsbytes
| 16.10.02  fs	Anpassungen bez. Escaping
| 03.10.02  fs	Datei erstellt
|
`---------

--------------------------------------------------------------------------------
Im folgenden ist das von mir so getaufte "v3.1"-Protokoll allgemein beschrieben. Die
konkreten Befehlssequenzen sind allerdings in request_v31.txt beschrieben.

[allgemeine Eigenschaften]

Das v3.1-Protokoll wird von AVM zumindest zur Konfiguration der Telefonanlagen
verwendet. Obwohl einzelne Stellen an bekannte Protokolle wie X.75 erinnern,
scheint es doch in weiten Teilen proprietär zu sein. Es ist eine Weiterentwicklung
des z.B. in der Fritz!X PC v1 verwendeten v3.0-Protokolls.

Das Protokoll ist verbindungslos. Wenn es ohne weitere Protokolle wie
v2.1 zur Transportsicherung verwendet wird, besteht keine dauerhafte Verbindung
zur Anlage, die entspr. PC-LED leuchtet in diesem Fall auch nicht.

Wenn bei Windows kein CAPI-Treiber installiert ist, verwendet AVM zur Konfiguration
nur das v3.1-Protokoll, ansonsten "v3 over v2".




[Aufbau der Datenpakete]

Die einzelnen Datenpakete beginnen und enden jeweils mit dem Byte 0x7e, die
transportierten Inhalte werden durch eine 16 Bit Prüfsumme vor
Übertragungsfehlern gesichert. Der Algorithmus ähnelt dem aus RFC 1331, wurde
aber von AVM leicht abgewandelt. Besonderer Dank für die Analyse geht hier
an Bob Mathews und David Wagner sowie alle freundlichen Helfer aus sci.crypt.

Wenn die Anlage im reinen v3-Protokoll läuft und ein verfälschtes Datenpaket
erhält, reagiert sie überhaupt nicht, d.h. verwirft dieses Paket einfach.
Ich vermute mal, dass im "v3 over v2"-Betrieb eine Fehlermeldung zurückkommen
wird.


Um die eindeutige Erkennung der Datenpakete zu gewährleisten, müssen mehrere
Zeichen innerhalb der Paket-Grenzen maskiert werden. Auch die Prüfsumme muss
ggf. maskiert werden. Dies gilt allerdings nur, falls reines v3 verwendet
wird. Bei "v3 over v2" findet auf der v3-Ebene keine Maskierung statt! [1]

	0x7d -> 0x7d 0x5d
	0x7e -> 0x7d 0x5e
	0x11 -> 0x7d 0x31
	0x13 -> 0x7d 0x33

ES könnte noch andere Ersetzungen geben, z.B. vermuten wir noch folgende:
	0x91 -> 0x7d 0xb1

Wichtig ist auch die Reihenfolge der Ersetzungen:
	o Zuerst wird die Prüfsumme gebildet bzw. überprüft (die Daten sind also
	  noch nicht maskiert bzw. (bei empfangenen Daten) immer noch maskiert).
	o Bei zu versendenden Daten werden jetzt die Maskierungen in der oben
	  beschriebenen Reihenfolge vorgenommen. Empfangene Daten werden
	  demaskiert, in dem man die Ersetzungen genau umgekehrt (also von
	  unten nach oben) durchführt.

Ein v3-Request hat also grundsätzlich immer folgendes Format:
	0x7e   0xff   (Befehlsbyte)   (Daten)   (16 Bit CRC)   0x7e
Das Befehlsbyte gibt an, wie die folgenden Daten überhaupt zu interpretieren sind.

Eine Antwort im v3-Protokoll ist nur leicht verändert:
	0x7e   0xff   (Antwortbyte)   0x00   (Daten)   (16 Bit CRC)   0x7e
Das Antwortbyte entspricht dem Befehlsbyte, jedoch ist das Bit 6 gesetzt, sprich
das Befehlsbyte um 0x40 (oder 64 im Dezimalsystem) erhöht.



[ Aufbau des Befehlsbytes ]

  7   6   5   4   3   2   1   0
  ^   ^           ------------- für den Befehlscode genutzt
  |   Antwortbit: Gesetzt, wenn dies eine Antwort der Anlage ist
  | Speicherbit: Gesetzt, wenn Daten in der Anlage gespeichert werden sollen

--------------------------------------------------------------------------------


[1] Aus folgendem Datenfragment schließe ich, dass es keine Escapings bei
"v3 over v2" gibt:
<-7E C0 7D 5E FF 01 7D 5D 31 B6 7D 5E 9C B5 7E
        ^^^^^       ^^^^^       ^^^^^
In der Mitte sehen wir 0x7D 0x5D in einem gekapselten v3 Frame. Wenn zuerst
das v3-Protokoll maskiert worden wäre (mit den gleichen Escapings wie v2),
müsste dort aber 0x7D 0x5D 0x5D stehen, da
  1. v3-Escaping: 0x7D -> 0x7D 0x5D
  2. v2-Escaping: 0x7D 0x5D -> 0x7D 0x5D 0x5D
Folglich wird nur einmal maskiert, was also nur auf der v2-Schicht geschehen
kann, also gibt es bei "v3 over v2" keine Maskierungen.




--------------------------------------------------------------------------------
[CRC-Algorithmus]

typedef unsigned short u16;

#include <stdio.h>
#include <string.h>

u16 crctable[256];

void generate_crctable (int polynom)
  {
   unsigned int b, v;
   int i;

   for (b = 0; b < 256 ; b++ )
     {
      v = b;
      for (i = 8; i > 0; i--)
        {
	 if (v&1)  { v = (v >> 1) ^ polynom; }
	 else { v = v >> 1; }
	}
      crctable[b] = v & 0xFFFF; 
     }
  }


u16 calculate_crc (u16 initial_crc, unsigned char* data, int length)
  {
   u16 crc = initial_crc;
   int i;
   for (i=0; i < length; i++)
     { crc = ( crc >> 8 ) ^ crctable[ (crc ^ (data[i] ^ 0xff)) & 0xff ]; }
   return ~crc;
  }

int main (int argc, char** argv)
  {
   int initial_value = 0xffff;
   int highbyte, lowbyte, crc;
   
   int polynom = 0x8408;
   unsigned char data[17][6] = 
      {
       {0xff, 0x02, 0,    0x23, 0x2d, 2}, 
       {0xff, 0x03, 0,    0x32, 0xa4, 2}, 
       {0xff, 0x04, 0,    0x46, 0x1b, 2},
       {0xff, 0x05, 0,    0x57, 0x92, 2},
       {0xff, 0x06, 0,    0x65, 0x09, 2},
       {0xff, 0x07, 0,    0x74, 0x80, 2},
       {0xff, 0x09, 0,    0x9d, 0xfe, 2},
       {0xff, 0x0A, 0,    0xaf, 0x65, 2},
       {0xff, 0x0B, 0,    0xbe, 0xec, 2},
       {0xff, 0x0C, 0,    0xca, 0x53, 2},
       {0xff, 0x0D, 0,    0xdb, 0xda, 2},
       {0xff, 0x0E, 0,    0xe9, 0x41, 2},
       {0xff, 0xc1, 0x00, 0xe5, 0x06, 3},
       {0xff, 0xc9, 0x00, 0x2b, 0xc6, 3},
       {0xff, 0x80, 0x00, 0xba, 0xb8, 3},
       {0xff, 0xe0, 0x00, 0xdf, 0xed, 3},
       {0xff, 0xe3, 0x00, 0xf5, 0x85, 3}
      };
   
   int iLowbyte =  3;
   int iHighbyte = 4;
   int iLaenge = 5;
   int iNrDaten = 17;

   unsigned char daten[44] = {};
   int length = 0;
   
   int i = 0, j=0;
   highbyte = lowbyte = 0;

   generate_crctable(polynom);

   for (i=0; i<iNrDaten; i++)
     {
      length = data[i][iLaenge];
      for (j=0; j<length; j++)  { daten[j] = data[i][j]; }

      crc =  calculate_crc(initial_value, daten, length);
      lowbyte = (crc & 0xFF00) / 256;
      highbyte = crc & 0x00FF;

      if (length == 2)
        {
         if (lowbyte != data[i][iLowbyte] || highbyte != data[i][iHighbyte])
           { printf ("2er CRC wird nicht mehr erzeugt!: %d 0x%02x 0x%02x (ist: 0x%02x 0x%02x) \n\n", i, lowbyte, highbyte, data[i][iLowbyte], data[i][iHighbyte]); }
        }
      else if (lowbyte == data[i][iLowbyte] && highbyte == data[i][iHighbyte])
       { printf ("RICHTIGER CRC: 0x%02x 0x%02x\n\n", lowbyte, highbyte); }
      else
        {
         int x = 0;
         printf ("Daten: ");
         for (x=0; x < length; x++)    { printf("0x%02x ", daten[x]); }
         printf ("\n");

         printf("real: (0x%02x 0x%02x) \n", data[i][iLowbyte], data[i][iHighbyte]);
         printf("CRC: (0x%02x 0x%02x) \n\n", lowbyte, highbyte);
        }
     }
   return 0;
  }



--------------------------------------------------------------------------------
Dank an:
  Bob Mathews, David Wagner und weitere Helfer aus sci.crypt (CRC-Algorithmus)

--------------------------------------------------------------------------------
,---------- [ COPYING ] -----------
| Permission is granted to copy, distribute and/or modify this document
| under the terms of the GNU Free Documentation License, Version 1.1 or
| any later version published by the Free Software Foundation; with no
| Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A
| copy of the license can be obtained under
| http://www.gnu.org/licenses/fdl.txt
`----------------------------------