Capio auf der FritzBox

[laland]

Hallo Community!

Ich wollte mich aus Interesse mal etwas mit dem CAPI over TCP -Server meiner FritzBox befassen. Leider fand ich bis jetzt keine Informationen, wie mit diesem Server umzugehen ist.

In erster Linie interessiere ich mich für das Protokoll, die Kommunikation zwischen Client und Server. Gibt es da empfehlenswerte Lektüre für mich?

L

 

[doc456]

Hallo,

eigentlich nicht, da es avm-spezifisch ist.
Du kannst dir aber mal diesen Thread durchlesen, vielleicht hilft dir das etwas weiter...

 

[laland]

Achso, verstehe. Und mit diesen Informationen ist nichts anzufangen?

http://www.wehavemorefun.de/fritzbox/index.php/CAPI-over-TCP-Protokoll


Habe ich es überhaupt richtig verstanden, dass ich mit dem CAPI über die Software Faxe senden und empfangen kann?


L

 

[doc456]

Stimmt, daran hatte ich nicht gedacht...
(Die Einführung hattest du gelesen?)

Und ja, kannst du, mit diesem Prog.

 

[laland]

Stimmt, daran hatte ich nicht gedacht...
(Die Einführung hattest du gelesen?)

Und ja, kannst du, mit diesem Prog.

Das habe ich erst im Nachhinein gefunden. aber wenn die Informationen ausreichen, um damit arbeiten zu können, bin ich zufrierenden. mir geht es eher weniger um den praktischen nutzen und mehr darum, die Funktionsweise zu verstehen, deswegen ist es mein ziel, das in einem eigenen Programm, ohne dll, zu schreiben.

L

 

[doc456]

Da bin ich mal gespannt. Berichte bitte weiter, OK?

AVM ist mit der Capi immer sehr eigen...

BtW, warum machst denn ein Fullquote von meinem Beitrag darüber?

 

[laland]

Da bin ich mal gespannt. Berichte bitte weiter, OK?

Gern, wenn es hier interessierte User gibt, werde ich einige Codes posten, sobald ich nennenswerte Fortschritte gemacht habe. ;-)

BtW, warum machst denn ein Fullquote von meinem Beitrag darüber?

Sorry, der hat sich unbemerkt eingeschlichen; auf jeden Fall war es keine Absicht.


L

 

[bodega]

Hi.

Ich hatte auch schon mal mit dem Gedanken gespielt, den Remote-CAPI der Box direkt anzusprechen, hatte aber dann nicht mehr weitergemacht. Der Link ist sehr interessant. Unter Linux könnte man die libcapi soweit ändern, dass diese TCP verwendet, anstelle das Device anzusprechen. Unter Windows würde man eine DLL nehmen und die folgende Funktionen mit korrekten Ordinalzahlen exportiert:

EXPORTS
	 CAPI_REGISTER 
	 CAPI_RELEASE
	 CAPI_PUT_MESSAGE
	 CAPI_GET_MESSAGE 
	 CAPI_WAIT_FOR_SIGNAL 
	 CAPI_GET_MANUFACTURER
	 CAPI_GET_VERSION 
	 CAPI_GET_SERIAL_NUMBER
	 CAPI_GET_PROFILE
	 CAPI_INSTALLED

Da die Funktionen die unterste Stufe der CAPI bilden und auch das CAPI-ADK auf diese zugreift, sollte man hier den Socket-Teil implementieren.

Ein Open-Source Projekt was sowohl unter Linux als auch Windows läuft wäre schon eine tolle Sache. Dann müsste man auch keinen zusätzlichen rcapid installieren. Zwar gibt es unter Windows bereits eine capi2032.dll, aber es wäre schön, unter Linux eine ähnliche Lib zu haben.

EDIT:
Cool das geht . Ich hab mir jetzt mal meine eigene capi2032.dll für Windows gecoded die mit dem AVM capi-over-tcp zusammen funktioniert. Bisher habe ich nur CAPI_REGISTER, CAPI_PUT_MESSAGE und CAPI_GET_MESSAGE implementiert. Es fehlt noch CAPI_RELEASE und die richtigen Informationen, wenn man ein CAPI_GET_PROFILE durchführen möchte. Ebenso das CAPI_WAIT_FOR_SIGNAL. Alles noch ne Baustelle und nur für eine ApplId.

 

[laland]

Interessant, interessant. Das scheint ja wirklich von Interesse zu sein


