,---------[ teledat.sourceforge.net ]---------- | Autor: Felix Schwarz | Webseite: teledat.sourceforge.net | |--------- Changelog --------- | 19.07.03 fs Ergänzungen auf Grund neuer AVM-Treiber | 28.03.03 fs kleine Ergänzungen zur Fax-Funktionalität | 15.03.03 fs CRC gefunden, daher einige Aktualisierungen | 07.02.03 fs Ergänzungen Phase 4 | 08.01.03 fs Ergänzungen zum Status | 17.10.02 fs Ergänzungen zu SMP und CAPI | 03.10.02 fs einige kleinere Korrekturen | 07.08.02 fs diese Datei erstellt | `--------- -------------------------------------------------------------------------------- In diesem Text will ich kurz meine Motivation zur Entschlüsselung des proprietären AVM-Protokolls sowie die Prioritäten und langfristigen Ziele für die Entwicklung erläutern. [Motivation] Der Hersteller AVM hat stellt immerhin Linux-Treiber für die Fritz!X USB bereit, die sich auf Grund der Protokoll-Kompatibilität (mit kleinen Abwandlungen!) auch für die 1&1 NetXXL und die Teledat USB 2a/b eignen. Leider gibt es gleich mehrere Problempunkte: Einmal liegen die Treiber nur in vorkompilierter Form vor. Da Linux grundsätzlich von einer Quelltext-Kompatibilität ausgeht (der Quelltext kann auf einer anderen Plattform kompiliert werden und läuft dann dort problemlos), ändern sich die Binärschnittstellen durchaus des öfteren, wenn die Entwickler dies für sinnvoll halten (dabei geht es nicht nur um den Linux-Kernel selbst, auch der C-Compiler und und andere Tools spielen hier eine Rolle). In solchen Situationen ist man immer auf AVM angewiesen, damit diese einen neu kompilierten Treiber veröffentlichen, der dann sogar immer noch auf Suse angepasst ist (Benutzern anderer Distributionen wird die Installation unnötig erschwert). Weiterhin gibt es von AVM keine Treiber für die serielle Internet-Verbindung. USB hat aber den Nachteil, dass die Kabellänge (ohne teure Verstärker) auf 5m begrenzt ist, was mir z.B. nicht ausreicht, da die Telefonanlage aus Platzgründen weiter entfernt steht. Serielle Kabel dagegen sind relativ billig und überbrücken auch Längen von 10-15m problemlos. Von AVM selbst ist nur zu hören, dass es mit Sicherheit nie einen Linux-Treiber für den seriellen Anschluss geben wird, Original-Zitat aus "install_passive-d.html" (enthalten im AVM-Treiberpaket für Linux): > Für die folgenden Controller mit V.24-Schnittstelle wird es nie (!) Treiber > nach dem CAPI4Linux-Modell geben: > * AVM ISDN-Connector FRITZ!X PC > * AVM ISDN-Connector FRITZ!X PC v2.0 Ich werde versuchen, sämtliche Funktionen, die AVM anbietet, auch für Linux nutzbar zu machen und einige Funktionen vielleicht auch ein bisschen cleverer zu implementieren. Speziell zur Fax-Funktionalität allerdings unten mehr. Ein weiterer Punkt war ursprünglich, dass die AVM-Treiber nicht für Mehrprozessor- Rechner ("SMP") geeignet waren, div. Änderungen im Linux-Kernel diese Fähigkeiten gezielt benötigten. Allerdings gelang es Heiko Rabe im April 2003 durch Änderungen im LGPL-Teil der Treiber, diese auch für SMP-Systeme anzupassen. Inzwischen hat AVM nachgezogen, so dass zumindest dieses Problem zunächst beseitigt wurde. [Linux und was sonst?] Ich habe auch verschiedentlich von Mac-Benutzern gehört, dass sie durchaus Interesse hätten, die hardmäßig solide verarbeiteten und recht preisgünstigen AVM-Anlagen einzusetzen. Leider gibt es keinerlei Treiber für MacOS bzw. andere Systeme (BSD-Derivate, Hurd, ...). Sollte das Protokoll erst einmal verfügbar sein, dürften entsprechende Portierungen nur eine Frage des persönlichen Könnens sein. Ich persönlich habe z.Zt. nur ein Interesse, Treiber und Anwendungen für Linux zu schreiben. Allerdings werde ich jeden gerne mit Informationen und Ratschlägen unterstützen, der einen freien Treiber für ein anderes Betriebssystem schreiben will. [CAPI?] Auch wenn der CAPI-Standard frei verfügbar ist und AVM sehr auf die CAPI setzt, liegt hierin leider nicht die Lösung zum AVM-Protokoll. CAPI ist nur eine einheitliche Programm-Schnittstelle, über die alle Programme ISDN-Funktionen einfach nutzen können. Die Umsetzung der CAPI-Befehle zum konkreten Ansprechen der Hardware muss aber für jede Hardware extra implementiert werden und dafür muss man das Hersteller-Protokoll kennen. Außerdem sieht der CAPI-Standard auch herstellereigene, proprietäre Erweiterungen vor, die AVM auch nutzt (z.B. zur Konfiguration der Bluetooth-Anlagen). Die aktiven Karten von AVM haben wohl eine CAPI-Implementierung in der Hardware, dies trifft aber auf die AVM-Smartdevices nicht zu, dies sind alles passive Karten. [Fax?] Die Fax-Funktionalität ist ziemlich kompliziert zu implementieren auf einem Multiuser-System (worunter nahezu alle modernen Systeme wie Linux, Mac OS X u.a. fallen). Das Problem dabei ist, dass bei der Fax-Übertragung garantierte Antwortzeiten eingehalten werden müssen und passive ISDN-Karten die ganze Last der Dekodierung auf die CPU abwälzen, was natürlich bei hoher Systemauslastung zu einem Problem wird. Bisher gibt es meines Wissens nach keine einzige freie Implementierung der Faxfunktionalität für passive ISDN-Karten. Daher ist die Fax-Funktionalität in meiner Prioritätenliste erst einmal ziemlich weit unten. Ggf. wird es nie eine Implementierung geben, auch wenn die externen AVM-Anlagen zumindest etwas Hardware-Unterstützung für den Faxversand bieten. [AVM Dateitransfer?] AVM benutzt in seinem Tool Fritz!Data neben Euro-ISDN auch ein proprietäres Protkoll namens IDTrans, das ähnlich funktioniert wie das aus der Mac-Welt vielleicht bekannte Leonardo-Protokoll (ebenfalls proprietär, Hersteller ist Hermstedt). Um die komplette Funktionalität zu sichern, werde ich mir später ev. auch Gedanken zur Analyse dieses Protokolls machen. Definitiv aber eine niedrige Priorität. [wann sind wir fertig?] Ich kann schon mal sagen, dass es in nächster Zeit keinen funktionierenden Internettreiber geben wird (auf keinen Fall vor Anfang 2004). Dies liegt einfach daran, dass eine Implementierung und das anschließende Debugging sehr vertrackt sein kann, wenn man noch nicht mal alle Eigenheiten des zugrunde liegenden Protokolls kennt und mein Studium kostet auch viel Zeit. Nach derzeitigem Stand ist es auch unwahrscheinlich, dass es einen Treiber für die Kernelversionen 2.2 oder 2.4 geben wird, weil das ISDN4Linux-Subsystem in der Version 2.5 umgebaut wurde und sich der doppelte Aufwand kaum lohnen dürfte. Versprechen kann ich jedenfalls nichts. Vielleicht wird es auch nie einen fertigen Treiber geben. Immerhin könnten meine bisher gesammelten Informationen aber ev. einem Nachfolgeprojekt helfen. Daher habe ich mich in meiner Planung (s.u.) auch erst mal auf kleine, realistische Ziele beschränkt. Zu beachten ist dabei aber, dass die unten stehende Liste _meine_ persönlichen Prioritäten wiederspiegelt. Wenn es mehrere Entwickler gibt, die alle an einer Implementierung arbeiten, können selbst größere Projekte plötzlich ziemlich schnell realisiert werden. Und jeder ist natürlich frei, Features, die ihm oder ihr wichtig sind, selbst zu implementieren bzw. andere Prioritäten bei der Programmierung zu setzen. Daher wäre auch deine Mitarbeit durch Bugreports, aktive Fehlersuche und eigene Analyse des Protokolls eine große Hilfe! :-) [Phase 1] Erstes Ziel ist die Entschlüsselung des seriellen Konfigurationsprotokolls, da ich denke, dass dieses am Einfachsten zu bewerkstelligen ist und man gleichzeitig einiges über das AVM-Protokoll lernt. Parallel werden erste Konfigurationstools entstehen, die aber hauptsächlich zum Testen des Protokollverständnisses dienen werden. Status: Wir befinden uns gerade im Übergang von Phase 1 zu Phase 2, da der CRC-Algorithmus gefunden wurde. [Phase 2] Ist erst einmal das Konfigurationsprotokoll weitgehend bekannt, beginnt die zweite Stufe: Das Programmieren eines Konfigurationsprogramms, mit dem man die Anlage konfigurieren kann (ähnlich der Fritz! Konfigurationssoftware von AVM). Ich hoffe, die Software eng in vorhandene Unix-Tools integrieren zu können. Ev. können wir sogar einige nette Gimmicks einbauen, die AVM noch nicht bietet: Ein "Anrufbeantworter", der einem die Nummern der Anrufe in Abwesenheit anzeigt (besonders praktisch, wenn einige Leute nicht auf den Anrufbeantworter sprechen wollen). Auch beim Least Cost Routing könnte man ein automatisches Update der Anbietervorwahlen per Internet implementieren. Parallel dazu kann mit der Analyse der Internetfunktionen von AVM begonnen werden. Dies wird insofern komplizierter, da beim Internet schon etliche Protokolle zusammenwirken. Genaue Kentnisse all dieser Protokolle sind sicherlich für die Unterscheidung unabdingbar, ob es sich bei den aufgefangenen Befehlen um proprietäre AVM-Steuerinformationen oder Internet-Protokolle handelt. [Phase 3] Hier können wir beginnen, einen echten Linux-Treiber zu schreiben, der den Zugang ins Internet ermöglicht und ggf. sogar in den Kernel integriert werden kann. Anfangs wird es sicherlich nur die Basisfunktionalität geben, Kanalbündelung, Call Bumping u.ä. kommt später! Außerdem wird das USB-Protokoll analysiert und in das Konfigurationstool sowie den Treiber eingebunden. [Phase 4] Erweiterung des Treibers für Kanalbündelung, Call Bumping, dynamische Kanalbündelung (zuschalten bei Bedarf u.ä.), Kompression, CAPI-Einbindung, ev. gibt es auch ein AT-Interface, damit man die Anlage auch mit herkömmlichen Modemanwendungen nutzen kann. Bei Bedarf auch Arbeiten am ursprünglichen AVM-Protokoll der Fritz!X PC 1.0 und Eumex 302 PC. [Phase 5] Analyse des ebenfalls proprietären AVM-Protokolls zum Dateitransfer (IDTrans- Protokoll), ggf. Einbindung in den Treiber. Entwurf eines Servers sowie von Clientprogrammen zur Nutzung dieses Protokolls. Wenn uns einige trickreiche Algorithmen dazu einfallen, sogar Nutzbarmachung der Fax-Funktionalität. --------------------------------------------------------------------------------