,---------[ 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)
| 26.02.03  fs	weitere Ergänzungen - vieles wie im v3-Protokoll
| 25.02.03  fs	Datei erstellt
|
`---------

--------------------------------------------------------------------------------
Im folgenden ist das von mir so getaufte "v3.0"-Protokoll allgemein beschrieben,
allerdings noch ziemlich unstrukturiert - ist halt alles gerade in der
Entwicklung und Erforschung.


[allgemeine Eigenschaften]

Bei der Fritz!X PC v1 und der Eumex 302 PC scheint AVM ein anderes Protokoll
verwendet zu haben als bei den neueren Anlagen, wo sich die Fritz!X USB/PC v2+3,
die Fritz!Card USB und andere Anlagen das gleiche Protokoll ("v3.1") teilen.
Das v3.1-Protokoll ist scheinbar eine Weiterentwicklung des alten, so dass ich
dieses v3.0 nenne.

Eigentlich ist das v3.0-Protokoll nicht mehr so interessant (weder die Fritz!X PC v1
noch die Eumex 302 PC werden noch verkauft) und wird auch nicht mein vorrangiges
Forschungsgebiet werden, doch im Zuge einiger Untersuchungen vermerke ich hier die
mir bereits aufgefallenen Informationen.



--------------------------------------------------------------------------------
Hier zunächst noch einige Dinge zu v2.0

Es wird der selbe CRC-Algorithmus verwendet wie im v2-Protokoll.

Erstkontakt bei 19.200 Baud und Hochschalten auf 115200 Baud funktionieren
exakt wie in v2.1.


Ebenfalls alle 10 Sekunden sendet die Anlage unaufgefordert und ohne
Antwort die gleiche Sequenz wie neuere Anlagen:
  7E 00 02 DF 01 47 AA 1C 7E

Unterschiedlich ist jedoch, dass alle 10 Sekunden folgende Pakete gesendet
werden (zeitversetzt um 5 Sekunden mit oberen), jedoch nicht 3 oder 4
wie bei neueren Anlagen.
  7E 00 02 DB 01 B9 3A 61 7E
  7E 00 02 E1 01 99 EC B5 7E
Erinnert alles sehr an das v2.1-Protokoll.


Die Eumex 302 PC versteht allerdings die Anforderung
   7E 20 FF 03 AC 08 7E
nicht, reagiert jedenfalls nicht wie im v2.1.


Als erstes nach 0x01 sendet die Anlage
->7E 60 00 04 00 31 2E 30 35 2E 30 34 00 30 30 30 30 30 30 30 00 44 2C 7E
                [1] [.] [0] [5] [.] [0] [4] 00 [0] [0] [0] [0] [0] [0] [0] 00 (CRC) 7E
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Firmware-Version

# Fritz!X PC v1
->7E 60 00 04 00 31 2E 30 36 2E 30 36 00 30 30 30 30 30 30 30 00 FD 7A 7E
                [1] [.] [0] [6] [.] [0] [6] 00 [0] [0] [0] [0] [0] [0] [0] 00 (CRC) 7E
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^ entspricht der Firmware-Version

# NetXXL
-> 7E 20 0F 04 00 33 2E 30 33 2E 30 32 00 33 2E 30 33 2E 30 32 00 F8 0B 7E
                 [3] [.] [0] [3] [.] [0] [2] 00 [3] [.] [0] [3] [.] [0] [2] 00 (CRC) 7E
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ statisch, nicht die Firmware



Falls kein entsprechender Treiber im System installiert ist, verwendet die
Software ebenso wie bei neueren Anlagen "v3.0 over v2.0".

Auf 7E FF 09 9D FE 7E antwortet die Anlage ähnlich wie im v3:
7E FF 49 00 (1) $Type:_(2)_$Version:_(3)_$Date:_(4)_$Time:_(5) 00 (CRC) 7E
(es fehlt "$Update: Capi ")

(1) 1 Byte (0x0A), bei neueren Anlagen 2 Byte (0x0D 0x0A)
(2) 9 Byte, Anlagenkennung:
      Fritz!X-V : Fritz!X PC v1 oder Eumex 302 PC
(3) 6 Byte, Firmware-Version, z.B. "01.05.04" (2. Zeile der Firmwaredatei)
	(3) 11 Byte, Release-Datum der Firmware, z.B. "Mar  3 1998"
	(4) 6 Byte, Uhrzeit des Releases Firmware, z.B. "16:32:54"
	(5) 16-Bit Prüfsumme, Algorithmus unbekannt


Auffällig ist, dass bei v2.0 die Frames scheinbar nur sehr viel kürzer sein
dürfen: Ab einer von 2 (Start-/Ende) +2 (CRC) +35 (Daten) = 37 Bytes wird
ein neuer Multiframe angefangen.


gepeicherte Kurzwahlen auslesen exakt so wie im v3.1-Protokoll, alles identisch
ebenso "FF 01", "FF 02", "FF 03", "FF 04",

beim Speichern:
MSNs
Amtsholung
Anklopfschutz
Rundruf
CLIP/CLIR
(Speichern)

ff 07 doch gleich (Fehler in der v3.1-Spec?)

"FF 41" ist gleich

"FF 46" ist identisch, nur dass es nur die Optionen
0xFF 	aus
0x01	sofort
0x02	verzögert
0x03	bei besetzt
0x04	bei verzögert/besetzt
0x05 und 0x06 kamen erst später (Überprüfen, was die Anlage in diesem Fall macht)


Für "FF 0C" und "FF 0E" (SMS, Klingelsperre) gibt es keine Optionen

"FF 81" ist gleich, ebenso 82-84


"FF 87" scheint anders zu sein als v3.1! (oder Fehler bei v3-Spec)
00 00 00 00  CLIP	- 0x00 = CLIP aktiv, 0x01: kein Haken
00 00 01 01  CLIR	- 0x00 = CLIR aktiviert, 0x01 deaktiviert
00 00 00 00  Rufe abw	- keine Option..., immer 0x00
00 00 00 00  ???	  ebenfalls...



Fazit: Fast alles gleich, CTI noch nicht ausprobiert

Anrufen:
7E FF 80 (Nebenstelle) (Nummer) (irgendetwas) CRC 7E
die Nummer kann scheinbar beliebig lang sein, jedoch verändert sich
das "irgendwas" am Ende dann... ? Die Länge der Rufnummer wird
jedenfalls nicht im Request kodiert.

Als Bestätigung kommt von der Anlage:
-> 7E FF C0 00 00 C0 0F 7E

Je nachdem, ob das ganze erfolgreich war, gibt es eine Anrufermeldung
oder

für besetzt(?)
->7E FF A1 91 34 00 00 00 00 00 00 8E 26 7E
<- 7E FF E1 00 C6 35 7E

existiert nicht:
-> 7E FF A1 00 00 00 00 00 00 81 34 C4 8C 7E
<- 7E FF E1 00 C6 35 7E







--------------------------------------------------------------------------------
,---------- [ 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
`----------------------------------