Was die Messages betrifft, habe ich noch eine Frage (als Grundlage nehmen wir dazu http://www.wehavemorefun.de/fritzbox/index.php/CAPI-over-TCP-Protokoll):

Gehen wir mal von einem Register-Request (CAPI_REGISTER) aus.

Die Anfrage müsste dann, wenn ich es richtig verstanden habe, folgendermaßen aussehen:

 ### Das, was in auf der Seite als 'TCP-Header' beschrieben wurde? ###
 0x80 (byte)
 [len] (word)

 ### Nun der Message-Struct, capi20-1.pdf: Seite 16 ###
 [capi_len] (word)
 0x0000 (word)
 0x00 (byte)
 0x00 (byte)
 0x0000 (word)

 ### Ab jetzt verwirrt mich das ein wenig, hier folgen zwei weitere Bytes,
 ### dessen Funktion nicht geklärt wurde:
 0x02 (byte)
 0x00 (byte)

 ### Anzahl ohne Header in Worten. Das scheint klar zu sein, jedenfalls
 ### teilweise. Da auf der Seite 'N+3' steht, gehe ich davon aus, dass die
 ### Zahl dieses Bytes '6' sein muss:
 0x06 (byte)

### Der Spezialkommando-Code scheint mir eine Konstante zu sein:
 0x20 (byte)

### Anzahl der Argumente und die Argumente scheinen selbst klärend zu sein.

Die letzte Sache, die ich noch genau wissen möchte ist, wie die Längenangaben gemacht werden. Das obere 'len' ist ja Bestandteil der ersten 3 Byte (TCP-Header, nicht Bestandteil des offiziellen CAPI) definiert, so wie ich das verstehe, die Länge der gesamtem CAPI-Messge (Header inklusive 'Payload'); das zweite ('capi_len') definiert anscheinend die Länge aller Daten, die auf den Header folgen. Stimmt das soweit? (Was mit 'Anzahl ohne Header in Worten' gemeint ist, ist mir ein wenig schleierhaft.)

Eine Frage habe ich allerdings noch zu den Daten, die direkt auf den Message-Header folgen, aber definitiv keine Argumente sind. Ist das eine Besonderheit der CAPI_REGISTER Message oder kommt es öfters vor, dass sich zwischen Header und Argumenteliste ein paar Bytes/Words drängen?



L

 

[bodega]

Das obere 'len' ist ja Bestandteil der ersten 3 Byte (TCP-Header, nicht Bestandteil des offiziellen CAPI) definiert, so wie ich das verstehe, die Länge der gesamtem CAPI-Messge (Header inklusive 'Payload'); das zweite ('capi_len') definiert anscheinend die Länge aller Daten, die auf den Header folgen. Stimmt das soweit?

Ja das stimmt.

Eine Frage habe ich allerdings noch zu den Daten, die direkt auf den Message-Header folgen, aber definitiv keine Argumente sind. Ist das eine Besonderheit der CAPI_REGISTER Message oder kommt es öfters vor, dass sich zwischen Header und Argumenteliste ein paar Bytes/Words drängen?

CAPI_REGISTER ist ein Sonderfall. Hier wird der CAPI-Header und die Message manuell zusammengebaut und die jew. Argumente wie Anzahl der Verbindungen, Anzahl der B3-Blöcke und Blockgröße übergeben.
Bei CAPI_GET_MESSAGE / CAPI_PUT_MESSAGE muss man nur nach den drei Bytes die CAPI-Nachricht übergeben.

capi_over_tcp_client.c

-removed-

capi_over_tcp_client.def

-removed-

Es gibt noch ein Problem mit dem DATA_B3_REQ(). Das muss ich mir noch anschauen. Ich teste das ganze unter Windows. Später könnte man es auf Linux übertragen...

 

[Pikachu]

Hallo,

Frage lässt sich diese Function CAPI_GET_SERIAL_NUMBER
dazu verwenden um zu Prüfen ob Capi over Tcp an oder aus ist,
da ich die Seriennummer 0004711 nur bei Capi over Tcp On
Angezeigt bekomme.

Return = 0 -> Capi over Tcp On
Return = 4105 (ungleich 0) -> Capi over Tcp Off

bei fritzcapi capi2032.dll version 3.8.1.0 für windows

Gruß Erwin

 

[bodega]

@Pikachu:

Idealerweise eignet sich CAPI_INSTALLED() dafür. CAPI_GET_SERIAL_NUMBER() liefert die Seriennummer zurück, die bei AVM wohl immer ...4711 ist. Es liegt wohl daran, dass das Profil ebenfalls per Remote ausgelesen wird. Ist der CAPI-over-TCP nicht an, wird auch keine Serien-Nummer zurückgeliefert.

Btw. habe ich den obigen Code entfernt. Keine Ahnung ob sowas überhaupt erlaubt ist. Wie seht ihr das? Der Nutzen liegt klar auf der Hand (man könnte z.B. eine libcapi20.so für die FB erstellen), aber wie sieht es Rechtlich aus??? Möchte nicht, dass AVM mir an die Karre fährt wegen dem ganzen Reverse Engineering ...

EDIT:
Der Empfang von B3-Blöcken geht nun auch. Das Senden leider noch nicht. Sobald der Puffer aufgebraucht ist, bricht die Kommunikation ab. Als ob der DATA_B3_RESP nicht erkannt wird, um den Puffer zu leeren...

 

[laland]

Hallo.

Gerade habe ich versucht, CAPI_RELEASE zu implementieren. Als Vorlage dafür nahm ich die Struktur einer Special-Message, welche auf der Seite (s.o.) definiert wurde:

[tcp-header: 0x80, laenge]
80
0e 00

[capi messageheader: laege, applid, kommando, subkommando, message-num]
0e 00
xx xx
20
80
?? ??

[wieder die 2 unbekannten bytes der special-messages]
02 00

[laenge ohne header in worten]
xx xx

[spezialkommando-code, laute seite '1']
01 00

[anzahl der argumente: 0]
00 00

Auf der Seite, dass ein RELEASE-Request 14 Bytes groß sein sollte, bei mir sind es aber 16. Wo habe ich da etwas überflüssiges eingetragen?

Und was sollte ich im CAPI-Header als Message-Number eintragen? Das ist mir leider nicht so ganz klar, da auf der Seite ja nur die Rede von dem Spezialkommando ist.

 

[bodega]

Die Message-Nr. ist normalerweise eine fortlaufende Nummer, die auch von der Anwendung mitgegeben werden kann. Pro Nachricht wird diese um +1 erhöht. Es ist nicht weiter schlimm, wenn hier nur 0 steht (möchte mich aber auch nicht festlegen ).

Auch ich komme auf 16 Bytes. Wieso nur 14 Bytes müsste man mal sniffen und den CAPI_RELEASE mitschneiden... ich schaue gleich mal...

EDIT:
Das wird bei CAPI_RELEASE gesendet. Die 14 Bytes stimmen also. Insgesamt sind es aber 17, wegen dem Header.

0000011E  80 0e 00 0e 00 07 00 20 80 09 00 02 00 03 01 00 .......  ........
0000012E  00                                               .

Länge: 14 Bytes, ApplId: 7, Msg-Nr. 9

 

[laland]

Ich verstehe. Also ist es ratsam, die Messagenumber der Kompatibilität wegen bei jedem Request zu incrementieren? (Wirklich nur bei Requests oder hat eine Confirmation, eine Indication oder gar eine Response auch Einfluss auf die Message-Number?)

L

 

[bodega]

Zur Message-Nr. steht alles in der CAPI-Referenz unter 3.1.

CAPI_RELEASE habe ich nun auch implementiert und funktioniert soweit. DATA_B3_REQ geht auch. Man muss auf jedenfall die Adresse des Buffers auf 0x00000000 zurücksetzen, nachdem man den Buffer an das Ende der Nachricht kopiert hat.

Den CAPI-over-TCP über Broadcast zu finden, habe ich rausgelassen. Mit direkter IP Angabe finde ich das besser.

Mal sehen. Wollte jetzt eine libcapi20 erstellen, die sowohl die internen Controller enthält, wie auch die über Remote. Auf einem Repeater installiert, könnte dieser dann die ISDN-Funktionalität der Basisstation verwenden.

 

[laland]

Ja danke! Da steht, dass die Message-Number unique sein muss, also ist es nicht zwingend erforderlich, dass es eine fortlaufende Nummerierung ist, oder?


Mittlerweile hatte ich endlich mal zeit, mich daran zu setzen und die Register-Funktio zu schreiben. Kann es sein, dass die Fritzbox an den Header der Response-Message (Antwort auf den Register-Request) 10 weitere Bytes (Argumente) anhängt?

 

[bodega]

@laland:
Also bei mir ersetzt der CAPI-over-TCP die Message-Nr. immer, wenn ich etwas übertrage. Ich setzte die beim CAPI_REGISTER und CAPI_RELEASE immer auf 1. Funktioniert wunderbar.
Bei CAPI_PUT_MESSAGE, CAPI_GET_MESSAGE kommt die Message-ID aus den Buffer, der von der Applikation übertragen wird. Die Nachricht wird von den darüber liegenden Funktionen wie CONNECT_REQ, CONNECT_RESP, ALERT_REQ, usw. mitgeliefert.

Das wichtigste bei der Antwort von CAPI_REGISTER ist die ApplID, welche sich an Position 4 befindet und 2 Bytes groß ist. Diese muss man in allen weiteren Nachrichten mitliefern.

Anscheinend ist das Reverse Engineering von Netzwerk-Protokollen, laut Wikipedia, erlaubt.
Meine libcapi20.so.3 läuft nun auch mit 10 Controllern (5 Lokal, 5 Remote). Falls kein lokales CAPI existiert (kein /dev/capi20), gibt es eben nur 5 Controller. Dafür braucht man nicht mal irgendwelche ISDN-Module laden. Das einbinden der Library reicht.

Leider darf ich nur einen B-Kanal bei Remote belegen... da muss ich nochmal genauer schauen. Ansonsten läuft alles und ist mit bisherigen CAPI-Anwendungen kompatibel (nunja, zumindest mit einer schonmal ).

 

[doc456]

Ansonsten läuft alles und ist mit bisherigen CAPI-Anwendungen kompatibel (nunja, zumindest mit einer schonmal ).

Das ist doch mal eine gute Nachricht, Danke, guter Job von dir/euch! :rock:

 

[laland]

Was ist eigentlich ein Controller? Das wollte ich sowieso noch in Erfahrung bringen. Den Brauche ich, wenn ich einen Listen-Request sende. Ich vermute mal einfach, dass der Controller die angeschlossene Telefon-Hardware ist (richtig?). Wie ermittelt man denn die Nummer des Controllers?

L